RESPONSIVE SERVER, SERVER SYSTEM AND SERVER METHOD FOR AUTOMATICALLY DISPENSING BASED ON COMPREHENSIVE MEDICATION AUTHORIZATION PROCESSING

Abstract

A responsive server, server system, and server method for automatically dispensing based on comprehensive medication authorization processing. The server may include performing automatic dispensing based on comprehensive medication information based on a complete medical history. In this respect, the disclosure provides prescription authorization checks that may include a medication search based on a complete medication history (i.e., from multiple sources, including those prescription claims not being processed through a prescription insurance carrier).

Claims

1. A system for checking for problems with filling a new prescription drug request or a refill of a previously-filled prescription drug request, the system comprising: a remote client terminal comprising: a display; a network communications interface configured to communicate with a universal prescription database server over a computer network; a memory configured to store prescription drug records in a local database, each prescription drug record being stored in association with at least one unique patient identifier; and a processor programmed to: (1) receive, based on user input, a prescription authorization request including an associated unique patient identifier of a patient, a drug identifier, a prescriber identifier, and either a unique identifier of an insurance company or an indication that the patient does not have insurance; (2) determine, based on a check of the local database, whether one or more drug-related filling problems exist with the received prescription authorization request; (3) if at least one drug-related filling problems exists with the check of the local database, output to the display visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist; and (4) if no drug-related filling problems exist with the check of the local database, and the remote client terminal is associated with a retail chain database server: (A) transmit, to the retail chain database server, the prescription authorization request including the associated unique patient identifier and the drug identifier; (B) receive, from the retail pharmacy chain database server, a retail chain indication of whether any drug-related filling problems exist with the prescription authorization request; and (C) if the received retail chain indication indicates that at least one drug-related filling problems exists, output to the display the visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist; and (5) if no drug-related filling problems exist with the check of the local database and the retail indication indicates that no drug-related filling problems exist with the prescription authorization request or the remote client terminal is not associated with a retail chain database server: (A) transmit, to the universal prescription database server, the prescription authorization request including the associated unique patient identifier, the drug identifier and either the unique identifier of the insurance company or the indication that the patient does not have insurance; (B) receive, from the universal prescription database server, a universal indication of whether any drug-related filling problems exist with the prescription authorization request; and (C) if the received universal indication indicates that at least one drug-related filling problems exists, output to the display the visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist; (6) if the received universal indication indicates that no drug-related problems exist: (A) if the received prescription authorization request includes the indication that the patient does not have insurance, output to the display information indicating that no drug-related problems exist with filling/dispensing the prescription authorization request; (B) if the received prescription authorization request includes the unique identifier of the insurance company: (i) transmit, to a prescription database server of an insurance company, based on the unique identifier of the insurance company, the prescription authorization request including the associated unique patient identifier and the drug identifier; (ii) receive, from the prescription database server of the insurance company, an insurance indication of whether one or more drug-related filling problems exist with the prescription authorization request; and (iii) if the received insurance indication indicates that at least one drug-related filling problems exists, output to the display the visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist; and (C) if the received insurance indication indicates that no drug-related filling problems exist with the prescription authorization request output to the display information indicating that no drug-related problems exist with filling/dispensing the prescription authorization request; and (7) upon entry of user input indicating that the prescription drug request has been filled and dispensed, transmit, to the universal prescription database server, an indication of the filling and dispensing of the prescription drug request and additional information including the fill date, and the prescriber identifier; and a universal prescription database server comprising: a memory that stores a universal prescription database; a network communications interface configured to communicate with the remote client terminal over the computer network; and a processor programmed to: (1) receive the prescription authorization request, over the computer network via the network communications interface from the remote client terminal, the prescription authorization request including the associated unique patient identifier, the drug identifier, and either the unique identifier of the insurance company or the indication that the patient does not have insurance; (2) compare the drug identifier in the received prescription authorization request with one or more drug identifiers in existing prescription records associated with the same unique patient identifier stored in the universal prescription database; (3) if, based on the results of the comparison with the universal database, at least one drug-related filling problem exists, transmit information identifying at least one of the one or more drug-related filling problems determined to exist; (4) if, based on the results of the comparison with the universal prescription database, no drug-related filling problems exist with the received prescription authorization request, transmit information indicating that no drug-related problems exist with filling the prescription authorization request; and (5) upon receipt, from the remote terminal, of the indication that the requested prescription has been filled and dispensed and the additional information, update the universal prescription database to indicate that the requested prescription was filled and dispensed with the associated additional information.

2. The system of claim 1, wherein the memory is further configured to store prescriber records, pharmacy records, and dispenser's records in the universal prescription database, the at least one unique patient identifier comprises one of: (i) a set of three parameters consisting of: a patient first name, a patient last name, and a patient date of birth, and (ii) a patient social security number, the prescription records comprise a National Drug Code number (NDC#) or other unique drug identifier, a drug strength, a dispense quantity, a day supply, instructions for use, a prescription written date, prescriber identification information, and dispenser identifiers, the prescriber identification information comprises one or more of a prescriber's first name, a prescriber's last name, a prescriber's DEA number, a prescriber's NPI number, a prescriber's state license number(s), a prescriber's office phone number, a prescriber's address, and a prescriber's facsimile number, and the dispenser identification information comprise one or more of a pharmacy name, a pharmacy number, a pharmacy address, a pharmacy phone number, a pharmacy facsimile number, a dispensing pharmacist first name, a dispensing pharmacist last name, a dispensing pharmacist state license number, and a dispensing pharmacist NPI number.

3. The system of claim 1, wherein the network communications interface is a secure communications interface.

4. The system of claim 1, wherein the drug-related problems include at least one of: a drug allergy, a negative drug-disease state interaction, a negative drug-drug interaction, a duplicate therapy, an early refill, and an overuse of a medication.

5. The system of claim 4, wherein the processor is further programmed to: assign a rating to each of the drug-related problems based on a severity of the problem; and include the rating in the transmitted information identifying the at least one of the one or more drug-related filling problems determined to exist.

6. The system of claim 1, wherein the prescription records comprise: a first prescription record associated with a first unique patient identifier, the first prescription record comprising an insurance company identifier of a first insurance company, and a second prescription record associated with the first unique patient identifier comprising an insurance company identifier of a second insurance company that is different than the first insurance company.

7. The system of claim 1, wherein each of the prescription records further comprise an insurance field that identifies whether an insurance claim is associated with the prescription record.

8. The system of claim 7, wherein if the insurance field does not indicate that an insurance claim is associated with the prescription record, the insurance field indicates that the prescription was paid for with cash.

9. A method of checking for problems with filling a new prescription drug request or a refill of a previously-filled prescription drug request, the method comprising: (1) receiving, from a client terminal, based on user input, a prescription authorization request including an associated unique patient identifier of a patient, a drug identifier, a prescriber identifier, and either a unique identifier of an insurance company or an indication that the patient does not have insurance; (2) determining, based on a check of a local database of the client terminal, whether one or more drug-related filling problems exist with the received prescription authorization request; (3) if at least one drug-related filling problems exists with the check of the local database, outputting, to a display of the client terminal, visibly-perceptible alert notification information identifying at least one of the one or more drug-related filling problems determined to exist; (4) if no drug-related filling problems exist with the check of the local database and the remote client terminal is associated with a retail chain database server: (A) transmitting, over a computer network via a network communications interface from the client terminal to the retail chain database server, the prescription authorization request including the associated unique patient identifier and the drug identifier; (B) receiving, by the client terminal from the retail chain database server, a retail indication of whether any drug-related filling problems exist with the prescription authorization request; and (C) if the received retail chain indication indicates that at least one drug-related filling problems exists, outputting, to the display of the client terminal, visibly-perceptible alert notification information identifying at least one of the one or more drug-related filling problems determined to exist; and (5) if no drug-related filling problems exist with the check of the local database, and either: (i) the retail chain indication indicates that no drug-related filling problems exist with the prescription authorization request, or (ii) the remote client terminal is not associated with a retail chain database server: (A) transmitting, over the computer network from the client terminal to a universal database server, the prescription authorization request including the associated unique patient identifier; (B) comparing, by the universal database server, the drug identifier in the received prescription authorization request with one or more drug identifiers in existing prescription records stored in the universal prescription database that are associated with the same unique patient identifier; (C) if, based on the results of the comparison by the universal prescription database server, at least one drug-related filling problem exists: (i) transmitting, from the universal prescription database server to the client terminal, information identifying at least one of the one or more drug-related filling problems determined to exist, and (ii) outputting to the display of the client terminal visibly-perceptible alert notification information identifying at least one of the one or more drug-related filling problems determined to exist; and (D) if, based on the results of the comparison of the universal prescription database server, no drug-related filling problems exist with the received prescription authorization request: (i) if the received prescription authorization request includes the unique identifier of the insurance company: (a) transmitting, to a prescription database server of the insurance company by the universal database server, based on the unique identifier of the insurance company, the prescription authorization request including the associated unique patient identifier and the drug identifier, (b) receiving, from the prescription database server of the insurance company by the universal prescription database server, an insurance indication of whether one or more drug-related filling problems exist with the prescription authorization request; and (c) if the received insurance indication indicates that at least one drug-related filling problems exists, transmitting, by the universal prescription database server to the client terminal, information identifying at least one of the one or more drug-related filling problems determined to exist; and (ii) if the insurance indication indicates that no drug-related filling problems exist with the prescription authorization request, or if the received prescription authorization request includes the indication that the patient does not have insurance: (a) outputting, to the display by the client terminal, information indicating that no drug-related problems exist with filling the prescription authorization request, (b) receiving, by the client terminal based on user input, information indicating that the requested prescription has been filled and dispensed, (c) transmitting, to the universal prescription database server from the client terminal, information indicating that the requested prescription has been filled and dispensed and additional information including the fill date, and the prescriber identifier, and (d) upon receipt, by the universal prescription database server, of the indication that the requested prescription has been filled and dispensed and the additional information, updating, by the universal prescription database server, the universal prescription database to indicate that the requested prescription was filled and dispensed and storing the associated additional information therewith.

