DETAILED ACTION
This is responsive to amendments filed on 07/14/2026 in which claims 1-20 are presented for examination; Claims 1 and 12 have been amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 1:
Step 1: Is the claim to a process, machine, manufacture or composition of matter?” Yes, it’s a method.
Step 2a Prong 1 (judicial exception)
Step 2A (1): “Does the claim recite an abstract idea, law of nature, or natural phenomenon? Yes , the claim comes under mental processes.
Claim 1 recites:
“A computer-implemented method for automated administration of pre-approval of pharmacy product prior authorizations, the method implemented using a prior authorization pre-approval (paPA) computing device comprising a processor in communication with a memory, the method comprising: receiving via a remote computing device, a claim transaction message associated with a pharmacy claim transaction for a prescription that has satisfied a prior authorization (PA) trigger condition, the claim transaction message including (i) a plan identifier associated with a healthcare plan under which the prescription is submitted at an originating pharmacy, and (ii) a prescriber identifier associated with a prescriber of the prescription; querying a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, and jurisdictional regulations; applying a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and the jurisdictional regulations, the set of pre-approval rules defining pre-approval conditions for pharmacy PAs; when the pre-approval conditions are met: automatically appending an approval data element to the claim transaction message to generate a PA approval message; determining an identity of the remote computer device based on one or more data elements of the claim transaction message; and transmitting the PA approval message to the remote computing device , wherein the remote computing device includes one of a pharmacy claims processor for further adjudication of the pharmacy claim transaction, to the originating pharmacy to fulfill the prescription, or to a healthcare claims clearinghouse for forwarding of the PA approval message to the pharmacy claims processor or to the originating pharmacy; and writing a new record to the reference database including an indication of whether the pharmacy claim transaction for the prescription satisfied the pre-approval conditions.”
All the limitations above are abstract idea related to the mental process (concepts performed in the human mind (including an observation, evaluation, judgment, opinion)) with the exception of bold and underlined limitations. Claim language pertains to pre-approval/ pre-authorization of any pharmacy product (medication/drug, lab orders etc.). It involves the process of checking eligibility of the product, which needs pre-approval, based on healthcare plan, coverage , prescriber’s data and jurisdictional restrictions. It is a common practice in a clinical setting/pharmacy to carry out all the steps above for a product to be pre-approved. If a product is approved, a pharmacy is notified and a record is kept to indicate that the product has fulfilled all the conditions for pre-approval. All of this can be done on paper.
Step 2A(2): Prong Two: evaluate whether the claim recites additional elements that integrate the exception into a practical application of the exception. NO
The claim does recite additional elements; however they don’t integrate the exception into a practical application of the exception.
computer-implemented (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
automated administration (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
computing device (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
processor (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
memory (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
receiving via a remote computing device ((Adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) )
database (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
automatically appending(Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
transmitting the PA approval message to the remote computing device (Adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) )
remote computing device (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
Step 2B: evaluate whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception? NO
As discussed previously with respect to Step 2A Prong Two, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
Step 2B: evaluate whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception? NO
As discussed previously with respect to Step 2A Prong Two, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
Regarding the claim limitations:
receiving via a remote computing device ((the courts have recognized the computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (“i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information”); See, MPEP 2106.05 (d)(II)
transmitting the PA approval message to the remote computing device (the courts have recognized the computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (“i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information”); See, MPEP 2106.05 (d)(II)
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Dependent claims 2-11 further narrows the abstract idea and add the additional elements of “electronic PA vendor”, “transaction identifier”
Under step 2A, prong two, the additional elements don’t integrate the exception into a practical application of the exception as merely adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
As discussed previously with respect to Step 2A Prong Two, the additional elements in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Regarding claim 12, it is rejected under the same rationale as claim 1. It adds the additional elements of “computing device”, “processor”, “memory device”, “computer-executable instructions” “
Under step 2A, prong two, the additional elements don’t integrate the exception into a practical application of the exception as merely adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
As discussed previously with respect to Step 2A Prong Two, the additional elements in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Dependent claims 13- 20 are rejected under the same basis as claims 2-11.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of co-pending Application No. 19/033,181 in view of references cited in the prior art rejection section.
The claims of instant application are substantially anticipated by the co-pending application; the minor differences between claim language which are claimed in the instant application, and not in the co-pending applications have been addressed in the prior art section. The additional differences in the co-pending application are merely broader scope.
This is a provisional nonstatutory double patenting rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-9, 11-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Pinsonneault ( US 8392214 B1) in view of Allred et al. (US 20210210185 A1)
Regarding claim 1, Pinsonneault teaches :
a computer-implemented method for automated administration of pre-approval of pharmacy product prior authorizations (See, Fig. 2), the method implemented using a prior authorization pre-approval (paPA) computing device comprising a processor in communication with a memory, the method comprising (see col 1, line 59 ):
receiving, via a remote computing device, a claim transaction message associated with a pharmacy claim transaction for a prescription that has satisfied a prior authorization (PA) trigger condition (col 7, line 33, “Turning now to block 302 of FIG. 3, a pharmacy computer 103 may submit a prescription claim request 202 to the service provider computer 104. Accordingly, the service provider computer 104 may receive the prescription claim request 202 at block 302.......”)
the claim transaction message including (i) a plan identifier associated with a healthcare plan under which the prescription is submitted at an originating pharmacy, and (ii) a prescriber identifier associated with a prescriber of the prescription (col 12, line 28 “The information included in the request 253 may be obtained from the prescription claim transaction, including the prescription claim request 202 and the claim response 203. In some example embodiments, the information included in the request 253 can be derived or obtained from other sources as well. For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. “
Also, col 13, line 67 “At block 310, the service provider computer 104 and/or prior authorization assistance logic module 109 may store or direct the storage of a transaction history record of the prescription claim transaction in a history file or other list/record structure in the database 182, according to an example embodiment of the invention. An example transaction history record in the history file or similar list/record structure may include some or all of the following information: Payor ID: A name or BIN Number/PCN that is associated with a payor, Patient ID: An identifier for the patient such as the cardholder ID and/or group ID, or patient name, Drug/Product ID: an identifier of the drug or product, such as the NDC number, Pharmacy ID: an identifier of the pharmacy/pharmacy computer 102 originating the claim request, Quantity Dispensed: a dispensing quantity for the drug or product, Prescription (Rx)/Service Number, and/or Date of Service: a date identifying when the prescription was requested to be filled.);
querying a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, [and jurisdictional regulations](col 12, line 33 “For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. “ Note: Also, see col 12, line 28.
Also, (col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention.” Note: Also, see col 9, line 38);
applying a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and [the jurisdictional regulations], the set of pre-approval rules defining pre-approval conditions for pharmacy PAs (col 9, line 20 “ Turning now to FIG. 4, at block 402, the prior authorization assistance logic module 109 may determine whether the prescription claim transaction involves an eligible pharmacy. For example, block 404 may determine an eligible pharmacy by obtaining the pharmacy ID (or pharmacy name) from the prescription claim request 202, and then determining whether the pharmacy ID (or pharmacy name) matches a corresponding entry in a list of eligible pharmacy IDs (or pharmacy names). To be included on the list, a pharmacy may have previously registered with a service provider for prior authorization assistance, according to an example embodiment of the invention. If block 402 determines that the pharmacy is not an eligible pharmacy, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 402 determines that the pharmacy is an eligible pharmacy, then processing may proceed to block 404.”
Also, col 15, line 37 “In addition, the request 242 for prior authorization assistance can further include additional information associated with the patient, payor (e.g., insurer), or healthcare provider (e.g., prescriber, pharmacist, etc.). It will be appreciated that any additional information required may be based upon what information was already provided in the prior prescription claim request 202 and further based upon requirements of the service provider computer 104 and/or prior authorization assistance computer 108. For example, the service provider computer 104 and/or prior authorization assistance computer 108 may specify the required information, which may be the same or different depending upon the payor involved. Accordingly, a first portion of the required information may have been provided in the claim transaction request 202, and a second portion of the required information may be provided in the request 242, where the first and second portions collectively provide at least the required information. The request 242 for prior authorization assistance may be delivered by the service provider computer 104 to the prior authorization logic module 109.”
Also, (col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention”);
when the pre-approval conditions are met: automatically appending an approval data element to the claim transaction message to generate a PA approval message(col 21, line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”
Also, col 17, line 44 “Following block 612 is block 614. At block 614, the service provider computer 104 can generate a response 248, which may be responsive to the request 248. The response 248 may include a message that a request 253 for prior authorization assistance has been accepted by a prior authorization assistance computer 108. The response 248 may also include a message requesting that the pharmacy resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed. An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX if any questions remain."
Also, (col 13, line 11 “Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain." )
determining an identity of the remote computer device based on one or more data elements of the claim transaction message (col 13, line 27 “Following block 505 is block 506. At block 506, the service provider can generate a claim response 208, which may incorporate or append any messages (e.g., in a free-text message field) generated at block 505.” Note: Fig. 5, the response is delivered to Pharmacy computer, which sent the original request, thus based on message element (any message related information), the computer identity can be determined to send the response back.)
and transmitting the PA approval message to the remote computing device, wherein the remote computing device includes one of a pharmacy claims processor for further adjudication of the pharmacy claim transaction, to the originating pharmacy to fulfill the prescription, or to a healthcare claims clearinghouse for forwarding of the PA approval message to the pharmacy claims processor or to the originating pharmacy ( col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention”
Also, (col 4, line 15 “Second, the service provider computer 104 may include, but is not limited to, any processor-driven device that is configured for receiving, processing, and fulfilling requests from the pharmacy computer 103, the claims processor computer 106, and/or prior authorization assistance computer 108, relating to prescription, pharmacy, benefits, and/or healthcare transactions or other activities, including requests for prior authorization assistance.” Note: Also, see Fig. 5. Where the message is sent to remote computing device.));
and writing a new record to the reference database including an indication of whether the pharmacy claim transaction for the prescription satisfied the pre-approval conditions ((col 13, line 11 “Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain.)"
Also, col 4, line 47 “ The data files 134 may also store routing tables for determining the destination of communications received from pharmacy computer(s) 103 or claims processor computer(s) 106. The routing tables can also store destinations of available prior authorization assistance computer(s) 108. The host module 140 may receive, process, and respond to requests from the client module 152 of the pharmacy computer 103, and may further receive, process, and respond to requests from the host modules 172, 188 of respective claims processor computer 106 or prior authorization assistance computer 108. The database 182 may comprise one or more databases operable for storing information that supports facilitating claim resolution and/or the providing of prior authorization assistance, in accordance with an example embodiment of the invention. For example, the database 182 may store, perhaps in a history file or other similar list/record structure, transaction history records having information from one or more prescription claim transactions for which prior authorization assistance is eligible or for which prior authorization assistance has been facilitated, directed, or provided, according to an example embodiment of the invention.”)
col 10, line 23 “ At block 410, the prior authorization assistance logic module 109 may determine whether the drug or product identified in the prescription claim request 202 (e.g., by NDC number or drug/product name) is an eligible drug or product for prior authorization assistance. For example, an eligible drug or product may be determined by comparing an NDC number (or name of drug) of the prescription claim request 202 with a listing of eligible NDC numbers (or names of drugs). If block 410 determines that the drug or product identified by the prescription claim request 202 is not eligible, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 404 determines that the drug or product is eligible, then processing may proceed to block 412, where a determination that the prescription claim transaction is eligible for prior authorization assistance.”).
Pinsonneault does not explicitly teach:
[querying a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, and] jurisdictional regulations
[applying a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and ] the jurisdictional regulations, [the set of pre-approval rules defining pre-approval conditions for pharmacy PAs]
Allred teaches:
[querying a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, and] jurisdictional regulations(para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.”),
[applying a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and ] the jurisdictional regulations, [the set of pre-approval rules defining pre-approval conditions for pharmacy PAs] (para “[0018] According to some embodiments, receiving one or more prescription-related rules from the prescriber, and transmitting the medical prescription to a selected pharmacy is further based on the one or more prescription-related rules.”
Also, para “[0054]….. The prescription processing system may also further evaluate the pharmacy selection information and/or the selection input against one or more standing orders or prescription-based rules from the prescriber. For example, the selection input may be evaluated against a list of acceptable pharmacies for fulfillment in order to ensure that the selected pharmacy is approved by the prescriber. Alternatively, the system may utilize the list in addition to the pharmacy selection information in order to identify the one or more pharmacies for which to obtain cost data, thus ensuring that the selected pharmacy will be an approved pharmacy." Note: see para 0040 defining prescriber ID and NPI number.
Also, para “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.” )
It would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teachings of Allred into the teachings of Pinsonneault at the time the application was filed in order to handle prescription based on the jurisdictional restrictions. (para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. …”)
Regarding claim 2, Pinsonneault as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneault further teaches further comprising building the reference database based on prescriber reference data provided by the pharmacy claims processor(col 12, line 28 “The information included in the request 253 may be obtained from the prescription claim transaction, including the prescription claim request 202 and the claim response 203. In some example embodiments, the information included in the request 253 can be derived or obtained from other sources as well. For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. Generally, information included in the prescription claim transaction can be used to obtain or derive additional information from a variety of internal or external sources to the service provider computer 104 and/or the prior authorization logic module 109, according to an example embodiment of the invention.”)
Regarding claim 3, Pinsonneault as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneault further teaches, further comprising generating the set of pre-approval rules based on [jurisdictional regulations] and healthcare plan provisions provided by the pharmacy claims processor(col 9, line 38 “At block 404, the prior authorization assistance logic module 109 may determine whether the prescription claim transaction involves an eligible transaction type. For example, block 404 may determine an eligible transaction type based upon the prescription claim request 202 being of a "billing" type (e.g., Transaction code=B1). For a billing type transaction, block 404 may optionally determine an eligible transaction type by requiring that the prescription claim request 202 be a primary claim transaction, as opposed to a secondary claim transaction or coordination of benefits (COB) claim transaction. For example, block 404 may determine that the prescription claim request 202 is a primary claim request based upon the included Other Coverage Code (OCC) being of a particular value. If block 404 determines that the transaction type is not an eligible transaction type, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 404 determines that the transaction type is eligible, then processing may proceed to block 406.”
Also, col 16, line 46 “On the other hand, if block 606 determines that the required information for generating the request 253 is available, then processing may proceed to block 610. At block 610, the prior authorization logic module 109 and/or service provider computer 104 can generate a request 253 for prior authorization assistance. The request 253 can include one or more combinations of payor information, patient information, insurance/coverage information, healthcare provider information, claim information, and date of service, as previously described herein.
col9, line 20 “Turning now to FIG. 4, at block 402, the prior authorization assistance logic module 109 may determine whether the prescription claim transaction involves an eligible pharmacy. For example, block 404 may determine an eligible pharmacy by obtaining the pharmacy ID (or pharmacy name) from the prescription claim request 202, and then determining whether the pharmacy ID (or pharmacy name) matches a corresponding entry in a list of eligible pharmacy IDs (or pharmacy names).”)
Pinsonneault does not explicitly teaches further comprising [generating the set of pre-approval rules based on] jurisdictional regulations [and healthcare plan provisions provided by the pharmacy claims processor]( para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.”)
It would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teachings of Allred into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to handle prescription based on the jurisdictional restrictions. (para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. …”)
Regarding claim 4, Pinsonneault as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneault further teaches , further comprising:
when the pre-approval conditions are not met: automatically appending a PA initiation data element to the pharmacy claim transaction message to generate a PA initiation message col 13, line 11 “ Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance……”
Also, (col 13, line 27 “Following block 505 is block 506. At block 506, the service provider can generate a claim response 208, which may incorporate or append any messages (e.g., in a free-text message field) generated at block 505. The claim response 208 may be responsive to the prescription claim request 202. The claim response 208 may also include information (e.g., reject code, etc.) from the claim response 203 received from claim processor computer 106, according to an example embodiment of the invention. In addition, it will be appreciated that the response 208 may be further be stylized as either a "rejection" or "approval" based upon preferences of the pharmacy associated with the pharmacy computer 103. For example, if the pharmacy prefers a rejection, then the response 208 may be indicated as "rejected" and the rejection reason/code can be the same as the one from response 203 from the claims processor computer 106.” Also, see col 8 ) ;
and transmitting a PA rejection message to the pharmacy claims processor to initiate existing PA processing of the pharmacy claim transaction, or transmitting a message to the pharmacy claims processor that PA was rejected for the pharmacy claim transaction and that the pharmacy claim transaction was forwarded to an electronic PA vendor to initiate electronic PA processing of the pharmacy claim transaction by transmitting one or more PA forms to the prescriber(col 1, line 41 “preparing a second request for prior authorization assistance, the second request based at least in part on information from the stored transaction history record, wherein the second request identifies at least patient information, identification of the drug or product for the patient, and identification of the payor; delivering, to a prior authorization assistance computer, the second request for prior authorization assistance, wherein the information included in the second request enables the prior authorization assistance computer to initiate a process for completing a prior authorization form and for delivering the completed prior authorization form to the payor; and delivering, to the pharmacy computer, a response indicating acceptance of the first request for prior authorization assistance, wherein the response is stylized as a paid response or a rejection response based upon preferences of the pharmacy. One or more of the prior steps may be performed by one or more computers associated with a service provider.”)
Regarding claim 5, Pinsonneault as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneault further teaches further comprising assigning a transaction identifier associated with the pharmacy claim transaction, wherein the new record includes the transaction identifier(col 13, line 64 “Returning back to FIG. 3, block 309 could otherwise determine that standard processing is to be performed instead of express processing, and processing may proceed to block 310. At block 310, the service provider computer 104 and/or prior authorization assistance logic module 109 may store or direct the storage of a transaction history record of the prescription claim transaction in a history file or other list/record structure in the database 182, according to an example embodiment of the invention. An example transaction history record in the history file or similar list/record structure may include some or all of the following information: Payor ID: A name or BIN Number/PCN that is associated with a payor, Patient ID: An identifier for the patient such as the cardholder ID and/or group ID, or patient name, Drug/Product ID: an identifier of the drug or product, such as the NDC number, Pharmacy ID: an identifier of the pharmacy/pharmacy computer 102 originating the claim request, Quantity Dispensed: a dispensing quantity for the drug or product, Prescription (Rx)/Service Number, and/or Date of Service: a date identifying when the prescription was requested to be filled.”)
Regarding claim 6, Pinsonneault as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneault further teaches further comprising :
storing, in the reference database, for each respective prescriber of a plurality of prescribers including the prescriber, at least one of:
a number of PAs approved in a reference period of time before the pharmacy claim transaction was submitted, or a percentage of PAs approved in the reference period of time, for each respective prescribed product of a plurality of prescribed products, for each respective jurisdiction of a plurality of jurisdictions, and for respective provisions of each healthcare plan of a plurality of healthcare plans((col 10, line 40 “ It will be appreciated that example variations of FIG. 4 (and block 308 of FIG. 3) are available in accordance with an example embodiment of the invention. For example, one or more blocks of FIG. 4 may be omitted or varied. As another example, while FIG. 4 (and block 308 of FIG. 3) has been illustrated as a post-adjudication step, it will be appreciated that one or more blocks of FIG. 4 may also be performed as a pre-adjudication step. For example, with reference to FIG. 4, blocks 402, 404, 410 may be performed as a pre-adjudication step prior to the prescription claim request 202 being routed by the service provider computer 104 to the claims processor computer 106 as prescription claim request 203. On the other hand, blocks 406, 408 may remain a post-adjudication step that occurs after the claims processor computer 106 delivers the claim response 207 to the service provider computer 104/prior authorization assistance logic module 109.”
Also, col 17 , line 44 “Following block 612 is block 614. At block 614, the service provider computer 104 can generate a response 248, which may be responsive to the request 248. The response 248 may include a message that a request 253 for prior authorization assistance has been accepted by a prior authorization assistance computer 108. The response 248 may also include a message requesting that the pharmacy resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed. An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX if any questions remain."
Also, see (col 13, line 11 “Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain.")
Regarding claim 8, Pinsonneaultas modified by Allred teaches the computer-implemented method of claim 6.
Pinsonneaultas further teaches further comprising:
storing, in the reference database, the respective healthcare plan provisions for each of a plurality of healthcare plans, [the respective jurisdictional provisions for each of a plurality of jurisdictions], a national provider identifier, a plurality of prescription drug identifiers, a quantity, a quantity per days value, and a number of refills(col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention..”
Also, (col 12 , line 28 “The information included in the request 253 may be obtained from the prescription claim transaction, including the prescription claim request 202 and the claim response 203. In some example embodiments, the information included in the request 253 can be derived or obtained from other sources as well. For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database.”
(col 8, line 1 ”Healthcare Provider Information Prescriber Information Primary Care Provider ID or other identifier (e.g., NPI code) Primary Care Provider Name (e.g., Last Name, First Name) Prescriber ID or other identifier (e.g., NPI code, DEA number) Prescriber Name (e.g., Last Name, First Name) Prescriber Contact Information (e.g., Telephone Number, Email Address, Fax Number, etc.) Pharmacy/Pharmacist Provider Information Pharmacy/Pharmacist ID (e.g., National Provider Identifier (NPI) code) Pharmacy/Pharmacist Contact Information (e.g., Telephone Number, Email Address, Fax Number, etc.)”
Also, col 10, line 23 “ At block 410, the prior authorization assistance logic module 109 may determine whether the drug or product identified in the prescription claim request 202 (e.g., by NDC number or drug/product name) is an eligible drug or product for prior authorization assistance. “
Also, col 13, line 67 “At block 310, the service provider computer 104 and/or prior authorization assistance logic module 109 may store or direct the storage of a transaction history record of the prescription claim transaction in a history file or other list/record structure in the database 182, according to an example embodiment of the invention. An example transaction history record in the history file or similar list/record structure may include some or all of the following information:………, Drug/Product ID: an identifier of the drug or product, such as the NDC number, Pharmacy ID: an identifier of the pharmacy/pharmacy computer 102 originating the claim request, Quantity Dispensed: a dispensing quantity for the drug or product, Prescription (Rx)/Service Number, and/or Date of Service: a date identifying when the prescription was requested to be filled.”
(32) Claim Information Drug or product information (e.g., National Drug Code (NDC)) Prescription/Service Reference Number Date Prescription Written Quantity Dispensed Number of Days”);
and generating one or more pre-approval rules of the set of pre-approval rules based on the healthcare plan provisions(col 8, line 62 “ At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention.”)
Allred further teaches [storing, in the reference database, the respective healthcare plan provisions for each of a plurality of healthcare plans,] the respective jurisdictional provisions for each of a plurality of jurisdictions, [a national provider identifier, a plurality of prescription drug identifiers, a quantity, a quantity per days value, and a number of refills](para, “[0064] As discussed herein, the prescription processing system 705 may be prohibited from directly transferring a prescription electronically to a pharmacy. For example, as discussed herein, the prescription processing system 705 may be registered as a pharmacy (e.g., a “holding pharmacy”) and may thus be subject to jurisdiction-specific regulations for transfers of prescriptions between pharmacies. Accordingly, the routing entity 730 may interface with the prescriber module 710 to receive possession of the medical prescription therefrom and retain the prescription until a pharmacy is identified for transmission. The routing entity 730, as a non-pharmacy entity, may then transfer the prescription into the possession of the selected pharmacy (i.e., the corresponding pharmacy module 720).”
Also, para “[0039] FIG. 2 depicts an information flow diagram for the network 100 according to an embodiment. As shown in FIG. 2, the system 105 may receive and/or store various types of data 205-230 as described herein from the external modules. Further, the system 105 may transmit the various types of data 205-230 to any of the external modules.”
It would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teachings of Allred into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to handle prescription based on the jurisdictional restrictions. (para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. …”)
Regarding claim 9, Pinsonneaultas as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneaultas further teaches further comprising updating the prescriber reference data with the new record(col 13, line 11 “Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain.)"
Also, col 4, line 47 “ The data files 134 may also store routing tables for determining the destination of communications received from pharmacy computer(s) 103 or claims processor computer(s) 106. The routing tables can also store destinations of available prior authorization assistance computer(s) 108. The host module 140 may receive, process, and respond to requests from the client module 152 of the pharmacy computer 103, and may further receive, process, and respond to requests from the host modules 172, 188 of respective claims processor computer 106 or prior authorization assistance computer 108. The database 182 may comprise one or more databases operable for storing information that supports facilitating claim resolution and/or the providing of prior authorization assistance, in accordance with an example embodiment of the invention. For example, the database 182 may store, perhaps in a history file or other similar list/record structure, transaction history records having information from one or more prescription claim transactions for which prior authorization assistance is eligible or for which prior authorization assistance has been facilitated, directed, or provided, according to an example embodiment of the invention.”)
Also, col 10, line 23 “ At block 410, the prior authorization assistance logic module 109 may determine whether the drug or product identified in the prescription claim request 202 (e.g., by NDC number or drug/product name) is an eligible drug or product for prior authorization assistance. For example, an eligible drug or product may be determined by comparing an NDC number (or name of drug) of the prescription claim request 202 with a listing of eligible NDC numbers (or names of drugs). If block 410 determines that the drug or product identified by the prescription claim request 202 is not eligible, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 404 determines that the drug or product is eligible, then processing may proceed to block 412, where a determination that the prescription claim transaction is eligible for prior authorization assistance.”).
Regarding claim 11, Pinsonneaultas modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneaultas further teaches further comprising monitoring, for the prescriber, a progress toward at least one prescriber approved status using the prescriber reference data(col 13, line 17 “Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain.")
Regarding claim 12, Pinsonneault teaches :
A prior authorization pre-approval (paPA) computing device, the paPA computing device comprising at least one processor in communication with at least one memory device storing computer-executable instructions that, when executed by the at least one processor, cause the at least one processor to (see Fig. 2, col 1 ):
receive via a remote computing device, a claim transaction message associated with a pharmacy claim transaction for a prescription that has satisfied a prior authorization (PA) trigger condition( col 7, line 33 “Turning now to block 302 of FIG. 3, a pharmacy computer 103 may submit a prescription claim request 202 to the service provider computer 104. Accordingly, the service provider computer 104 may receive the prescription claim request 202 at block 302.......”)
the claim transaction message including (i) a plan identifier associated with a healthcare plan under which the prescription is submitted at an originating pharmacy, and (ii) a prescriber identifier associated with a prescriber of the prescription(col 12, line 28”The information included in the request 253 may be obtained from the prescription claim transaction, including the prescription claim request 202 and the claim response 203. In some example embodiments, the information included in the request 253 can be derived or obtained from other sources as well. For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. “
Also, col 13, line 67 “At block 310, the service provider computer 104 and/or prior authorization assistance logic module 109 may store or direct the storage of a transaction history record of the prescription claim transaction in a history file or other list/record structure in the database 182, according to an example embodiment of the invention. An example transaction history record in the history file or similar list/record structure may include some or all of the following information: Payor ID: A name or BIN Number/PCN that is associated with a payor, Patient ID: An identifier for the patient such as the cardholder ID and/or group ID, or patient name, Drug/Product ID: an identifier of the drug or product, such as the NDC number, Pharmacy ID: an identifier of the pharmacy/pharmacy computer 102 originating the claim request, Quantity Dispensed: a dispensing quantity for the drug or product, Prescription (Rx)/Service Number, and/or Date of Service: a date identifying when the prescription was requested to be filled.);
query a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, [and jurisdictional regulations] ( col 12, line 33 “For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. “
Also, col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention.”);
apply a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and [the jurisdictional regulations], the set of pre-approval rules defining pre-approval conditions for pharmacy PAs(col 9, line 20Turning now to FIG. 4, at block 402, the prior authorization assistance logic module 109 may determine whether the prescription claim transaction involves an eligible pharmacy. For example, block 404 may determine an eligible pharmacy by obtaining the pharmacy ID (or pharmacy name) from the prescription claim request 202, and then determining whether the pharmacy ID (or pharmacy name) matches a corresponding entry in a list of eligible pharmacy IDs (or pharmacy names). To be included on the list, a pharmacy may have previously registered with a service provider for prior authorization assistance, according to an example embodiment of the invention. If block 402 determines that the pharmacy is not an eligible pharmacy, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 402 determines that the pharmacy is an eligible pharmacy, then processing may proceed to block 404.”
Also, col 15, line 37 “In addition, the request 242 for prior authorization assistance can further include additional information associated with the patient, payor (e.g., insurer), or healthcare provider (e.g., prescriber, pharmacist, etc.). It will be appreciated that any additional information required may be based upon what information was already provided in the prior prescription claim request 202 and further based upon requirements of the service provider computer 104 and/or prior authorization assistance computer 108. For example, the service provider computer 104 and/or prior authorization assistance computer 108 may specify the required information, which may be the same or different depending upon the payor involved. Accordingly, a first portion of the required information may have been provided in the claim transaction request 202, and a second portion of the required information may be provided in the request 242, where the first and second portions collectively provide at least the required information. The request 242 for prior authorization assistance may be delivered by the service provider computer 104 to the prior authorization logic module 109.”
Also, col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention”);
when the pre-approval conditions are met: automatically append an approval data element to the claim transaction message to generate a PA approval message( col 21, line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”
Also, col 17, line 44 Following block 612 is block 614. At block 614, the service provider computer 104 can generate a response 248, which may be responsive to the request 248. The response 248 may include a message that a request 253 for prior authorization assistance has been accepted by a prior authorization assistance computer 108. The response 248 may also include a message requesting that the pharmacy resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed. An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX if any questions remain."
Also, col 13, line 11 Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain." );
determine an identity of the remote computer device based on one or more data elements of the claim transaction message (col 13, line 27 “Following block 505 is block 506. At block 506, the service provider can generate a claim response 208, which may incorporate or append any messages (e.g., in a free-text message field) generated at block 505.” Note: Fig. 5, the response is delivered to Pharmacy computer, that sent the original request, thus based on message element (any message related information), the computer identity can be determined to send the response back.)
and transmit the PA approval message to the remote computing device, wherein the remote computing device includes one of a pharmacy claims processor for further adjudication of the pharmacy claim transaction, to the originating pharmacy to fulfill the prescription, or to a healthcare claims clearinghouse for forwarding of the PA approval message to the pharmacy claims processor or to the originating pharmacy(col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention”
Also, col 4, line 15 “Second, the service provider computer 104 may include, but is not limited to, any processor-driven device that is configured for receiving, processing, and fulfilling requests from the pharmacy computer 103, the claims processor computer 106, and/or prior authorization assistance computer 108, relating to prescription, pharmacy, benefits, and/or healthcare transactions or other activities, including requests for prior authorization assistance.” Note: Also, see Fig. 5. Where the message is sent to remote computing device.);
and write a new record to the reference database including an indication of whether the pharmacy claim transaction for the prescription satisfied the pre-approval conditions(col 13, line 11 “Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain.)"
Also, col 4, line 47 “ The data files 134 may also store routing tables for determining the destination of communications received from pharmacy computer(s) 103 or claims processor computer(s) 106. The routing tables can also store destinations of available prior authorization assistance computer(s) 108. The host module 140 may receive, process, and respond to requests from the client module 152 of the pharmacy computer 103, and may further receive, process, and respond to requests from the host modules 172, 188 of respective claims processor computer 106 or prior authorization assistance computer 108. The database 182 may comprise one or more databases operable for storing information that supports facilitating claim resolution and/or the providing of prior authorization assistance, in accordance with an example embodiment of the invention. For example, the database 182 may store, perhaps in a history file or other similar list/record structure, transaction history records having information from one or more prescription claim transactions for which prior authorization assistance is eligible or for which prior authorization assistance has been facilitated, directed, or provided, according to an example embodiment of the invention.”)
col 10, line 23 “ At block 410, the prior authorization assistance logic module 109 may determine whether the drug or product identified in the prescription claim request 202 (e.g., by NDC number or drug/product name) is an eligible drug or product for prior authorization assistance. For example, an eligible drug or product may be determined by comparing an NDC number (or name of drug) of the prescription claim request 202 with a listing of eligible NDC numbers (or names of drugs). If block 410 determines that the drug or product identified by the prescription claim request 202 is not eligible, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 404 determines that the drug or product is eligible, then processing may proceed to block 412, where a determination that the prescription claim transaction is eligible for prior authorization assistance.”).
Pinsonneault does not explicitly teach :
[query a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, and] jurisdictional regulations,
[apply a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and] the jurisdictional regulations, [the set of pre-approval rules defining pre-approval conditions for pharmacy PAs]
Allred teaches :
[query a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, and] jurisdictional regulations(para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.”),
[apply a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and] the jurisdictional regulations, [the set of pre-approval rules defining pre-approval conditions for pharmacy PAs] (para “[0018] According to some embodiments, receiving one or more prescription-related rules from the prescriber, and transmitting the medical prescription to a selected pharmacy is further based on the one or more prescription-related rules.”
Also, para “[0054]….. The prescription processing system may also further evaluate the pharmacy selection information and/or the selection input against one or more standing orders or prescription-based rules from the prescriber. For example, the selection input may be evaluated against a list of acceptable pharmacies for fulfillment in order to ensure that the selected pharmacy is approved by the prescriber. Alternatively, the system may utilize the list in addition to the pharmacy selection information in order to identify the one or more pharmacies for which to obtain cost data, thus ensuring that the selected pharmacy will be an approved pharmacy." Note: see para 0040 defining prescriber ID and NPI number.
Also, para “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.” )
It would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teachings of Allred into the teachings of Pinsonneault at the time the application was filed in order to handle prescription based on the jurisdictional restrictions. (para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. …”)
Regarding claim 13, Pinsonneault as modified by Allred teaches paPA computing device of Claim 12.
Pinsonneault further teaches, wherein the healthcare claims clearinghouse is one of a pharmacy switch server or a medical claims clearinghouse( col 4, line 25 “The service provider computer 104 may include, but is not limited to, a server computer, a mainframe computer, one or more networked computers, or any other processor-based device. According to an example embodiment of the invention, the service provider computer 104 may comprise, but is not limited to, one or more "switches" or "switch providers" performing routing and processing (e.g., pre- and post-routing editing) of transactions relating to prescription claims and/or prior authorization assistance requests between or among pharmacies, payors/claims processors, prior authorization assistance entities, and/or other service providers.” )
Regarding claim 14, Pinsonneault as modified by Allred teaches paPA computing device of Claim 12.
Pinsonneault further teaches wherein the computer- executable instructions further cause the processor to generate the set of pre-approval rules based on [jurisdictional regulations] and healthcare plan provisions provided by the pharmacy claims processor(col 9, line 38 “At block 404, the prior authorization assistance logic module 109 may determine whether the prescription claim transaction involves an eligible transaction type. For example, block 404 may determine an eligible transaction type based upon the prescription claim request 202 being of a "billing" type (e.g., Transaction code=B1). For a billing type transaction, block 404 may optionally determine an eligible transaction type by requiring that the prescription claim request 202 be a primary claim transaction, as opposed to a secondary claim transaction or coordination of benefits (COB) claim transaction. For example, block 404 may determine that the prescription claim request 202 is a primary claim request based upon the included Other Coverage Code (OCC) being of a particular value. If block 404 determines that the transaction type is not an eligible transaction type, then processing may proceed to block 409, where a determination is made that the prescription claim transaction is not eligible for prior authorization assistance. On the other hand, if block 404 determines that the transaction type is eligible, then processing may proceed to block 406.”
col9, line 20 “Turning now to FIG. 4, at block 402, the prior authorization assistance logic module 109 may determine whether the prescription claim transaction involves an eligible pharmacy. For example, block 404 may determine an eligible pharmacy by obtaining the pharmacy ID (or pharmacy name) from the prescription claim request 202, and then determining whether the pharmacy ID (or pharmacy name) matches a corresponding entry in a list of eligible pharmacy IDs (or pharmacy names).”)
Also, col 16, line 46 “On the other hand, if block 606 determines that the required information for generating the request 253 is available, then processing may proceed to block 610. At block 610, the prior authorization logic module 109 and/or service provider computer 104 can generate a request 253 for prior authorization assistance. The request 253 can include one or more combinations of payor information, patient information, insurance/coverage information, healthcare provider information, claim information, and date of service, as previously described herein. The information included in the request 253 may be obtained from the request 242 and/or the identified stored transaction history record. In some example embodiments, the information included in the request 253 can be derived or obtained from other sources as well. Generally, information included in the request 242 and/or stored transaction history record can be used to obtain or derive additional information from a variety of internal or external sources to the service provider computer 104 and/or the prior authorization logic module 109, according to an example embodiment of the invention.”)
Pinsonneault does not explicitly teaches further comprising [generating the set of pre-approval rules based on] jurisdictional regulations [and healthcare plan provisions provided by the pharmacy claims processor]( para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.”)
It would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teachings of Allred into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to handle prescription based on the jurisdictional restrictions. (para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. …”)
Regarding claim 15, Pinsonneault as modified by Allred teaches paPA computing device of Claim 12.
Pinsonneault further teaches wherein the computer- executable instructions further cause the processor to:
when the pre-approval conditions are not met: automatically append a PA initiation data element to the claim transaction message to generate a PA initiation message(col 13, line 11 “Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance……”
Also, col 13, line 27 “Following block 505 is block 506. At block 506, the service provider can generate a claim response 208, which may incorporate or append any messages (e.g., in a free-text message field) generated at block 505. The claim response 208 may be responsive to the prescription claim request 202. The claim response 208 may also include information (e.g., reject code, etc.) from the claim response 203 received from claim processor computer 106, according to an example embodiment of the invention. In addition, it will be appreciated that the response 208 may be further be stylized as either a "rejection" or "approval" based upon preferences of the pharmacy associated with the pharmacy computer 103. For example, if the pharmacy prefers a rejection, then the response 208 may be indicated as "rejected" and the rejection reason/code can be the same as the one from response 203 from the claims processor computer 106.” Also, see col 8);
and transmit a PA rejection message to the pharmacy claims processor to initiate existing PA processing of the pharmacy claim transaction, or transmitting a message to the pharmacy claims processor that PA was rejected for the pharmacy claim transaction and that the pharmacy claim transaction to an electronic PA vendor to initiate electronic PA processing of the pharmacy claim transaction by transmitting one or more PA forms to the prescriber( col 20, line 35 “In an example embodiment of the invention, the completed prior authorization form can be delivered as soon as it has been completed, or it may be batched with other completed prior authorization forms and delivered on a periodic basis to the claims processor computer 108 or another computer associated with the payor. The delivery of the completed prior authorization form can be via email, FTP or other Internet delivery, fax, EDI transmissions, or via other electronic communications means. Alternatively, the completed prior authorization form may be delivered from the prior authorization assistance entity to a payor through non-electronic communications means (e.g., paper delivery) without departing from example embodiments of the invention.”)
Regarding claim 16, Pinsonneault as modified by Allred teaches paPA computing device of Claim 12.
Pinsonneault further teaches wherein the computer- executable instructions further cause the processor to assign a transaction identifier associated with the pharmacy claim transaction, wherein the new record includes the transaction identifier col 13, line 64 “Returning back to FIG. 3, block 309 could otherwise determine that standard processing is to be performed instead of express processing, and processing may proceed to block 310. At block 310, the service provider computer 104 and/or prior authorization assistance logic module 109 may store or direct the storage of a transaction history record of the prescription claim transaction in a history file or other list/record structure in the database 182, according to an example embodiment of the invention. An example transaction history record in the history file or similar list/record structure may include some or all of the following information: Payor ID: A name or BIN Number/PCN that is associated with a payor, Patient ID: An identifier for the patient such as the cardholder ID and/or group ID, or patient name, Drug/Product ID: an identifier of the drug or product, such as the NDC number, Pharmacy ID: an identifier of the pharmacy/pharmacy computer 102 originating the claim request, Quantity Dispensed: a dispensing quantity for the drug or product, Prescription (Rx)/Service Number, and/or Date of Service: a date identifying when the prescription was requested to be filled.”)
Regarding claim 19, Pinsonneault as modified by Allred teaches paPA computing device of Claim 12.
Pinsonneault further teaches wherein the computer- executable instructions further cause the processor to, when the pre-approval conditions are met, assign a prescriber approved status to the prescriber reference data(col 21, line 6 “ Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”).
Claims 7, 10 ,17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pinsonneault as modified by Allred and in view of Smith (US 20230058048 A1)
Regarding claim 7, Pinsonneaultas modified by Allred teaches the computer-implemented method of claim 6.
Pinsonneaultas as modified by Allred does not explicitly teach storing, in the reference database, a pre-approval rule of the set of pre-approval rules defining a minimum threshold number of PAs approved or a minimum percentage of PAs approved as established using at least one of the healthcare plan provisions or jurisdictional regulations.
Smith teaches storing, in the reference database, a pre-approval rule of the set of pre-approval rules defining a minimum threshold number of PAs approved or a minimum percentage of PAs approved as established using at least one of the healthcare plan provisions or jurisdictional regulations(para, “[0028] In some embodiments, when an approval rate for claims 107 requiring prior authorization requests 114 for a particular specialty drug falls below a threshold percentage for a provider 101, the training engine 123 may schedule training for the associated provider 101. The training may be training on how to best complete the paperwork associated with the prior authorization request 114 for the specialty drug so that the approval rate for claims 107 for the specialty drug increases. Alternatively, the training engine 123 may schedule training when the total number of claim 107 denials due to prior authorization requests 114 passes a threshold number. The threshold percentage or threshold number that triggers training may be provided by the manufacturer 103 associated with the specialty drug.”
Also, para “[0027] Returning to FIG. 1, the training engine 123 may monitor the various metrics associated with claims 107 and specifically the rate of claim 107 denial due to missing or incomplete prior authorization requests 114. The metrics that trigger training for each specialty drug and/or manufacturer 103, as well as the type and form of training, may be stored by the training engine 121 as part of the training data 116.”)
It would have been obvious for a person of ordinary skill in the art to apply minimum threshold teachings of Smith into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to increase the rate of approval. (Abstract, “A system for increasing the rate of claim approval for specialty drugs is provided. The system monitors the approval and disapproval rates for claims related to specialty medications for multiple providers (e.g., pharmacies) due to missing or incomplete prior authorization requests….”)
Regarding claim 10, Pinsonneaultas as modified by Allred teaches the computer-implemented method of claim 1.
Pinsonneaultas further teaches:
wherein the pharmacy claim transaction is a first pharmacy claim transaction, the method further comprising(col 1, line 29 “ According to another example embodiment of the invention, there is a system. The system may include at least one memory for storing computer-executable instructions; and at least one processor configured to access the at least one memory. The at least one processor may be configured to execute the computer-executable instructions to: receive a first request for prior authorization assistance from a pharmacy computer associated with a pharmacy, wherein the request for prior authorization assistance includes claim identification information for a prior healthcare claim transaction;),
when the pre-approval conditions are met, assigning a prescriber approved status to the prescriber reference data(col 21, line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”);
and receiving a second claim transaction message associated with a second pharmacy claim transaction for a prescription for a same prescribed product as the first pharmacy claim transaction and prescribed by the same prescriber as the first pharmacy claim transaction(col 21, line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”)
Also, col 1, line 34 “identify a stored transaction history record for the prior healthcare claim transaction, wherein the stored transaction record is identified based at least in part on the claim identification information from the request for prior authorization assistance, wherein the stored transaction history record indicates a denial of coverage by a payor of a drug or product for a patient; prepare a second request for prior authorization assistance, the second request based at least in part on information from the stored transaction history record, wherein the second request identifies at least patient information, identification of the drug or product for the patient, and identification of the payor; deliver, to a prior authorization assistance computer, the second request for prior authorization assistance, wherein the information included in the second request enables the prior authorization assistance computer to initiate a process for completing a prior authorization form and for delivering the completed prior authorization form to the payor”);
querying the reference database with the prescriber identifier to access the prescriber reference data associated with the prescriber](col 12, line 33 “ For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. “);
and automatically appending an approval data element to the second claim transaction message to generate a second PA approval message)(col 21, line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”
Also, col 17, line 33 “ Following block 612 is block 614. At block 614, the service provider computer 104 can generate a response 248, which may be responsive to the request 248. The response 248 may include a message that a request 253 for prior authorization assistance has been accepted by a prior authorization assistance computer 108. The response 248 may also include a message requesting that the pharmacy resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed. An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX if any questions remain."
Also, col 13, line 11 “ Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain." )
Pinsonneaultas as modified by Allred does not explicitly teach :
detecting the prescribed approved status in the prescriber reference data.
Smith teaches:
detecting the prescribed approved status in the prescriber reference data.(para, “[0026] FIG. 2 is an illustration of a graphical user interface (GUI) 200 that may be used to implement the portal 123. As shown, the GUI 200 may provide a variety of metrics regarding prior authorizations (PAs) for various drugs associated with a drug manufacturer 103. In the example shown, the GUI 200 is being used to view metrics for each drug including total number of claims 107 received, the total number of claims 107 accepted (paid), and the total number of claims 107 that have been rejected due to missing or incomplete prior authorization requests 114. The GUI 200 may be further used to show metrics related to individual providers 101 (pharmacies), prescribers (physicians), and to select the particular drugs that are tracked for the manufacturer 103. As will be discussed further below, in some embodiments, the manufacturers 103 may be able to schedule training for a particular provider 101 through the GUI 200.”
Also, para , “[0028] In some embodiments, when an approval rate for claims 107 requiring prior authorization requests 114 for a particular specialty drug falls below a threshold percentage for a provider 101, the training engine 123 may schedule training for the associated provider 101. The training may be training on how to best complete the paperwork associated with the prior authorization request 114 for the specialty drug so that the approval rate for claims 107 for the specialty drug increases. Alternatively, the training engine 123 may schedule training when the total number of claim 107 denials due to prior authorization requests 114 passes a threshold number. The threshold percentage or threshold number that triggers training may be provided by the manufacturer 103 associated with the specialty drug.”
It would have been obvious for a person of ordinary skill in the art to apply minimum threshold teachings of Smith into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to increase the rate of approval. (Abstract, “A system for increasing the rate of claim approval for specialty drugs is provided. The system monitors the approval and disapproval rates for claims related to specialty medications for multiple providers (e.g., pharmacies) due to missing or incomplete prior authorization requests….”)
Regarding claim 17, Pinsonneault as modified by Allred teaches paPA computing device of Claim 12.
Pinsonneaultas further teaches wherein the computer- executable instructions further cause the processor to:
store, in the reference database, for each respective prescriber of a plurality of prescribers including the prescriber, at least one of: a number of PAs approved in a reference period of time before the pharmacy claim transaction was submitted, or a percentage of PAs approved in the reference period of time, for each respective prescribed product of a plurality of prescribed products, for each respective jurisdiction of a plurality of jurisdictions, and for respective provisions of each healthcare plan of a plurality of healthcare plans.(col 10, line 40 “ It will be appreciated that example variations of FIG. 4 (and block 308 of FIG. 3) are available in accordance with an example embodiment of the invention. For example, one or more blocks of FIG. 4 may be omitted or varied. As another example, while FIG. 4 (and block 308 of FIG. 3) has been illustrated as a post-adjudication step, it will be appreciated that one or more blocks of FIG. 4 may also be performed as a pre-adjudication step. For example, with reference to FIG. 4, blocks 402, 404, 410 may be performed as a pre-adjudication step prior to the prescription claim request 202 being routed by the service provider computer 104 to the claims processor computer 106 as prescription claim request 203. On the other hand, blocks 406, 408 may remain a post-adjudication step that occurs after the claims processor computer 106 delivers the claim response 207 to the service provider computer 104/prior authorization assistance logic module 109.”
Also, col 17, line 33 “ Following block 612 is block 614. At block 614, the service provider computer 104 can generate a response 248, which may be responsive to the request 248. The response 248 may include a message that a request 253 for prior authorization assistance has been accepted by a prior authorization assistance computer 108. The response 248 may also include a message requesting that the pharmacy resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed. An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX if any questions remain."
Also, see col 13, line 11 “ Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain.");
Pinsonneaultas modified by Allred does not explicitly teach:
and store, in the reference database, a pre-approval rule of the set of pre- approval rules defining a minimum threshold number of PAs approved or a minimum percentage of PAs approved as established by at least one of the healthcare plan provisions or jurisdictional regulations.
Smith teaches:
and store, in the reference database, a pre-approval rule of the set of pre- approval rules defining a minimum threshold number of PAs approved or a minimum percentage of PAs approved as established by at least one of the healthcare plan provisions or jurisdictional regulations(para, “[0028] In some embodiments, when an approval rate for claims 107 requiring prior authorization requests 114 for a particular specialty drug falls below a threshold percentage for a provider 101, the training engine 123 may schedule training for the associated provider 101. The training may be training on how to best complete the paperwork associated with the prior authorization request 114 for the specialty drug so that the approval rate for claims 107 for the specialty drug increases. Alternatively, the training engine 123 may schedule training when the total number of claim 107 denials due to prior authorization requests 114 passes a threshold number. The threshold percentage or threshold number that triggers training may be provided by the manufacturer 103 associated with the specialty drug.”
Also, para “[0027] Returning to FIG. 1, the training engine 123 may monitor the various metrics associated with claims 107 and specifically the rate of claim 107 denial due to missing or incomplete prior authorization requests 114. The metrics that trigger training for each specialty drug and/or manufacturer 103, as well as the type and form of training, may be stored by the training engine 121 as part of the training data 116.”)
It would have been obvious for a person of ordinary skill in the art to apply minimum threshold teachings of Smith into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to increase the rate of approval. (Abstract, “A system for increasing the rate of claim approval for specialty drugs is provided. The system monitors the approval and disapproval rates for claims related to specialty medications for multiple providers (e.g., pharmacies) due to missing or incomplete prior authorization requests….”)
Regarding claim 18, Pinsonneault as modified by Allred and Smith teaches paPA computing device of Claim 17.
Pinsonneaultas further teaches wherein the computer- executable instructions further cause the processor to:
store, in the reference database, the respective healthcare plan provisions for each of a plurality of healthcare plans, [the respective jurisdictional provisions for each of a plurality of jurisdictions], a national provider identifier, a plurality of prescription drug identifiers, a quantity, a quantity per days value, and a number of refills; (col 8, line 53 “At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention..”
Also, col 12, line 28 “The information included in the request 253 may be obtained from the prescription claim transaction, including the prescription claim request 202 and the claim response 203. In some example embodiments, the information included in the request 253 can be derived or obtained from other sources as well. For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database.”
Col 8, line 1 “ Healthcare Provider Information Prescriber Information Primary Care Provider ID or other identifier (e.g., NPI code) Primary Care Provider Name (e.g., Last Name, First Name) Prescriber ID or other identifier (e.g., NPI code, DEA number) Prescriber Name (e.g., Last Name, First Name) Prescriber Contact Information (e.g., Telephone Number, Email Address, Fax Number, etc.) Pharmacy/Pharmacist Provider Information Pharmacy/Pharmacist ID (e.g., National Provider Identifier (NPI) code) Pharmacy/Pharmacist Contact Information (e.g., Telephone Number, Email Address, Fax Number, etc.)”
(col 10, line 23 “At block 410, the prior authorization assistance logic module 109 may determine whether the drug or product identified in the prescription claim request 202 (e.g., by NDC number or drug/product name) is an eligible drug or product for prior authorization assistance. “
Col 13, line 64 “At block 310, the service provider computer 104 and/or prior authorization assistance logic module 109 may store or direct the storage of a transaction history record of the prescription claim transaction in a history file or other list/record structure in the database 182, according to an example embodiment of the invention. An example transaction history record in the history file or similar list/record structure may include some or all of the following information:………, Drug/Product ID: an identifier of the drug or product, such as the NDC number, Pharmacy ID: an identifier of the pharmacy/pharmacy computer 102 originating the claim request, Quantity Dispensed: a dispensing quantity for the drug or product, Prescription (Rx)/Service Number, and/or Date of Service: a date identifying when the prescription was requested to be filled.”
(32) Claim Information Drug or product information (e.g., National Drug Code (NDC)) Prescription/Service Reference Number Date Prescription Written Quantity Dispensed Number of Days”);
generate one or more pre-approval rules of the set of pre-approval rules based on the healthcare plan provisions col 8, line 53 “ At block 306, the claims processor computer 106 may adjudicate the prescription claim request 203 and generate a claim response 207. The claim response 207 may indicate an approval of coverage and include financial coverage information that specifies a payor-covered amount (e.g., an insured amount) and a patient-responsible amount (e.g., a co-pay or coinsurance amount). Alternatively, the claim response 207 may indicate a denial of coverage for the prescription claim 203, which indicates no coverage by a payor. For a denial of coverage, the claim response 207 may include one or more denial reasons or reject codes. As an example, in accordance with an NCPDP Telecommunication Standard, an example reject code may be one or more of the following codes: (i) Reject Code="70" (Product/Service not covered), (ii) Reject Code="75" (Prior Authorization Required), or (iii) Reject Code="76" (Plan Limitation Exceeded). Many other possible reject codes are available without departing from example embodiments of the invention.”);
Allred further teaches:
[store, in the reference database, the respective healthcare plan provisions for each of a plurality of healthcare plans,] the respective jurisdictional provisions for each of a plurality of jurisdictions, [a national provider identifier, a plurality of prescription drug identifiers, a quantity, a quantity per days value, and a number of refills] para, “[0064] As discussed herein, the prescription processing system 705 may be prohibited from directly transferring a prescription electronically to a pharmacy. For example, as discussed herein, the prescription processing system 705 may be registered as a pharmacy (e.g., a “holding pharmacy”) and may thus be subject to jurisdiction-specific regulations for transfers of prescriptions between pharmacies. Accordingly, the routing entity 730 may interface with the prescriber module 710 to receive possession of the medical prescription therefrom and retain the prescription until a pharmacy is identified for transmission. The routing entity 730, as a non-pharmacy entity, may then transfer the prescription into the possession of the selected pharmacy (i.e., the corresponding pharmacy module 720).”
Also, para “[0039] FIG. 2 depicts an information flow diagram for the network 100 according to an embodiment. As shown in FIG. 2, the system 105 may receive and/or store various types of data 205-230 as described herein from the external modules. Further, the system 105 may transmit the various types of data 205-230 to any of the external modules.”)
and generate one or more pre-approval rules of the set of pre-approval rules based on the jurisdictional regulations(para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. In some transactions, the routing entity 730 may receive the prescription from the prescriber module 710 and transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are prohibited). In other transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and directly transfer the prescription to the pharmacy module 720 (e.g., in jurisdictions where pharmacy-to-pharmacy electronic transfers of prescriptions are permitted), thereby completing the transfer without involvement of the routing entity 730. In additional transactions, the prescription processing system 705 may receive the prescription directly from the prescriber module 710 and transfer the prescription to the routing entity 730. The routing entity 730 may then transfer the prescription to the pharmacy module 720 under instruction from the prescription processing system 705.”
It would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teachings of Allred into the teachings of Pinsonneault as modified by Allred and Smith at the time the application was filed in order to handle prescription based on the jurisdictional restrictions. (para, “[0069] In some embodiments, the network 700 may handle prescriptions in various manners based on the jurisdictional restrictions applicable to each transaction. …”)
Regarding claim 20, Pinsonneault as modified by Allred teaches paPA computing device of Claim 19.
Pinsonneault further teaches wherein the pharmacy claim transaction is a first pharmacy claim transaction, and wherein the computer- executable instructions further cause the processor to:
receive a second claim transaction message associated with a second pharmacy claim transaction for a prescription for a same prescribed product as the first pharmacy claim transaction and prescribed by the same prescriber as the first pharmacy claim transaction(col 21, line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”)
Also, col 1, line 34 “identify a stored transaction history record for the prior healthcare claim transaction, wherein the stored transaction record is identified based at least in part on the claim identification information from the request for prior authorization assistance, wherein the stored transaction history record indicates a denial of coverage by a payor of a drug or product for a patient; prepare a second request for prior authorization assistance, the second request based at least in part on information from the stored transaction history record, wherein the second request identifies at least patient information, identification of the drug or product for the patient, and identification of the payor; deliver, to a prior authorization assistance computer, the second request for prior authorization assistance, wherein the information included in the second request enables the prior authorization assistance computer to initiate a process for completing a prior authorization form and for delivering the completed prior authorization form to the payor”);
query the reference database with the prescriber identifier to access the prescriber reference data associated with the prescriber](col 12, line 33 “For example, healthcare provider information, including addresses and contact information, can be obtained from a healthcare provider database or listing that includes the addresses and contact information for various healthcare providers. Accordingly, an identifier such as a prescriber ID or a pharmacy/pharmacist ID from the prescription claim transaction can be used to obtain additional information from a healthcare provider database. “);
and automatically append an approval data element to the second claim transaction message to generate a second PA approval message(col 21 , line 6 “Once the prior authorization requested by the completed prior authorization form has been completed, then a pharmacy computer 102 can submit another prescription claim request 202 to the service provider computer 104, which in turn communicates the request to the claims processor computer as a request 203. Since the prior authorization for a particular drug or product for the patient has been approved, the claims processor computer 106 will provide a response 207 indicating approval of coverage. The response 207 will include the payor-covered amount as well as any patient-responsible amount. The service provider computer 104 may receive the response 207, and likewise communicate the response 207 to the pharmacy computer 103 as a response 103. The pharmacy can deliver the requested drug or product to the patient/customer at the pharmacy upon payment of any patient-responsible amount.”
Also, (col 17, line 44 “ Following block 612 is block 614. At block 614, the service provider computer 104 can generate a response 248, which may be responsive to the request 248. The response 248 may include a message that a request 253 for prior authorization assistance has been accepted by a prior authorization assistance computer 108. The response 248 may also include a message requesting that the pharmacy resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed. An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX if any questions remain."
Also, col 13, line 11 “ Following block 504 is block 505, where one or more messages can be generated for appending to any response delivered according to block 506 below. According to an embodiment, the message can indicate that the request 253 was not accepted by the prior authorization assistance computer 108, and may further identify one or more reasons for the non-acceptance. Alternatively, the message that the request 253 has been accepted by or delivered to a prior authorization assistance computer 108. The message can also instruct the pharmacy to resubmit a claim request 202 in X days or Y hours when the prior authorization assistance process is expected to have been completed (e.g., prior authorization for a drug/product for a patient approved by a payor). An example message may be: "Prior Authorization Request Accepted. Resubmit prescription billing request in 48 hours. Call 1-XXX-XXX-XXXX (if any questions remain." )
Pinsonneaultas as modified by Allred does not explicitly teach :
detect the prescribed approved status in the prescriber reference data;
Smith teaches:
(para, “[0026] FIG. 2 is an illustration of a graphical user interface (GUI) 200 that may be used to implement the portal 123. As shown, the GUI 200 may provide a variety of metrics regarding prior authorizations (PAs) for various drugs associated with a drug manufacturer 103. In the example shown, the GUI 200 is being used to view metrics for each drug including total number of claims 107 received, the total number of claims 107 accepted (paid), and the total number of claims 107 that have been rejected due to missing or incomplete prior authorization requests 114. The GUI 200 may be further used to show metrics related to individual providers 101 (pharmacies), prescribers (physicians), and to select the particular drugs that are tracked for the manufacturer 103. As will be discussed further below, in some embodiments, the manufacturers 103 may be able to schedule training for a particular provider 101 through the GUI 200.”)
Also, para “[0028] In some embodiments, when an approval rate for claims 107 requiring prior authorization requests 114 for a particular specialty drug falls below a threshold percentage for a provider 101, the training engine 123 may schedule training for the associated provider 101. The training may be training on how to best complete the paperwork associated with the prior authorization request 114 for the specialty drug so that the approval rate for claims 107 for the specialty drug increases. Alternatively, the training engine 123 may schedule training when the total number of claim 107 denials due to prior authorization requests 114 passes a threshold number. The threshold percentage or threshold number that triggers training may be provided by the manufacturer 103 associated with the specialty drug.”)
It would have been obvious for a person of ordinary skill in the art to apply minimum threshold teachings of Smith into the teachings of Pinsonneault as modified by Allred at the time the application was filed in order to increase the rate of approval. (Abstract, “A system for increasing the rate of claim approval for specialty drugs is provided. The system monitors the approval and disapproval rates for claims related to specialty medications for multiple providers (e.g., pharmacies) due to missing or incomplete prior authorization requests….”)
Response to Arguments
Applicants’ arguments filed on 07/14/2026 have been fully considered but they are not persuasive.
Double Patenting
The examiner acknowledges the applicant’s intent to file terminal disclaimer to resolve the double patenting issue.
Remarks 35 USC § 101
Remarks, Pg. 14-15, Applicant contends: “In the Instant application as filed, as well as amended claim 1, there is clearly described a process of automatically processing prior authorizations in claim transaction messages that provides an improvement to the underlying technology. Instant claim 1 describes a) applying a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and the jurisdictional regulations, the set of pre-approval rules defining pre-approval conditions for pharmacy PAs; b) when the pre-approval conditions are met: i) automatically appending an
approval data element to the claim transaction message to generate a PA approval message; ii) determining an identity of the remote computer device based on one or more data elements of the claim transaction message; and iii) transmitting the PA approval message to the remote computing device, wherein the remote computing device includes one of a pharmacy claims processor for further adjudication of the pharmacy claim transaction, to the originating pharmacy to fulfill the prescription, or to a healthcare claims clearinghouse for forwarding of the PA approval message to the pharmacy claims processor or to the originating pharmacy; and c) writing a new record to the reference database including an indication of whether the pharmacy claim transaction for the prescription satisfied the pre-approval conditions. Accordingly, the subject matter the technical field, the claimed subject matter, and the specific technological improvement in the Instant application and Desjardins are demonstrated to be similar.”
The applicant is trying to draw parallel with Desjardins, and state that claimed invention provides an improvement to underlying technology. The instant application is completely irrelevant to Desjardin, as the case facts, and claimed inventions are completely different. In Desjardin, the claim recited a technological solution to a technological problem. Id. Finally, in Ex Parte Desjardins, the claims reflected a specific improvement that addressed the technical problem of “catastrophic forgetting” in continual learning systems, while allowing artificial intelligence systems to variously optimize system performance, use less storage capacity and reduce system complexity. Ex Parte Desjardins, Appeal No. 2024-000567 (PTAB September 26, 2025, Appeals Review Panel Decision) (precedential).” In the instant application, the applicant is merely pointing out the claim limitations and provides conclusory statement that these limitations provide improvement to underlying technology, without any discussion of technology. Secondly, from applicant’s arguments, it is not clear which underlying technology is being improved? In the first identified, limitation, the data is being appended to the message, there is no discussion about how the data is being appended, nowhere does the claim discusses how the data is being appended, what problem in data appending is being solved, or what improvement to data appending technology is being made. The similar analysis can be done, with each of the argued limitations with regard to determining the identity of remote device from message (under BRI, one can’t even respond back to message without knowing the identity of the device that sent a message), transmitting the messages, and adding the records.
In remarks, Pg. 9-15, the applicant is merely providing different decisions, guidelines etc..., and draws parallel to claimed invention by making a conclusory statement without discussing any case facts, the technologies, or the improvements.
Remarks, Pg. 16-17, Applicant contends: “With respect to Step 2A, Prong One, the Examiner alleges that certain claim steps are mental processes (Office Action, p. 4), but Applicant submits that these steps cannot practically be performed mentally. In Claim 1, the Examiner identified "querying a reference database with the prescriber identifier and the plan identifier to access prescriber reference data associated with the prescriber of the prescription, healthcare plan provisions of the healthcare plan, and jurisdictional regulations and applying a set of pre-approval rules to the prescriber reference data, the healthcare plan provisions, and the jurisdictional regulations, the set of pre-approval rules defining pre-approval conditions for pharmacy PAs." However, performing such analysis represents thousands to hundreds of thousands of data points that cannot be mentally processed, compared, or analyzed by a human. Accordingly, the claims do not recite a judicial exception under Prong One of the Step 2A analysis. For this reason alone, the claims satisfy the requirements of the subject matter eligibility test and Applicant respectfully requests that the Examiner withdraw the rejection.”
The examiner agrees, that using the computer, or automating the process that can be mentally performed, one is making it more efficient, and manageable; however, applying the computer as tool, and as a result getting the efficiency does not integrate the abstract idea into application. (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f)). Instant application specification states “[0003] It is well known that some prescriptions for products or services provided at a pharmacy (e.g., medication, medical devices, medical supplies, laboratory orders) require a prior authorization (PA), based on provisions of a healthcare plan or insurer. Some common instances for requiring a PA may include, but are not limited to, medications prescribed for off-label or not yet approved uses, prescribed products having cheaper or more commonly available treatment alternatives, prescribed medical devices, prescribed medical supplies, prescription digital therapeutics, and/or medication-specific clinical protocols including step therapy. When a pharmacy PA is initiated, the prescriber must provide additional information to the healthcare plan or insurer, for the insurer to approve the prescription for coverage under the healthcare plan. This process commonly requires multiple phone calls or faxes and the transmission of unfilled and filled forms between parties and may require days or weeks of time and effort by multiple parties. In some cases, prescribers are not sure of what information is needed and may provide unnecessary information to the insurer. In many cases, the PA process results in delays in treatment, which can be significant and, at times, harmful to the patients.”
As can be seen, here the question is not whether the claimed invention can be performed by humans using paper and pen, rather it can be improved by automating the process. The improvement being performed here is a business improvement, rather than a technical improvement.
Remarks, Pg. 16-18, Applicant further discusses different steps of 35 U.S.C 101 analysis; however, the remarks merely provide conclusory statements, rather than providing any analysis related to how the claimed limitations individually, or in combination provide an improvement to underlying technology, or provide a technical solution to a problem.
Remarks 35 USC § 103
Remarks, Pg. 18-19, the applicant contends: “Pinsonneault describes a system for providing prior authorization support. More specifically, Pinsonneault describes a method for identifying claims which require prior authorization with the objective of initiating some form of assistance to the prescriber to complete the prior authorization form. The information included in the second request enables the prior authorization assistance computer to initiate a process for completing a prior authorization form and for delivering the completed form to the payor, and delivering, to the pharmacy computer, a response from the payor indicating acceptance of the first request for assistance. See Abstract. Basically, Pinsonneault runs a program against a pharmacy claims file, notes the complicated prior authorization requests, and operates a call center-like operation to prepare the prior authorizations so that the pharmacy claim can be approved more quickly. However, this is contrast to the Applicant's presently amended claims, which describe tapping into the claims flow and electronically extracting the claims noted for prior authorization to determine whether the plan+ prescriber+ drug combination (based on a dynamic rule set that we will maintain) has a pre-approved prior authorization rule. If not, the rejected claim is routed directly to the electronic Prior Authorization vendor to interact with the prescriber. Rather than being described by the Pinsonneault patent, the Applicant's approach sits adjacent as its focus is on eliminating the administrative processes for certain prior authorizations rather than facilitating assistance in preparing.”
Tthe applicant provides summary of the reference, and states, how the claimed invention differs from the reference; the applicant does not point out which limitations are not being disclosed by the reference. The issue with this approach is that claims are given it’s broadest reasonable interpretation, the reference can have steps, and functions that are additional to the claimed invention; the issue is whether the claim limitations are anticipated by the reference or not. From above remarks, it is very difficult to parse what applicant believe is not being disclosed by the reference.
Secondly, it seems, the issue being presented is that instant invention simply steps into automated administration of pe-approval of pharmacy product prior authorizations, whereas the reference’s objective is to initiate some form of assistance to the prescriber, and then the second request enables the prior authorization assistance computer to initiate a process for completing a prior authorization. Though, one of the embodiments do proceed in described manner, the reference also provides an embodiment, that does not require this step, rather, the entire process can be directly performed. Fig. 3, item 309, and 360; if the express option is selected, then express processing does not require separate request from pharmacy computer to accept prior authorization assistance, rather it can directly administer the process (See, Fig. 5). Thus, it is clear that method does not require first request for prior authorization assistance, and then second request to initiate the process form completing the prior authorization.
Remarks, Pg. 20, the applicant contends: “furthermore, Applicant respectfully submits that the 35 U.S.C. §103(a) of Pinsonneault and Allred is improper because the Office Action relies on information gleaned solely from Applicant's specification. MPEP § 2142 states that "impermissible hindsight must be avoided and the legal conclusion must be reached on the basis of the facts gleaned from the prior art." Any judgement on obviousness is in a sense necessarily a reconstruction based on hindsight reasoning, but so long as it takes into account only knowledge which was within the level of ordinary skill in the art at the time the claimed invention was made and does not include knowledge gleaned only from applicant's disclosure, such a reconstruction is proper" (MPEP § 2145(X)(A), quoting In re McLaughlin, 443 F.2d 1392, 1395 (CCPA 1971).”
First of all, the Allred reference is only used to access the jurisdiction regulation, and applying the pre-approval rules to the jurisdiction regulations. It is well known to ordinary skill in the art that jurisdiction related rules exist, that must be applied; in fact that’s the whole point of having such rules; you can’t apply the rules, without accessing them. Secondly, the examiner have provided the motivation for such combination, from the reference itself, as it clearly states that transactions needs to be handled based on jurisdiction restrictions (See, para 0069).
Remarks, Pg. 20, the applicant contends: “In the present case, the Office Action relies on the combination of a system prior authorization assistance in filling out forms (Pinsonneault) and a system for determining which pharmacy to use (Allred) to allegedly support the limitations of Claim 1. Although Allred does not describe prior authorization, the Office Action states that "[i]t would have been obvious for a person of ordinary skill in the art to apply jurisdiction regulation teaching of Allred into the teachings of Pinsonneault at the time the application was filed in order to handle prescription based on the jurisdictional restrictions." (Office Action, page 24). However, if it were obvious to use jurisdictional regulations with prior authorizations, then Allred may actually include the term prior authorization. Instead, the Office Action makes a leap that these two items would be obvious to combine with no evidence that it is so.”
The examiner is not clear, what applicant is trying to convey over here; Allred is not the primary reference, so it is not clear what applicant means by “if it were obvious to use jurisdictional regulations with prior authorizations, then Allred may actually include the term prior authorization.” The Pinsonnault reference teaches the pre-authorizing, applying the rules, regulations, etc...; it is merely silent with regards to regulations related to jurisdiction; to teach this aspect explicitly, the examiner have introduced Allred reference, that teaches jurisdiction regulations, can be accessed and applied on transaction, thus using the teaching of Allred, one can apply the jurisdiction regulations on transaction to ensure that transaction is handled according to jurisdiction restriction.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUMA WASEEM whose telephone number is (571)272-1316. The examiner can normally be reached Monday-Friday(9:00am - 5:00 pm) EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jason B. Dunham can be reached on (571) 272-8109. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUMA WASEEM/Examiner, Art Unit 3686
/JASON B DUNHAM/Supervisory Patent Examiner, Art Unit 3686