10. The method of claim 9, further comprising storing prescriber records, pharmacy records, and dispenser's records in the universal prescription database of the memory, wherein the unique patient identifier comprises one or more of: a patient first name, a patient last name, a patient date of birth, and a patient social security number; the prescription records comprise a National Drug Code number (NDC#), a drug strength, a dispense quantity, a day supply, instructions for use, a prescription written date, prescriber identifiers, and dispenser identifiers, the prescriber identifiers comprise a prescriber's first name, a prescriber's last name, a prescriber's DEA number, a prescriber's NPI number, a prescriber's state license number(s), a prescriber's office phone number, a prescriber's address, and a prescriber's facsimile number; and the dispenser identifiers comprise a pharmacy name, a pharmacy number, a pharmacy address, a pharmacy phone number, a pharmacy facsimile number, a dispensing pharmacist first and last name, a dispensing pharmacist state license number, and a dispensing pharmacist NPI number.

11. The method of claim 9, wherein the network communications interface is a secure communications interface.

12. The method of claim 9, wherein the drug-related problems include at least one of: a drug allergy, a negative drug-disease state interaction, a negative drug-drug interaction, a duplicate therapy, an early refill, and an overuse of a medication.

13. The method of claim 12, further comprising assigning a rating to each of the drug-related problems based on a severity of the problem, wherein the rating is included in the transmitted response.

14. The method of claim 9, wherein the prescription records comprise: a first prescription record associated with a first patient comprising an insurance company identifier of a first insurance company, and a second prescription record associated with a first patient comprising an insurance company identifier of a second insurance company that is different than the first insurance company.

15. The method of claim 9, wherein each of the prescription records further comprise an insurance field that identifies whether an insurance claim is associated with the prescription record.

16. The method of claim 15, wherein if the insurance field does not indicate that an insurance claim is associated with the prescription record, the insurance field indicates that the prescription was paid for with cash.

17. A system for checking for problems with filling a new prescription drug request or a refill of a previously-filled prescription drug request, the system comprising: a remote client terminal comprising: a display; a network communications interface configured to communicate with a universal prescription database server over a computer network; a memory configured to store prescription drug records in a local database, each prescription drug record being stored in association with at least one unique patient identifier; and a processor programmed to: (1) receive, based on user input, a prescription authorization request including an associated unique patient identifier of a patient, a drug identifier, a prescriber identifier, and either a unique identifier of an insurance company or an indication that the patient does not have insurance; (2) determine, based on a check of the local database, whether one or more drug-related filling problems exist with the received prescription authorization request; (3) if at least one drug-related filling problems exists with the check of the local database, output to the display visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist; (4) if no drug-related filling problems exist with the check of the local database, and the remote client terminal is associated with a retail chain database server: (A) transmit, to the retail chain database server, the prescription authorization request including the associated unique patient identifier and the drug identifier; (B) receive, from the retail pharmacy chain database server, a retail chain indication of whether any drug-related filling problems exist with the prescription authorization request; and (C) if the received retail chain indication indicates that at least one drug-related filling problems exists: (i) output, to the display, visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist and an override button, and (ii) when the user indicates, via clicking/pressing the override button, that the prescription was overridden so as to be filled and dispensed, transmit an indication of the overriding and dispensing to the universal prescription database server; (5) if no drug-related filling problems exist with the check of the local database and the retail indication indicates that no drug-related filling problems exist with the prescription authorization request or the remote client terminal is not associated with a retail chain database server: (A) transmit, to the universal prescription database server, the prescription authorization request including the associated unique patient identifier, the drug identifier and either the unique identifier of the insurance company or the indication that the patient does not have insurance; (B) receive, from the universal prescription database server, a universal indication of whether any drug-related filling problems exist with the prescription authorization request; and (C) if the received universal indication indicates that at least one drug-related filling problems exists: (i) output, to the display, visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist and an override button, and (ii) when the user indicates, via clicking/pressing the override button, that the prescription was overridden so as to be filled and dispensed, transmit an indication of the overriding and the dispensing to the universal prescription database server; (6) if the received universal indication indicates that no drug-related problems exist: (A) if the received prescription authorization request includes the indication that the patient does not have insurance, output to the display information indicating that no drug-related problems exist with filling/dispensing the prescription authorization request; (B) if the received prescription authorization request includes the unique identifier of the insurance company: (i) transmit, to a prescription database server of the insurance company, based on the unique identifier of the insurance company, the prescription authorization request including the associated unique patient identifier and the drug identifier; (ii) receive, from the prescription database server of the insurance company, an insurance indication of whether one or more drug-related filling problems exist with the prescription authorization request; and (iii) if the received insurance indication indicates that at least one drug-related filling problems exists: (a) output, to the display, visibly-perceptible alert notification information identifying at least one of the one or more problems determined to exist and an override button, and (b) when the user indicates, via clicking/pressing the override button, that the prescription was overridden so as to be filled and dispensed, transmit an indication of the overriding and dispensing to the universal prescription database server; and (C) if the received insurance indication indicates that no drug-related filling problems exist with the prescription authorization request, output, to the display, information indicating that no drug-related problems exist with filling/dispensing the prescription authorization request; and (7) upon entry of user input indicating that the prescription drug request has been filled and dispensed, transmit, to the universal prescription database server, an indication of the filling and dispensing of the prescription drug request and additional information including the fill date, and the prescriber identifier; and a universal prescription database server comprising: a memory that stores a universal prescription database; a network communications interface configured to communicate with the remote client terminal over the computer network; and a processor programmed to: (1) receive the prescription authorization request, over the computer network via the network communications interface from the remote client terminal, the prescription authorization request including the associated unique patient identifier, the drug identifier, and either the unique identifier of the insurance company or the indication that the patient does not have insurance; (2) compare the drug identifier in the received prescription authorization request with one or more drug identifiers in existing prescription records associated with the same unique patient identifier stored in the universal prescription database; (3) if, based on the results of the comparison with the universal database, at least one drug-related filling problem exists, transmit information identifying at least one of the one or more drug-related filling problems determined to exist; (4) if, based on the results of the comparison with the universal prescription database, no drug-related filling problems exist with the received prescription authorization request, transmit information indicating that no drug-related problems exist with filling the prescription authorization request; and (5) upon receipt, from the remote terminal, of the indication that the requested prescription has been filled and dispensed and the additional information, update the universal prescription database to indicate that the requested prescription was filled and dispensed with the associated additional information, wherein if the indication indicates that the prescription authorization request was overridden so as to be filled and dispensed, store an indication indicating the prescription authorization request was overridden and filled and dispensed.

18. The system of claim 17, wherein the processor is further programmed to: capture auditable information regarding the prescriber including a prescriber identification number, when the prescription has been filled or overridden and filled; and generate displayable report information including prescribing habits of the prescriber based on actually filled prescriptions.

19. The system of claim 17, wherein the processor is further programmed to: capture auditable information regarding the prescriber including a prescriber identification number, when the prescription has been filled or overridden and filled; and generate displayable report information including any unordinary amount of prescriptions of controlled substances.

20. The system of claim 17, wherein the processor is further programmed to: capture or record auditable information regarding the pharmacist/pharmacy including a pharmacist identification number, and/or a pharmacist name, and information regarding the prescriber including a prescriber identification number, when the prescription has been overridden and filled; determine whether a threshold percentage of prescriptions prescribed by a prescriber were filled at the same pharmacy and dispensed by the same pharmacist; determine, based on the captured or recorded overrides, a working relationship between the prescriber and pharmacy/pharmacist; and transmit auditable information to the remote terminal based on the results of the determinations.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Exemplary embodiments will be described with reference to the following drawings.

[0030] FIG. 1A shows a conventional server system 100 for medication monitoring for prescription fill authorization checks.

[0031] FIG. 1B shows a flowchart illustrating the processing a conventional server system for medication monitoring using patient information without universally-accepted insurance card information.

[0032] FIG. 1C shows a flowchart illustrating the processing a conventional server system for medication monitoring using patient information including universally accepted insurance card information.

[0033] FIG. 2 shows a server system 200 for medication monitoring-based prescription fill authorization checks in accordance with an exemplary embodiment of the present disclosure.

[0034] FIG. 3 shows a server system 300 illustrating the flow of data from a user terminal 310 at a remote location (e.g., shown as a pharmacy, but could also be a hospital/doctor's office (prescriber)) through a series of secure communication interfaces to a server check database 312 back to the remote terminal 310.

[0035] FIG. 4 shows a server system 400 illustrating the flow of data from a user terminal 410 at a remote location through a series of secure communication interfaces to a check server 412 back to the remote terminal 410.

[0036] FIG. 5A shows the hardware of a user terminal 200, which may be located at a remote location.

[0037] FIG. 5B shows an authorization check server 520 and a profile database server 540 of the embodiments of anyone of FIGS. 2-4.

[0038] FIG. 5C shows a high-level flowchart showing processing executed by user terminal 200 according to an exemplary embodiment of the disclosure for performing processing of for a pharmacy location (e.g., a brick-and-mortar independent pharmacy).

[0039] FIG. 5D shows a screenshot of a display (output device 217) of the user terminal 200 showing a highlighted icon with an arrow over it, which is the icon to start the process.

[0040] FIG. 5E shows a screenshot of a display (output device 217) of the user terminal 200 displaying how to login, which is to authenticate the user via the login function 212a.

[0041] FIG. 5F shows a screenshot of a display (output device 217) of the user terminal 200 displaying where to enter login credentials.

[0042] FIG. 5G shows a screenshot of a display (output device 217) of the user terminal 200 displaying, once login has been authenticated, an Rx Processing Tasks Screen 104 including a search button.

[0043] FIG. 5H shows a screenshot of a display (output device 217) of the user terminal 200 displaying the patient's profile.

[0044] FIG. 5I shows a screenshot of a display (output device 217) of the user terminal 200 displaying the patient's insurance information that is on file (which is via the insurance information tab on the bottom left (highlighted)).

[0045] FIG. 5J shows a screenshot of a display (output device 217) of the user terminal 200 showing how a pharmacist enters a prescription for filling that is NOT using our system.

[0046] FIG. 5K shows a screenshot of a display (output device 217) of the user terminal 200 displaying, once login has been authenticated, an Rx Processing Tasks Screen 108 including a search button.

[0047] FIG. 5L shows a screenshot of a display (output device 217) of the user terminal 200 displaying, an Electronic Claims Log screen 109.

[0048] FIG. 5M is similar to FIG. 5H and shows a screenshot of a display (output device 217) of the user terminal 200 displaying the patient's profile.

[0049] FIG. 5N shows a screenshot of a display (output device 217) of the user terminal 200 showing how a pharmacist enters a prescription for filling using an embodiment of the disclosed server.

[0050] FIG. 5O shows a screenshot of a display (output device 217) of the user terminal 200 showing a rejection from the universally-utilizable server system.

[0051] FIG. 5P shows a respective screenshot of a display (output device 217) of the user terminal 200 showing a rejection from the universally-utilizable server system.

[0052] FIG. 5Q shows a screenshot of a display (output device 217) of the user terminal 200 showing the patient profile with the patient's social security number entered on their profile.

[0053] FIG. 5R shows a screenshot of a display (output device 217) of the user terminal 200 showing the Electronic Claims Log screen showing the claim for rx#6066197 processed through SCRIPTCHECK successfully.

[0054] FIG. 6A shows a high-level flowchart showing some of the processing executed by an embodiment of the discloser related to a terminal device of a prescriber utilizing a universal database server according to an exemplary embodiment.

[0055] FIG. 6B shows an exemplary embodiment of a universal prescription database including attributes or characteristics of medication data (including prescriptions and disbursements each including associated patient info) stored in the universal prescription database, and communication interfaces between a plurality of devices.

[0056] FIGS. 7A and 7B show a high-level flowchart showing processing executed by a script server utilizing a universal database server according to an exemplary embodiment.

[0057] FIG. 8A is a sample screenshot showing displayable information sent as a response returned to a remote terminal from the script server/universal prescription database server illustrating an EARLY REFILL problem warning and the selectable options available to the user terminal.

[0058] FIG. 8B show exemplary screenshots of information displayed in a remote terminal, in response to a user's selection of a PAYMENT INFORMATION option of FIG. 8A.

[0059] FIG. 8C is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the early refill warning of FIG. 8A.

[0060] FIG. 9A is a sample screen shot showing displayed information sent as a response returned to a remote terminal from the script server/universal prescription database server illustrating a DUPLICATE THERAPY problem warning and the selectable options available to the user terminal.

[0061] FIG. 9B shows exemplary screenshots of information displayed in a remote terminal, in response to a user's selection of a PAYMENT INFORMATION option of FIG. 9A where the patient does not have a universally-accepted insurance card.

[0062] FIG. 9C is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DUPLICATE THERAPY warning of FIG. 9A.

[0063] FIG. 10A is a sample screen shot illustrating displayable information sent as a response returned to a remote terminal from the script server/universal prescription database server illustrating an DRUG-DRUG INTERACTION (INTX) problem warning and the selectable options available to the user terminal.

[0064] FIG. 10B shows an exemplary screenshot of information displayed in a remote terminal, in response to a user's selection of a PAYMENT INFORMATION option of FIG. 10A.

[0065] FIG. 10C is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DRUG-DRUG INTERACTION (INTX) warning of FIG. 10A.

[0066] FIG. 11A shows a sample screenshot illustrating information displayed by the remote terminal, which is received in a response returned to the remote terminal from the script server/universal prescription database, the displayed information showing a DRUG-DISEASE STATE INTERACTION (INTX) problem warning.

[0067] FIG. 11B is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DRUG-DRUG DISEASE STATE INTERACTION (INTX) warning of FIG. 11A.

[0068] FIG. 12A shows a sample screenshot illustrating information displayed by the remote terminal, which is received in a response returned to the remote terminal from the script server/universal prescription database, the displayed information showing a DRUG ALLERGY problem warning and the selectable options available to the user terminal.

[0069] FIG. 12B is a sample screenshot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the DELETE ALLERGY option to override the DRUG ALLERGY warning of FIG. 12A.

[0070] FIG. 12C is a sample screenshot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DRUG ALLERGY warning of FIG. 12A.

[0071] FIG. 13 is a sample screenshot illustrating the response returned to a remote terminal from the universal prescription database server(s) indicating that a complete search was performed, how many errors were overridden, and what those error were.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

[0072] FIG. 1A shows a conventional server system 100 for medication monitoring for prescription fill authorization checks. In particular, an individual pharmacy terminal device 102a has a local database 104a for storing prescription records for customers. The local database 104a may be stored on a memory of the terminal device 102a. The memory device may be any type of conventional memory. Pharmacy terminal 102a is shown in FIG. 1A as a retail pharmacy that is part of a retail chain 106 of pharmacy terminals 102a-102e. However, the pharmacy terminal 102a could also be a similar system of an already-connected group of terminal devices associated with one of: a mail order pharmacy, a hospital pharmacy, an independent pharmacy, and so on with very minor modifications.

[0073] As shown in FIG. 1A, pharmacy terminal 102a is part of a retail chain 106 that includes other member pharmacy terminals 102b, 102c, 102d, 102e. Each of the other member pharmacy terminals 102b-102e may have their own respective local databases 104b, 104c, 104d, 104e for storing records of prescriptions filled at the respective member pharmacies. The retail chain 106 also includes a central database server 108 that is utilizable from each of the retail chain 106 member pharmacy terminals. The central database server 108 contains records of prescriptions filled by a particular customer at any of the retail chain member pharmacies 102a-102e. However, this is still incomplete, as it does not account for prescriptions filled by the customer at a different pharmacy that is not connected to the central database 108.

[0074] In the conventional example of FIG. 1A, if the customer filling a prescription at the pharmacy, via terminal 102a, is using a universal insurance card, than a third database 110 may be accessed (based on the universal insurance card information). The insurance company database 110 is routinely checked by computers, when a pharmacist enters universal insurance card information received by a customer, when submitting an insurance claim. The insurance company database 110 includes records of prescriptions filled anywhere, as long as an insurance claim was submitted in connection with the prescription.

[0075] Once a prescription is presented at pharmacy 102a, the local database 104a, the retail chain central database 108, and optionally the insurance company database 110 (if a universal insurance card was presented) are all updated to record a record of the prescription.

[0076] FIG. 1B shows a conventional method of displaying information indicating whether or not a prescription fill request is authorized by a user terminal, in the case that a universally-accepted prescription insurance card is not used. In a real world exemplary scenario, a patient visits a medical services provider that prescribes medicine (e.g., a doctor, a nurse practitioner), herein after a prescriber. The prescriber may ask the patient how the prescription information should be delivered to the pharmacy, and, which one. However, many times, the patient just receives a paper of the prescription information. Regardless of the method of transmittal from the prescriber to the pharmacist (e.g., patient hand-delivery, phone authorization, fax, electronic prescription sent), the prescription information is received/entered into a pharmacy terminal, which may be of several different types. If the pharmacy terminal is a part of a traditional retail pharmacy chain (e.g., terminal 102a in chain 106 of FIG. 1A), the method continues at step 112 along the left-most column of FIG. 1B. If the pharmacy is an independent pharmacy, the method continues at step 114 along the middle column of FIG. 1B. Finally, if the pharmacy is a mail order pharmacy, the method continues at step 116 along the right-most column of FIG. 1B.

[0077] At the retail chain pharmacy terminal device, the prescription is entered (Step 118), and checked against the local store database 104a (Step 120) to determine if there are any problems with filling the prescription (e.g., drug allergies, negative drug-disease state interactions, negative drug-drug interactions, duplicate therapies, early refills (abuse/overuse of a medication), and other potential negative problems). If there are any problems identified from the check/search of local database 104a, a warning alert is issued, in the form of displayed information, and the prescription is not filled (Step 122). If no problems are identified (Step 124), the retail chain central database 108 is checked (Step 126). If are still no problems identified in the records check of central database 108 (Step 126), the prescription is authorized to be filled, and dispensed (Steps 228 and 230). On the other hand, if the central database 108 records do identify a problem (Step 126), than an alert is issued and the prescription is not filled (Step 132).

[0078] In an independent pharmacy or a mail-order pharmacy (as shown in the middle column and right-most column, respectively, of FIG. 1B), the method proceeds similarly with the exception that there may be no central database server to check. That is, the independent pharmacy may not be a part of a retail chain. The mail-order pharmacy could be a part of a retail chain, or could not. Since the method proceeds similarly for independent and mail order pharmacies, a description of the individual steps will not be repeated here. However, importantly, in the conventional system, the medication monitoring information is not shared between the three columns shown in FIG. 1B. That is, each of the individual systems (retail chain, independent, mail order) do not interact. Because of such, the medication monitoring information is inaccurate as it is not a complete representation of all possible prescriptions the patient may have received (had dispensed to him). That is, it does not utilize a complete medication history (i.e., from multiple sources, including those prescription claims not being processed through a prescription insurance carrier)). In other words, problems with drug allergies, negative drug-disease state interactions, negative drug-drug interactions, duplicate therapies, early refills (overuse of a medication), and other potential negative problems could occur and remain undetected if a patient merely uses a first pharmacy, such as a retail pharmacy (left-most column of FIG. 2) for one prescription, and a different pharmacy such as a mail order (right-most column) or independent pharmacy (middle column) for another prescription.

[0079] The situation described above is somewhat improved if a patient uses a universal insurance card, although important disadvantages remain, as will be described in connection with FIG. 1C. FIG. 1C shows a flowchart illustrating the processing of a conventional server system for medication monitoring using patient information including universally accepted insurance card information. The first portion of the processing, from a prescription being entered/received by a remote pharmacy terminal through the pharmacy central database being checked (Steps 120, 126, 128, 132) are substantially the same as described in connection with FIG. 1B, and so a detailed description thereof need not be repeated here. However, the method of FIG. 1C further includes additional steps including: (i) if no problems with the prescription are identified (Step 128), transmitting data regarding the prescription to be filled to an insurance company central database 110 to check (Step 134) for potential problems (drug interactions, early refills, insurance plan limitations, and so on). If no problems are identified (Step 136), then information indicating that the prescription may be dispensed is displayed (Step 138). However, if the records of the central insurance company database 110 indicate a problem fill problem (Step 140), then information displayed by the remote pharmacy terminal may indicate that the prescription should not be dispensed.

[0080] As shown, the central insurance company database 110 provides the advantage of receiving information from, and providing information to pharmacies from each of the three columns shown in FIG. 3. In other words, the central insurance company database 110 overcomes some of the limitations illustrated in FIG. 2, where a pharmacy in one column does not have access to information stored in a different database only utilizable to a different pharmacy in a different column. Unfortunately, the system and method described in connection with FIG. 1C still provides incomplete information to pharmacists that only works when the patient always uses the same universal insurance card.

[0081] Accordingly, a pharmacist using pharmacy terminal 102a may have access to information via insurance company database 110 that was not available in local database 104a, or retail chain central database 108. However, unfortunately, conventional system 100 leaves gaps in the information available for determining what information should be displayed to the pharmacist terminal requesting a prescription authorization. In particular, none of the conventional databases (104a, 108, 110) account for prescriptions filled outside the retail chain 106, in the case that no insurance identification information is presented, or, the case that the insurance card information is not of the particular insurance company associated with insurance company database 110.

[0082] FIG. 2 shows a server system 200 for medication monitoring-based prescription fill authorization checks in accordance with an exemplary embodiment of the present disclosure. In particular, FIG. 2 shows a universal prescription database server 408 that is configured to be universally-utilizable from any pharmacy, regardless of type, and regardless of whether a patient uses an insurance card or not. The dual direction arrows leading to and from the various pharmacy and insurance company devices of FIG. 2 and the universal prescription database server 208 illustrate the bi-directional communication capability via respective communication interfaces (e.g., FIG. 3) of the universal prescription database server. Preferably, the communication interface of the server 208 provides access to a wide area network with maximum availability, such as the Internet. In addition, the universal prescription database server 208 is preferably capable of exchanging prescription records and information with the insurance company central databases 110 and 406 (if authorized by the insurance company).

[0083] The universally-utilizable prescription database server 208 may also include a storage medium for storing various records as will be needed to perform the functions of the disclosure. For example, the records may include, in an exemplary embodiment, patient records including one or more unique patient identifiers (e.g., the patient's first and last name, date of birth, social security number), mailing address/phone number information, and prescription record history. Each prescription record entry may comprise one or more of: the unique patient identifier(s), a drug identifier (e.g., drug name and NDC number), and a quantity. The prescription records may also include a strength of the respective drug, instructions for use, day supply, the date the prescription was written, and a prescription fill date (if the prescription was filled). The prescription records may also include the prescriber's name (first and last), prescriber's DEA (Drug Enforcement Agency) number, prescriber's NPI number, prescriber's state license number(s), prescriber's full office address(es), office phone number(s) and office facsimile number(s). If the prescription of the prescription record has been filled, the prescription may indicate as much and also include information regarding the filled prescription including the pharmacy's name, full address, and phone number, and the pharmacist's full name, state license number, and NPI number. To achieve such, each prescription filled will be saved for future comparison (prescription authorization checks) and will indicate whether or not the user used a universally-accepted insurance card or not (e.g., how the prescription was paid). For example, if a patient uses a universally-accepted insurance card, the server 208 may capture, save, and transmit for pharmacist knowledge one or more pieces of the following: Insurance name, Insurance Bank Identification Number (BIN #), Processor Control Number (PCN #), prescription identification number (RX ID #), prescription group number (RX Group #), person code and insurance pharmacy help desk phone number. Subsequently, if no insurance card was utilized (e.g., cash/credit card was used), the prescription record will indicate that as well. With each transaction sent to the system, an updated list of each patient's drug allergies and health condition will occur and be stored in the systems database.

[0084] The universal prescription database server 208 of embodiments of the present disclosure provides several advantages over conventional systems and methods, as discussed above. In this respect, the universal prescription database server 208 preferably stores and transmits relevant prescription information for each individual prescription attempting to be filled, to and from pharmacies in order to provide pharmacists a complete list of any potential problems that exist. The universal prescription database server according to an embodiment of the present disclosure preferably incorporates a series of identifiers, or markers, which will be used to classify all medications according to the specific class into which they are classified. These classifications may include, for example, beta-blockers, opiates, or other classifications known as drug class identifiers. Additionally, the universal prescription database server according to an exemplary embodiment of the present disclosure may be preferably programmed to include an extensive list of drug interactions which will be used to determine if any interactions exist between any recently-filled prescriptions and the prescription currently attempting to be filled (the one at the basis of the prescription authorization request). The interactions are preferably classified according to severity. In one embodiment the lowest severity interaction may be classified as (1), and the most severe interaction may be classified as (5). Additionally, and preferably, an exemplary system may use the drug class identifiers to determine if any medications were filled-recently, such as within the past 180 days, that would identify a duplicate therapy problem.

[0085] As shown in FIG. 2, the system 200 includes access to the retail pharmacy chain 106, which comprises individual retail pharmacies 102a-102e, and access to a central insurance company database 110. The system 400 may also (as depicted in FIG. 2) include a mail order pharmacy terminal 202, and an independent pharmacy 404, which could be the remote client pharmacy terminal. It should be appreciated that the selection of pharmacy types is meant to be illustrative only, and any combination of pharmacies and pharmacy types could be included. A second insurance company database 206 is also shown, representing that multiple independent insurance companies can maintain separate central insurance company databases, which may be accessed by pharmacies.

[0086] FIG. 3 shows a server system illustrating the flow of data from a user terminal 310 at a remote location (e.g., shown as a pharmacy, but could also be a hospital/doctor's office (prescriber)) through a series of secure communication interfaces to a server check database 312 back to the remote terminal 310. FIG. 3 shows how the exemplary embodiment may function. For example, when a prescription is presented to a pharmacy and entered into the pharmacy remote terminal 310 prior to being filled and dispensed, the data may be transmitted to a web service node terminal on an encrypted Secure Sockets Layer (SSL) connection. Once transmitted, the server system will communicate to the universal prescription database server on another encrypted SSL connection, which will be using a different certificate. Any data being returned to the client terminal 310 may be sent back across the same encrypted channels. The SSL connections will safeguard the data as it is in transit from the client to the host. Any patient protected information (PPI) that is stored in the universal prescription database is to be stored and encrypted as required by law (HIPAA). This data will not be decrypted to the reporting repository unless absolutely necessary (e.g., subpoena) and will follow strict policies and procedures to ensure that this data, whatever it may be, is secured to avoid any sensitive data being released from the system. The overall composition of the network begins with a perimeter network, also known as a demilitarized zone (DMZ). This network is protected on both ends by firewalls. This network adds an additional layer of security to the organizations local area network (LAN), making it least vulnerable to attacks. Within the DMZ is a sub-network identified as Bastion, also protected on both ends by firewalls. The Bastion provides another line of defense in the event of a security breach. The final network, the Corporate Network, is utilized primarily for day to day system maintenance as well as reporting capabilities. Access to this data will be at a corporate level only and will have an added firewall for protection.

[0087] FIG. 4 shows another example of an embodiment of the disclosure. FIG. 4 shows a server system 400 illustrating the flow of data from a user terminal 410 at a remote location through a series of secure communication interfaces to a check server 412 back to the remote terminal 410. In this example, the first check is a hard drive of the pharmacy. If no problems, the pharmacy terminal communicates with a switch server 412, which communicates with a public facing web service server, preferably, with a firewall between the two. The switch server is configured to route the prescription fill request to destinations based on a BIN. The switch server 412 is the entity that reads the BIN number and routes the message via the BIN number. There are existing switch server companies (e.g., PowerLine, etc.) that route the fill/claim requests based on the BIN, and return information including, for example, an alert notification of a type of problem (e.g., refill too soon). However, in the conventional technology, people could not register to, for example, a retail chain database without using a pharmacy tied to that retail chain. Retail chains do not use a BIN number. By being able to provide utilizable database prescription information, without using the same pharmacy (e.g., instead by registering and receiving login credentials), any and every pharmacy could use the universal database to overcome problems with the existing technology. The public facing web service may communicate with a scriptcheck database server, which is universally-utilizable via the public facing web service. Ultimately, if there is no problem with any of the comprehensive series of checks, the prescription is auto-filled.

[0088] FIG. 5A shows the hardware of a user terminal 200, which may be located at a remote location. The user terminal device 200 may further comprise an Input/Output (I/O) interface 214 communicably coupled to an input device 216 and/or an output device 217 via links 218 and 219, respectively. The input device 216 may be one of or any combination of a keyboard, a mouse, a trackball, a touchscreen, a virtual reality glove, a sensor (e.g., biometric sensor), and any known or later-developed device for inputting data and/or control signals to the user terminal 200. The output device 217 may be one of or any combination of a computer monitor, a cathode ray tube, a liquid crystal display (LCD), a touchscreen display device, an image projector, an electrophoretic display, a virtual reality device, an audio speaker, and any other known or later-developed device for visually displaying or audibly outputting the data output from the user terminal 200. Each of the various links 218 and 219 can be any known or later-developed device or system for connecting the input device 216 and the output device 217, respectively, to the I/O interface 214. In particular, the links 218 and 219 can each be implemented as one or more of a direct cable connection, a connection over a wide area network, a local area network or a storage area network, a connection over an intranet, a connection over an extranet, a connection over the Internet, a connection over any other distributed processing network or system, and/or an infrared, radio-frequency or other wireless connection.

[0089] The user terminal 200 may further comprise a communication unit 215 (which may comprise a network interface card) that is communicably coupled to the network 230 and that allows the user terminal 200 to communicate, via the network 230, with the scriptcheck universally accessible server 300.

[0090] The user terminal 200 may also include various circuits, routines, or applications as will be discussed below with reference to items 212a-212c. These disclosed circuits, routines, or applications can be dedicated circuits and/or individual programs and/or routines in a larger program stored in a memory such as the memory 211 and executed by the processor 212. Thus, in exemplary embodiments, the disclosed circuits, routines, or applications can be implemented by one or more programs executed by the processor 212. In certain embodiments, circuits, routines, or applications may be a web browser or application, and will be discussed in more detail below.

[0091] FIG. 5B shows an authorization check server 520 and a profile database 540 of the embodiments of anyone of FIGS. 2-4. FIGS. 5A and 5B show modules 212a-212c and 326-328, respectively, which may perform some of the functions of the user terminal in communication with the server 300.

[0092] In this respect, FIG. 5C further shows a high-level flowchart showing some of the processing executed by the user terminal in communication with the server 300 according to an exemplary embodiment of the disclosure for performing processing for a pharmacy location (e.g., a brick-and-mortar independent pharmacy). In particular, FIG. 5C shows steps 1500-1504. In particular, FIGS. 5D-5L are further described below to explain Steps 1500-1504, and additional processing interactions between the client terminal 200 and the server 300 that may be implemented in different embodiments of the disclosure.

[0093] FIG. 5D shows a screenshot of a display (output device 217) of the user terminal 200 showing a highlighted icon with an arrow over it, which is the icon to start the process. The user of the user terminal may click a mouse on an icon to start the process, or, if on a smartphone, touch the screen. The icon may be an icon on a desktop background screen for example.

[0094] FIG. 5E shows a screenshot of a display (output device 217) of the user terminal 200 displaying how to login, which is to authenticate the user via the login function 212a. Thus, FIG. 5E corresponds to a display that is a part of the Step 1500 where the user (e.g., a pharmacist) logins to the secure server. To login to the secure server, the user may have registered in advance via the public facing web server so that the user can use the system and so that the login credentials are stored. The login credentials may be a user name and password, or other types of authentication processing, such as, biometrics (e.g., iris scan, fingerprint) or an auto-login feature where the password is remembered. However, unlike conventional retail systems, the user is able to gain access to the system by registering with the server system. Similarly, FIG. 5F shows a screenshot of a display (output device 217) of the user terminal 200 displaying where to enter login credentials. FIG. 5G shows a screenshot of a display (output device 217) of the user terminal 200 displaying, once login has been authenticated, an Rx Processing Tasks Screen 104 which includes multiple buttons for the pharmacist. For example, a search button, which will be described later for searching for a patient. Once the user clicks the search button, the user may look up a patient via a search bar.

[0095] FIG. 5H shows a screenshot of a display (output device 217) of the user terminal 200 displaying the patient's profile. In this screenshot, the user's SSN has not been entered. This screen 105 would be a part of the Step 1501, which requires 3 types of information. For example, to start the process, a user (e.g., pharmacist) must enter user information regarding a patient (if a refill, could use previously stored information to enter), and information regarding the prescription claim type (e.g., a name of a nationally recognized insurance carrier who would have a BIN discussed below, or an indication NONE or CASH, which mean that no nationally recognized insurance card information is presented for this prescription claim.

[0096] FIG. 5I shows a screenshot of a display (output device 217) of the user terminal 200 displaying a Claim Type Information screen 106. In this example, the patient has insurance so the patient's insurance information that is on file (which is via the insurance information tab on the bottom left (highlighted) is displayed).

[0097] FIG. 5J shows a screenshot of a display (output device 217) of the user terminal 200 showing a display screen 107. The display screen 107 is used to prompt the pharmacist to enter a prescription for filling. In this example, as the claim types (primary, secondary) do NOT use the disclosed universally-utilizable system, they are less accurate. PLEASE NOTE***IN THIS EXAMPLE, THIS PRESCRIPTION IS BEING SUBMITTED ONLY TO THE PATIENT'S PRIMARY INSURANCE (HIGHMARK)*** This would be an example that is similar to how the current, conventional system works that is inaccurate/incomplete information because DOES NOT use the disclosed system.

[0098] FIG. 5K shows a screenshot of a display (output device 217) of the user terminal 200 displaying, once login has been authenticated, an Rx Processing Tasks Screen 104 including a search button. From this screen 108, the pharmacist selects the electronic claims log to see if the prescription processed with or without errors.

[0099] FIG. 5L shows a screenshot of a display (output device 217) of the user terminal 200 displaying, an Electronic Claims Log screen 109. Please note that this prescription (rx#6066197, top on the list) processed without any errors to the insurance company and resulted in a paid claim. It is important to note that this claim was submitted WITHOUT the patients social security number. ***OUR SYSTEM REQUIRES A SOCIAL SECURITY NUMBER (AMONG OTHER THINGS) TO ENSURE THAT WE HAVE THE CORRECT PATIENT***

[0100] FIG. 5M is similar to FIG. 5H and shows a screenshot of a display (output device 217) of the user terminal 200 displaying the patient's profile. This screen 110 occurs after selecting search, and a patient's name is typed in the search bar, and a result is found (and optionally selected). FIG. 5N shows a screenshot of a display (output device 217) of the user terminal 200 showing how a pharmacist enters a prescription for filling using an embodiment of the disclosed system. In FIG. 5N, as shown in Screen 111, the primary form of prescription authorization is SCRIPTCHECK, which corresponds to using a universally-utilizable server as in the disclosure. That is, FIG. 5N IS using our system. PLEASE NOTE***IN THIS EXAMPLE, WHEN THE USER OF THE USER TERMINAL CLICKS THE FILL BUTTON, THIS PRESCRIPTION IS SUBMITTED TO THE DISCLOSED SYSTEM (LOCAL HARDDRIVE and SCRIPTCHECK) FIRST, THEN TO THE PATIENT'S PRIMARY INSURANCE (HIGHMARK)*** This is seen under the primary section, which shows SCRIPTCHECK and under the secondary section, which shows HIGHMARK (the patient's primary insurance). In this respect, when the FILL button is selected/clicked, the prescription information and patient information (i.e., identification information) goes to the internet to the switch server, and then routed to the universal database server (and if insurance the insurance server). If neither have problems, in an embodiment, the user terminal automatically issues a command to print a prescription label for the identified patient with the prescription information. Further, a confirmation screen may be displayed confirming that the prescription is filled/dispensed.

[0101] One of the important things to note is that using the disclosed system adds NO ADDITIONAL STEPS to the prescription filling process. This is seen in the FIGS. above. In this respect, the disclosed system may be implemented to seamlessly integrate (blindly drop) into all pharmacy prescription processing systems. This would mean that no additional steps need to be taken by the pharmacist to ensure that EVERY claim, including those that aren't being processed to an insurance company, go to the disclosed universally-utilizable database (SCRIPTCHECK) first.

[0102] FIG. 5O shows a screenshot of a display (output device 217) of the user terminal 200 showing a rejection from the universally-utilizable server system. In particular, FIG. 5O shows a main Electronic Claim Log screen 112 including an indication that RX #6066197 has a VOIDED TRANSACTION.

[0103] FIG. 5P shows a respective screenshot of a display (output device 217) of the user terminal 200 showing a rejection from the universally-utilizable server system. In particular, FIG. 5P shows a screenshot of a Claim Rejection Detail Screen for RX #06066197. The Claim Rejection Detail Screen indicating to the pharmacist that the patient's social security number is missing and MUST be entered in the patient profile, and the claim re-submitted.

[0104] FIG. 5Q shows a screenshot of a display (output device 217) of the user terminal 200 showing the patient profile with the patient's social security number entered on their profile. In some embodiments, SCRIPTCHECK may be configured so that a SSN is required for every transaction. This ensures proper verification of the patient. In some embodiments, the personal identification information includes a first and last name and a date of birth with the SSN.

[0105] FIG. 5R shows a screenshot of a display (output device 217) of the user terminal 200 showing the Electronic Claims Log screen showing the claim for rx#6066197 processed through SCRIPTCHECK successfully. That is, after the user of the user terminal enters in the SSN in FIG. 5Q then the SCRIPTCHECK problem goes away and the prescription can be filled and dispensed.

[0106] FIG. 6A shows a high-level flowchart showing some of the processing executed by an embodiment of the discloser related to a terminal device of a prescriber utilizing a universally-utilizable database server according to an exemplary embodiment. In this respect, the method of FIG. 6A may be used by a prescriber to receive displayed information that helps check for any problems in prescribing a specific prescription before issuing the prescription to the patient. FIG. 6A illustrates use by a prescriber, however, as discussed above and below, a pharmacist may use the system as well. When a prescriber decides to write a prescription, the prescriber will be able to utilize the most current, up-to-date data for the patient. After logging into a secure network (Step 601), the prescriber enters the patient information and prescription information (e.g., a patient's demographically data as well as the full prescription data for the designated prescription) at Step 602. Upon transmitting the claim to the universal prescription database server across the secure network (Step 603), a comprehensive check will be performed to check for problems with filling the prescribing the proposed prescription (e.g., problems related to one of: drug allergies, negative drug-disease state interactions, negative drug-drug interactions, duplicate therapies, early refills (overuse of a medication), and other potential negative problems). In real-time, a response will be transmitted back to the remote terminal informing the prescriber of any potential problems) at Step 605. It is important to note that this data will NOT be stored in the universal prescription database server. It will only be used for the prescriber to see what the patient already has had filled and by which prescriber(s). Only once the prescription is actually filled and dispensed will the data be updated in the centralized system and made available for future reference.

[0107] FIG. 6B shows an exemplary embodiment of a universal prescription database including attributes or characteristics of medication data (including prescriptions and disbursements each including associated patient info) stored in the universal prescription database, and communication interfaces between a plurality of devices. The system 600 of FIG. 6 includes a universal prescription database server 1602 that is connected to a wide variety of pharmacies as well as being utilizable by all licensed prescribers. As depicted, the pharmacies connected to universal prescription database 1602 include a retail chain pharmacy 1604, an independent pharmacy 1606, a mail order pharmacy 1608, a hospital 1610, a nursing home 1612, and a personal care facility 1614. Of course, those of ordinary skill in the art will readily appreciate that the particular pharmacy types depicted in FIG. 6 are merely exemplary, and intended to illustrate the wide variety of pharmacies which may participate in the universal prescription database server 1602. As shown, each pharmacy is capable of communicating with the universal prescription database server 1602 and exchanging information in both directions. New prescription records are transmitted to the universal prescription database server 602. Preferably, for each relevant prescription, the following information may form a prescription record that is transmitted to the universal prescription database 1602 and utilized for future prescription checks: Patient data (e.g., one or more of First and Last name, middle name, full address, phone number(s), date of birth, social security number), Prescriber data (e.g., one or more of: First and Last name, full office address, office phone number(s), office facsimile number(s), DEA #, NPI #, state license number(s)), Prescription data (e.g., one or more of: Date written, date dispensed, drug name, NDC #, drug strength, quantity dispensed, instructions for use, day supply), and, if applicable Dispensing data (e.g., one or more of: Pharmacy name, full address, phone number, dispensing pharmacist's first name, dispensing pharmacist's last name, dispensing pharmacist's state license number(s), dispensing pharmacist's NPI #), and claim type (e.g., what, if any, insurance claim information is used with submitting the prescription claim, and if none, then an indication of NONE. The term CASH may be used to describe the situation where a user is not submitting insurance claim information with a prescription fill request. The insurance or discount card information for the claim may include one or more of: BIN #, PCN #RxID #, Rx Group #, Person code, Insurance's/discount card's pharmacy help desk phone number). In addition, it is advantageous for each record to be associated with a patient name and a unique patient identifier, such as a social security number. It should also be understood that licensed prescribers will also have access to the same information via an equally secure network to help in determining whether or not to prescribe a prescription(s). Generally speaking, as shown in FIG. 6B, some information may be required to submit a claim. For example, in an embodiment, a SSN may be required to submit a prescription fill request. In other embodiments, a First and Last Name, DOB and SSN is mandatory in order to recreate a patient profile, or at least, for every fill request. Obviously, people's addresses change, thus these generally are not good for personal identification information.

[0108] In this respect, the method may include The method further includes receiving a database request via a Bank Identification Number (BIN) specific for the comprehensive prescription database from remote terminals via a secure/encrypted internet communications interface of the universal prescription database. The database request comprises of a new prescription or a refill of an existing prescription. The method includes comparing the transmitted prescription record using the industry standard NCPDP format with existing prescription records associated with the same unique patient identifier and preparing a response based on the comparison in real time. The method further includes sending the response to the remote terminal via the secure communications interface. The responses include, but are not limited to, drug allergies, negative drug-disease state interactions, negative drug-drug interactions, duplicate therapies, early refills (overuse of a medication), and other potential negative problems, in essence providing a comprehensive pre-dispensing check of each prescription filled.

[0109] A method of filling a prescription according to an exemplary embodiment of the present disclosure will now be described in connection with FIGS. 7A and 7B. The first portion of the process, from a prescriber writing a prescription (Step 200) through the pharmacy central database being checked (Steps 226, 228, 232) are substantially the same as described in connection with FIG. 2, and so a detailed description thereof need not be repeated. If the check of the local database and the central database both return positive results (in FIG. 7A), then according to exemplary embodiments of the present disclosure, the responsive server transmits the prescription information to a universal prescription database server at step 500 in FIG. 7B. Preferably, the data transmitted to the universally-utilizable prescription database includes a unique patient identifier, such as a social security number. The universal prescription database receives and transmits data relevant to determining whether each respective prescription attempting to be filled should be filled at any pharmacy terminal regardless of sector (retail, hospital, mail order, among others), and regardless of prescription type, e.g., whether insurance card information or not (e.g., cash payment), or otherwise. Accordingly, the universally-utilizable prescription database server advantageously has the most complete prescription history information available for each patient, regardless of which pharmacies, or how many pharmacies they have used, and regardless of the manner in which the patient pays for their prescriptions, past or present. If the universally-utilizable prescription database server identifies a potential problem, that information is transmitted back to the pharmacist (see FIGS. 8A-13), who can make a decision not to dispense, at step 502 (e.g., by selecting the DO NOT FILL button in FIG. 8A as an example). If the universal prescription database server does not identify any potential problems, than that status is transmitted to the pharmacist at step 504. At this point, the pharmacist has confidence that the prescription can be filled with a minimum chance of medication being dispensed improperly due to limited information available to the pharmacist.

[0110] The universally-utilizable database server may also perform an insurance check in steps 510-518, if insurance information is presented. However, this insurance check could be performed before or after the universally-utilizable database stored information is checked. Further, the universally-utilizable database server may be one server or incorporate additional servers. For example, as described above, an intermediary scriptcheck server may be used to securely communicate with the universally-utilizable database server. However, one server could perform both functions. In this respect, if once the universally-utilizable prescription database has been utilized, if the patient is not using a prescription insurance card, the process can stop, after the prescription is dispensed (Step 506), and the dispensed prescription data is transmitted to be saved in the patient profile (Step 507). If patient insurance card information has been entered into the remote terminal (Step 508), then a record of the prescription request can be transmitted to the insurance company central database 110 server (Step 510). The information transmitted to the insurance company database server 110 can preferably include the results of the universal prescription database check. The insurance company may still identify a problem, such as ineligibility for the particular medication under the patient's insurance coverage, among other potential problems, as will be understood by those of ordinary skill in the art. Accordingly, the insurance company database 110 may alert the pharmacist to a problem (Step 512). The insurance company's recommendation may be followed (Step 514). However, if the insurance company database server 110 does not identify any problems (Step 516), then the pharmacist may dispense the prescription (Step 518). Preferably, the result of the pharmacist ultimately filling a prescription is then transmitted to the universal prescription database so that the universal prescription database has the most complete set of prescription history data available.

[0111] Of course it should be appreciated that the above described system and method are merely exemplary and various changes to the system and method described above may be made without departing from the scope and spirit of the invention. For example, a particular insurance company may determine that the universal prescription database is superior and more cost effective than continuing to maintain their own separate database 110. Accordingly, particular insurance companies may solely utilize the universal prescription database. As such, the universal prescription database could be programmed to analyze eligibility rules of the particular insurance company according to the insurance company's policies. Similarly, individual pharmacies and retail chains may eventually forego maintaining separate prescription databases in favor of the universal prescription database described herein.

[0112] As will be understood, utilizing an exemplary system and/or method as described above, each time a prescription is written by a prescriber and filled at any pharmacy that utilizes a universal prescription database, an extensive search of all available prescription records will be performed to identify potential problems regardless of how many different prescribers and/or pharmacies the patient has used in the past. Advantageously, the results will include not only results of prescriptions filled utilizing an insurance card, but also of those prescriptions filled with no universal insurance card, including those not utilizing any type of insurance or discount card, referred to as CASH customers, discount cards, and so on. This information will then be sent back to the prescriber and/or pharmacy. The prescriber and pharmacist will then be able to evaluate the information and determine which course of action to take.

[0113] By running a universal prescription database search for all prescriptions written, filled and dispensed, new prescriptions and refills, prescribers and pharmacists advantageously have access to substantially all relevant prescription information pertaining to the current prescription being filled, regardless of who prescribed the prescription and where other prescriptions were filled. As a result, substantially all prescription information can pass through one universal prescription database, and all prescribers and pharmacists can access the universal prescription database. As shown in FIG. 5, all prescriptions ultimately end up in one column, illustrating that all information has been transmitted to and stored in the universal prescription database to be used for this, and all other relevant future prescriptions.

[0114] It will readily be appreciated by those of ordinary skill in the art that if the universal prescription database described above were adopted by all prescribers and pharmacies, and if the universal prescription database were checked and updated for all prescriptions filled and refilled, the advantages and overall health improvements to society would be dramatic. Such a system and method would provide a simple, accurate, inexpensive method for prescribers and pharmacists to check for the same issues that are responsible for today's preventable medication errors (by utilizing a complete medication history (i.e., from multiple sources, including those prescription claims not being processed through a prescription insurance carrier)). In addition, the system and method described herein provides a system with which to track prescribing trends for narcotics as well as narcotic abuse. Finally, the system and method described herein would preferably require every person to have a unique patient identifier in the universal prescription database in order to have a prescription filled, or refilled.

[0115] FIGS. 8A-13 show examples of using an embodiment of the present disclosure to achieve a better outcome than is possible with conventional systems. FIG. 8A is a sample screenshot showing displayable information sent as a response returned to a remote terminal from the script server/universal prescription database server illustrating an EARLY REFILL problem warning and the selectable options available to the user terminal. FIG. 8B show exemplary screenshots of information displayed in a remote terminal, in response to a user's selection of a PAYMENT INFORMATION option of FIG. 8A. FIG. 8C is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the early refill warning of FIG. 8A. In the example of FIGS. 8A-8C, a patient fills a prescription for Percocet 5/325 mg at an independent pharmacy (pharmacy 1). The prescription was written by Doctor A for a quantity of 120 tablets with instructions for use that would indicate that the prescription should last no less than 30 days. The patient utilizes a universally accepted insurance card and pays the designated copay.

[0116] Three days later, the same patient makes an appointment to be seen by a second physician, Doctor B. When asked to complete a new patient questionnaire, he makes no reference to any other physician that he is seeing, particularly Doctor A. He proceeds to describe his aliments to Doctor B and indicates to Doctor B that he has seen the best relief from Percocet 5/325 mg. Doctor B in turn prescribes the patient Percocet 5/325 mg, a quantity of 120 tablets, to be take 1 tablet every 6 hours only as needed for pain. This prescription should last no less than 30 days. After leaving the office, the patient proceeds to a retail pharmacy (pharmacy 2). He presents the prescription to the pharmacist, registers as a new patient and indicates that he has no insurance. The pharmacist proceeds to enter the prescription into the pharmacy computer system. A series of checks is performed by the computer to check for drug allergies, negative drug-disease state interactions, negative drug-drug interactions, duplicate therapies, early refills (overuse of a medication), and other potential negative problems. Seeing as the patient had never had any prescriptions filled at this pharmacy or any other within the same chain, no errors are reported. After this initial check, the prescription record is then submitted to the universal prescription database. In real-time, the pharmacist receives an error report instantly indicating an EARLY REFILL problem, shown in FIG. 8A. The error report showed that the same patient had the same prescription filled and dispensed three days earlier at an independent pharmacy. As part of the message received from universal prescription database, the pharmacist also was informed that the patient did in fact have insurance (FIG. 8B). As a result, the pharmacist did not fill the prescription, called the prescribing physician to inform him of the other prescription recently filled, and destroyed the prescription per the physician's request (prescriber's request). FIG. 8C shows an override option, which will be discussed more below.

[0117] FIG. 9A is a sample screen shot showing displayed information sent as a response returned to a remote terminal from the script server/universal prescription database server illustrating a DUPLICATE THERAPY problem warning and the selectable options available to the user terminal. FIG. 9B shows exemplary screenshots of information displayed in a remote terminal, in response to a user's selection of a PAYMENT INFORMATION option of FIG. 9A where the patient does not have a universally-accepted insurance card. FIG. 9C is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DUPLICATE THERAPY warning of FIG. 9A.

[0118] In a second example, as illustrated in FIGS. 9A-9C, an elderly woman arrives for a week-long visit to see her daughter, who lives a few states away. While packing for the trip, she places in an overnight bag all of her current medications including two medications to control her blood pressure (Hyzaar and Diovan), one medication to control her heart rate (Digoxin) and one medication to prevent blood clots (Warfarin). During her flight, she began experiencing slight chest pains and shortness of breath. So not to alarm anyone, she doesn't tell anyone until the plane lands. Upon landing, an ambulance takes her to the nearest hospital for evaluation. After a few hours, she is seen by an emergency room physician who looks over the list of medications that she provided to them. While she did remember to tell the physician that she was being treated with Hyzaar, Digoxin and Warfarin, she forgot to tell him of the Diovan. After completing all necessary tests, it was determined that the patient had experienced a panic attack. In addition, her blood pressure was a bit higher that designated. The ER physician decided to keep her on all of her current medications but to also add another anti-hypertensive medication to control her blood pressure better. She was advised to continue all previous medication as well as filling the new one immediately and beginning it. Upon leaving the hospital, she proceeds to the nearest pharmacy, a small independent store around the corner. She registers with the pharmacist and informs her that she does not have insurance. The pharmacist proceeds to process the new prescription. As soon as the pharmacist transmits the claim into the universal prescription database, a DUPLICATE THERAPY problem (FIG. 9A) response (including displayable information) is returned. The pharmacist recognizes that the patient was already on two anti-hypertensive medications. The pharmacist asks the patient if she notified the ER doctor of this and she said that she had not. The pharmacist calls the ER to speak with the prescribing doctor to inform him of this. As a result, the doctor told the pharmacist to cancel the prescription and inform the patient to simply continue taking the medications she was currently on.

[0119] FIG. 10A is a sample screen shot illustrating displayable information sent as a response returned to a remote terminal from the script server/universal prescription database server illustrating an DRUG-DRUG INTERACTION (INTX) problem warning and the selectable options available to the user terminal. FIG. 10B shows an exemplary screenshot of information displayed in a remote terminal, in response to a user's selection of a PAYMENT INFORMATION option of FIG. 10A. FIG. 10C is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DRUG-DRUG INTERACTION (INTX) warning of FIG. 10A.

[0120] In a third example, as shown in FIGS. 10A-10C, an elderly man is living in a high rise housing complex. He is on a fixed income and is very cautious of what he spends. As a result, he gets a variety of maintenance prescriptions filled at 2 separate, unrelated pharmacies. He utilizes his prescription insurance card at one pharmacy (Pharmacy 1) to fill some prescriptions, and pays cash for other prescriptions at another pharmacy (Pharmacy 2). He utilizes the second pharmacy to take advantage of the $3 prescriptions they offer, which is cheaper than utilizing his prescription card. One day complains to his primary physician about a high fever and overall weakness. After a complete examination, the physician determines that the patient has a bacterial infection and prescribes the antibiotic Flagyl to treat it. He hands the prescription to the patient, who then proceeds to the pharmacy. Arriving at Pharmacy 1, the patient presents the prescription to the pharmacist. Upon entering the prescription data into the pharmacy computer system, the pharmacist runs a check on all of the current medications that the patient has filled at this pharmacy. As no problems are reported, the prescription is then sent to the universal prescription database for a more extensive check. Immediately, the pharmacist receives a message indicating a severe DRUG-DRUG INTERACTION problem (FIG. 10A) with a prescription that the patient routinely has filled at Pharmacy 2, Warfarin. Immediately, the pharmacist informs the patient of the interaction, contacts the physician for an alternative medication and proceeds to safely fill the new antibiotic.

[0121] FIG. 11A shows a sample screenshot illustrating information displayed by the remote terminal, which is received in a response returned to the remote terminal from the script server/universal prescription database, the displayed information showing a DRUG-DISEASE STATE INTERACTION (INTX) problem warning. FIG. 11B is a sample screen shot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DRUG-DRUG DISEASE STATE INTERACTION (INTX) warning of FIG. 11A.

[0122] In a second example, as shown in FIGS. 11A-11C, a patient presents to a pharmacy for the first time. Upon registering as a new patient, he informs the pharmacist that the only medical condition that he is being treated for is hypertension (high blood pressure). He presents his prescription drug card, which was issued by the state department of welfare. This particular insurance card is only accepted in the state in which it was issued (in this case, Pennsylvania). He routinely gets his hypertensive medications filled at the same pharmacy. As a result, the universal prescription database has an up-to-date record of his drug allergies and health conditions. While on vacation in upstate New York, he begins to develop flu-like symptoms and decides to visit an urgent care facility. This facility has no record of this patient in their system. As a result, they must rely on the patient giving them an accurate, up-to-date medical history, including drug allergies and health conditions. Being in a hurry to get back to his hotel and rest, he forgets to inform the physician that he is being treated for hypertension. Prior to prescribing anything, the physician utilizes an in-house computer to transmit the prescriptions that he wishes to prescribe the patient to the universal prescription database. In real-time, the prescriber receives notification that the patient is currently taking a hypertensive medication (FIG. 11A), which is a contraindication for the decongestant that he wanted to prescribe. The physician consults the patient, who immediately remembered that he forgot to tell the doctor of this. As a result, the physician was able to switch the medication to something safer.

[0123] FIG. 12A shows a sample screenshot illustrating information displayed by the remote terminal, which is received in a response returned to the remote terminal from the script server/universal prescription database, the displayed information showing a DRUG ALLERGY problem warning and the selectable options available to the user terminal. FIG. 12B is a sample screenshot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the DELETE ALLERGY option to override the DRUG ALLERGY warning of FIG. 12A. FIG. 12C is a sample screenshot showing confirmation of the data stored by the universal prescription database server for reporting purposes when a pharmacist chooses the PHARMACIST OVERRIDE option to override the DRUG ALLERGY warning of FIG. 12A.

[0124] In a fifth example, as shown by FIGS. 12A-12C, a patient presents to the independent pharmacy (pharmacy 1) that he uses when he needs a prescription filled to inform his pharmacist that he has recently discovered that he has a drug allergy to Penicillin. The pharmacist updates his patient profile to indicate the newly identified drug allergy. Not long after, the patient is prescribed Azithromycin to treat a sore throat. During the filling process, this prescription data is transferred into the universal prescription database to check for any problems, such as drug allergies, negative drug-disease state interactions, negative drug-drug interactions, duplicate therapies, early refills (overuse of a medication), and other potential negative problems. The universal prescription database updates the patient's centralized profile to update the newly reported Penicillin allergy. Years pass and luckily the patient has not had a need for any prescriptions to be filled. During that time, however, the patient moved to a new state and was forced to find a new family care physician after coming down with an illness. During his first visit to the new physician, he fills out a new patient form. While filling out the form, he forgets to indicate the drug allergy to Penicillin that his previous physician identified years back. As the present physician was unaware of the allergy, he prescribes Penicillin to treat his condition. The patient then proceeds to a chain pharmacy (pharmacy 2) to have the prescription filled. As he has never used this particular pharmacy before, or any within the same chain, he takes a moment to provide his information to the pharmacist to enter in the computer system. Again forgetting his allergy to Penicillin, he neglects to inform the pharmacist of his drug allergy. The pharmacist proceeds to fill the prescription. After entering the prescription data into the pharmacy system, no problems are identified. Proceeding next to the step, the prescription data is then sent to the universal prescription database. After running a complete, detailed check an error is reported back to the pharmacist (FIG. 12A) indicating that the patient has in the past reported an allergy to Penicillin. The result identified the date the allergy was reported as well as which pharmacy reported it. The pharmacist asks the patient about the reported allergy and confirmed that it was a true allergy. As a result, the pharmacist chose not to fill the prescription and called the prescribing physician for an alternative.

[0125] FIG. 13 is a sample screenshot illustrating the response returned to a remote from the universal prescription database indicating that a complete search was performed, how many errors were overridden, and what those error were. In a sixth example, as illustrated by FIG. 13, a local Drug Enforcement Agency (DEA) agent presents to number of local pharmacy's inquiring about the prescribing habits of a local physician who has come under investigation for over-prescribing narcotics. After an extensive investigation, it was determined that an extraordinary number of prescriptions were prescribed by the physician over the period of 2 years. As part of the investigation, the DEA, through the appropriate legal steps, also requested records from the universal prescription database to support the over-prescribing habits. In the report, all of the dispensed prescriptions written by this physician were supplied. The report showed the following for each dispensed prescription: the date the prescription was written, the date the prescription was dispensed, the prescribing physician, the prescribing physician's DEA number, the prescribing physician's NPI number, the prescribing physician's state license number(s), the prescribing physician's full office address, the prescribing physician's office phone and facsimile numbers, the name of the drug, the drug strength, the quantity dispensed, and the day supply of the prescription. In addition, the report also showed for each dispensed prescription the name of the pharmacy that it was dispensed at, the full address of the pharmacy, the phone number of the pharmacy, the dispensing pharmacist's full name, and the dispensing pharmacist's NPI number and state license number. Finally, and most importantly, the report showed that for each prescription that was filled, the universal prescription database reported numerous errors that were reported back to the pharmacist for review. Each time the pharmacist overrode an error, the universal prescription database recorded the type of error(s), the name of the pharmacist who overrode the error(s), the overriding pharmacist's NPI number and state license number(s). Upon review of the report, it was identified that the majority of the prescriptions prescribed by the physician were filled at the same pharmacy and dispensed by the same pharmacist. By means of evaluating the recorded overrides of this specific pharmacist, it was determined that the prescriber and physician were working together.

[0126] In each of the above examples, it can be seen that the use of a universally-utilizable prescription database advantageously provides prescribers and pharmacists with important information that they can use to achieve better outcomes for patients, including avoiding negative drug interactions, and preventing abuse of prescription drugs. In each of the examples, conventional systems are insufficient to provide the pharmacist with sufficient information to achieve these better outcomes. It will also be appreciated that the more prescribers and pharmacies that participate in the universal prescription database, the more effective it will be.

[0127] The below chart compares preferred features of an exemplary embodiment of the present disclosure to a conventional system and database maintained by, for example, an insurance company. While the disclosure has been shown and described with reference to certain embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims.

TABLE-US-00001 Universal Prescription Conven- Database tional General Information System Systems 1. Uses a centralized computer database X X 2. Database communicates centrally with X X all pharmacies nationwide 3. Database could be utilized by X X pharmacists 4. Database requires a separate log in by pharmacist to utilize the database 5. Database could be accessed by X prescribers 6. Database requires a separate log-in by X prescriber to utilize the database 7. Database tracks ALL prescriptions X filled and dispensed 8. Database tracks filling history for ALL X medications for each individual 9. Database tracks prescribing habits of X X prescriber for ALL medications 10. Database will securely store and X transmit ONLY relevant data with regard to ALL prescriptions attempting to be filled 11. Database will provide responses in X X real-time to remote terminals 12. Database has reporting capabilities X X

TABLE-US-00002 Universal Prescription Conven- Database tional Use of System System Systems 1. System could be utilized by: Pharmacists X X Prescribers X X Hospital Staff (other than prescribers) Insurance Companies X X Government Agencies X 2. Use of the system is initiated at the level of: Pharmacist X X Prescriber X 3. Database will communicate with X prescriber/pharmacist by sending relevant information back to the remote location via secure messaging system 4. Database will store data immediately (in X X real-time) for immediate use by multiple remote locations 5. The decision to prescribe, fill and dispense X a prescription is based on the information sent back to the prescriber and pharmacist (at remote locations) from the universal database

TABLE-US-00003 Universal Prescription Conven- Database tional Information System Systems 1. Data required for the system to work: Patient's full name X X Patient's date of birth X X Patient's social security number X Drug name X X Drug strength X X Drug quantity X X Drug sig. (instructions for use) X X Day supply of prescription X X Prescriber's full name X X Prescriber's DEA # X X Prescriber's NPI # X X Prescriber's state license # X X Prescriber's office address X Prescriber's office phone # X 2. After filling each prescription, both new and refills, the system will store: Patient's full name X X Patient's full address X Patient's phone # X Patient's date of birth X X Patient's social security number X Prescriber's full name X X Prescriber's full office address X Prescriber's office phone # X Prescriber's office facsimile # X Prescriber's DEA # X X Prescriber's NPI # X X Prescriber's state license # X X Date the prescription was written X X Date the prescription was dispensed X X Drug name X X Drug NDC # X X Drug strength X X Drug quantity X X Drug sig. (instructions for use) X X Day supply of prescription X X Pharmacy name X X Pharmacy's full address X Pharmacy's phone # X Dispensing pharmacist's full name X Dispensing pharmacist's state license # X Dispensing pharmacist's NPI # X Payment information X If insurance used, the following is obtained: 1. BIN # X 2. PCN # X 3. RxID # X 4. Rx Group # X 5. Person Code X 6. Insurance pharmacy help desk phone # X 3. Each prescription run through the universal prescription database will return the following information relevant to each prescription attempting to be filled: Patient's full name X X Patient's full address X Patient's phone # X Patient's date of birth X X Patient's social security number X Prescriber's full name X X Prescriber's full office address X Prescriber's office phone # X Prescriber's office facsimile # X Prescriber's DEA # X X Prescriber's NPI # X X Prescriber's state license # X X Date the prescription was written X X Date the prescription was dispensed X X Drug name X X Drug NDC # X X Drug strength X X Drug quantity X X Drug sig. (instructions for use) X X Day supply of prescription X X Pharmacy name X X Pharmacy's full address X Pharmacy's phone # X Filling pharmacist's full name X Filling pharmacist's state license # X Filling pharmacist's NPI # X Payment information X If insurance used, the following is obtained: 1. BIN # X 2. PCN # X 3. RxID # X 4. Rx Group # X 5. Person Code X 6. Insurance pharmacy help desk phone # X 4. The universal prescription database will X store all information for every prescription filled (new or refill) by all persons regard- less of whether or not the person utilized a universally accepted insurance card. 5. Once verified through the universal X prescription database, the database will then allow for claim transmission to all insurance company computer systems (if patient is utilizing an insurance card) to verify the insurance company's restrictions/limitations

TABLE-US-00004 Universal Prescription Conven- Database tional Reporting Capabilities System Systems 1. System tracks prescribing habit of X prescriber for ALL prescriptions written 2. Prescriber prescribing report includes: Prescriber's full name X Prescriber's full office address X Prescriber's office phone # X Prescriber's office facsimile # X Prescriber's DEA # X Prescriber's NPI # X Prescriber's state license # X Patient's full name X Patient's full address X Patient's phone # X Patient's date of birth X Patient's social security number X Date the prescription was written X Date the prescription was dispensed X Drug name X Drug NDC # X Drug strength X Drug quantity X Drug sig. (instructions for use) X Day supply of prescription X Pharmacy name X Pharmacy's full address X Pharmacy's phone # X Filling pharmacist's full name X Filling pharmacist's state license # X Filling pharmacist's NPI # X Payment information X If insurance used, the following is obtained: 1. BIN # X 2. PCN # X 3. RxID # X 4. Rx Group # X 5. Person Code X 6. Insurance pharmacy help desk phone # X 2. System tracks pharmacist over ride history for ALL prescriptions written 3 Pharmacist over ride report includes: The type of override (e.g. early refill) X Filling pharmacist's full name X Filling pharmacist's state license # X Filling pharmacist's NPI # Prescriber's full name X Prescriber's full office address X Prescriber's office phone # X Prescriber's office facsimile # X Prescriber's DEA # X Prescriber's NPI # X Prescriber's state license # X Patient's full name X Patient's full address X Patient's phone # X Patient's date of birth X Patient's social security number X Date the prescription was written X Date the prescription was dispensed X Drug name X Drug NDC # X Drug strength X Drug quantity X Drug sig. (instructions for use) X Day supply of prescription X Pharmacy name X Pharmacy's full address X Pharmacy's phone # X Payment information X If insurance used, the following is obtained: 1. BIN # X 2. PCN # X 3. RxID # X 4. Rx Group # X 5. Person Code X 6. Insurance pharmacy help desk phone # X 3. System tracks patient fill history of ALL medications dispensed 4 Patient fill history report includes: Patient's full name X X Patient's full address X Patient's phone # X Patient's date of birth X X Patient's social security number X Prescriber's full name X X Prescriber's full office address X Prescriber's office phone # X Prescriber's office facsimile # X Prescriber's DEA # X X Prescriber's NPI # X X Prescriber's state license # X X Date the prescription was written X X Date the prescription was dispensed X X Drug name X X Drug NDC # X X Drug strength X X Drug quantity X X Drug sig. (instructions for use) X X Day supply of prescription X X Pharmacy name X X Pharmacy's full address X Pharmacy's phone # X Filling pharmacist's full name X Filling pharmacist's state license # X Filling pharmacist's NPI # X Payment information X If insurance used, the following is obtained: 1. BIN # X 2. PCN # X 3. RxID # X 4. Rx Group # X 5. Person Code X 6. Insurance pharmacy help desk phone # X