System and method for automating pharmacy processing of electronic prescriptions

A method and system may provide an automated pharmacy processing system which automatically processes an electronic prescription by converting the electronic prescription into a pharmacy prescription record. In this way, an electronic prescription can be filled by a pharmacist without manual data entry. The system receives an electronic prescription and compares data from the electronic prescription with entries in one or more pharmacy database(s). When there is a match between the electronic prescription data and an entry in the one or more pharmacy database(s), the system populates the pharmacy prescription record with data from the matching pharmacy database entry. If all of the data fields from the pharmacy prescription record have been populated the pharmacist can fill the electronic prescription.

TECHNICAL FIELD

The present disclosure generally relates to a system and method for automating pharmacy processing of electronic prescriptions, and more particularly to fully generating pharmacy prescription records based on data from electronic prescriptions, in an efficient and expeditious manner.

BACKGROUND

Health care costs have been increasing at a fast rate. In an attempt to reform health care, legislation in the United States that includes incentivizing payors and providers to cooperate has been passed. As such, health providers are changing their approaches to providing health care to patients. Coordination of health care across multiple health care providers or health care organizations may not only decrease the cost of health care to payors, but may also improve the quality of health care to patients. Health care organizations may include pharmacy entities or enterprises that fill or provide prescription products and services, hospitals, health care data repositories, managed care organizations, physicians and/or physician groups, and other medical professionals that are licensed to prescribe medical products and medicaments to patients.

As a result, electronic prescriptions written by a physician are becoming increasingly more popular. However, electronic prescriptions from a physician are organized in a different format than the pharmacy prescription data necessary for a pharmacist to fill a prescription. Additionally, there are many variations of electronic prescriptions which have different data fields, some providing more detail than others and also which are organized in a variety of ways. The systems currently in place require a technician to read the electronic prescription and manually enter data from the electronic prescription into pharmacy prescription data fields. Once the technician has entered the data from the electronic prescription the pharmacist can fill the prescription. This manual process can be time consuming, leads to additional work for the technician and increases the likelihood of errors in the pharmacy prescription data.

DETAILED DESCRIPTION

A “health care organization,” as used herein, refers to a health care related enterprise or health care provider. The health care organization may be for profit or not-for-profit. The health care organization may provide health care diagnostic, therapeutic, rehabilitation, and other services to patients. For example, the health care organization may provide physician care, therapy, imaging, counseling, or the like. The health care organization may provide inpatient and/or outpatient services, may include one or more physical locations or facilities. Additionally or alternatively, the health care organization may provide other health-care related services, such as providing billing management, providing health care insurance, maintaining electronic medical records, etc. Examples of health care organizations may include a hospital group, a medical practice group, an insurance group, a stand-alone imaging facility, a home-health service provider, and others. In some embodiments, a health care organization may include a pharmacy enterprise.

As used herein, the term “customer” indicates someone purchasing a retail product but may additionally be, by way of example, a patient (i.e., the person named on the prescription), a guardian (e.g., the parent of a child named on the prescription), a care-giver (i.e., anyone who takes care of a patient or picks up the medication on the patient's behalf), etc. Moreover, the term “customer” is not limited to a single person, but may instead be any person or persons having a reason or desire to purchase one or more retail products or to perform one or more functions relating to prescription medications, whether the prescriptions are related to a single patient or multiple patients. For example, a customer could be a caregiver responsible for patients with a specific disease that progresses in a known manner. The caregiver customer might greatly benefit from gaining information related to various medications and health products to assist in his or her caregiver responsibilities. In any event, while the term “customer” may be used interchangeably with the term “patient,” in this specification the term “patient” is used primarily so as to avoid confusion.

Generally speaking, an automated pharmacy processing system (also referred to herein as “the system”) receives an electronic prescription from a health care organization using electronic medical records (EMRs), electronic health records (EHRs), or standalone e-Prescribing systems. The system automatically converts the information from the electronic prescription into a pharmacy prescription record, which can be filled by a pharmacist at a selected pharmacy location, without requiring a technician to manually enter data from the electronic prescription into the pharmacy processing system. The automated pharmacy processing system may convert patient identification information, prescribing physician (also referred to herein as a “prescriber”) identification information, medication information, drug quantity, drug days' supply and prescriber instructions (SIG) from an electronic prescription format into the pharmacy prescription record. In addition, the automated pharmacy processing system may determine whether generic substitution of a brand name medication is allowed and substitutes the generic for the brand name medication on the electronic prescription.

Although the automated pharmacy processing system receives the electronic prescriptions via a digital network, the format in which the information or data is stored in an electronic prescription is different from the format in which pharmacy prescription data or records are stored. Therefore, it may be necessary to convert the data in an electronic prescription into a pharmacy prescription record format. To demonstrate the difference in formatting,FIG. 1illustrates an exemplary electronic prescription for a particular patient. However, this is merely an example and electronic prescriptions may be formatted in any suitable number of ways. In the example ofFIG. 1, the electronic prescription100includes several data fields which may be grouped into multiple prescription components for the automated pharmacy processing system. The prescription components include patient information, prescriber information, medication name information, quantity and days' supply and prescriber instructions.

For example, a patient name field102, a patient age field104, and a patient address field108may fit within the patient information component. On the other hand, a prescriber name field116, a DEA number field118, a prescriber license number field120, a prescriber phone number field122, and a prescriber facility field124may fit within the prescriber information component. Electronic prescription data which may fit within the medication name information component includes a medication name110, a medication size130and a dispense as written (DAW) field126which is used to determine whether a generic substitute is permitted. Additionally, a number of days field128and a dispense (DISP) field114may fit within the days' supply and quantity components, respectively, while a prescriber instructions (SIG) field112may fit within the prescriber instructions component. The electronic prescription100may also include an indication of a pharmacy location for the patient to pick up the prescription. Alternatively, the pharmacy location may default to the closest location to the patient address108.

In one embodiment, the automated pharmacy processing system may detect data by parsing the electronic prescription100to find field identifiers and XML tags corresponding to data fields. For example, the electronic prescription100may follow the SCRIPT standard defined and maintained by the National Council for Prescription Drug Programs (NCPDP), which defines field identifiers and XML tags for each data field. For example, the system may parse the electronic prescription100for an XML tag or field identifier indicating a DEA number field. However, this is merely one example of how data within an electronic prescription may be detected and categorized by the automated pharmacy processing system. Alternatively, data may be detected and categorized in any suitable number of ways and in some implementations data from the electronic prescription may not be categorized. For ease of illustration only, this application will continue to describe detecting data from an electronic prescription in the manner described above.

Once the automated pharmacy processing system detects data from the electronic prescription, the data is compared to one or more pharmacy database(s) illustrated inFIGS. 2-4. The one or more pharmacy database(s) illustrated inFIGS. 2-4may be one database or a group of two or more databases. Each figure corresponds to one of the prescription components mentioned above.

AlthoughFIGS. 2-4depict the one more pharmacy database(s) as including only a few data entries, it should be understood that several data entries may be utilized. For example, the one or more pharmacy database(s) may include thousands of data entries. However, for ease of illustration only, merely a portion of the one or more pharmacy database(s) is illustrated inFIGS. 2-4.

FIG. 2illustrates a portion of a pharmacy patient database200corresponding to the patient information component. Once the automated pharmacy processing system detects the data in the electronic prescription associated with patient information, the system compares the data from the electronic prescription to the data stored in the pharmacy patient database200. Data in the pharmacy patient database200may include a patient identification number210such as a Medical Record Number (MRN), a patient name220, a patient birth date230, a patient address240, a patient phone number250, an insurance provider260along with other insurance information, and a list of allergies270. However, this is just an example and additional or alternative data may also be stored in the pharmacy patient database200.

In any event, data which is detected from the electronic prescription is compared to the data entries in the pharmacy patient database200to find a match. If the data detected from the electronic prescription as patient information is the same as one row of data fields (also referred to herein as an “entry”) in the pharmacy patient database200then a match is generated, and the automated pharmacy processing system places the data corresponding to the matching entry in the pharmacy patient database200into a pharmacy prescription record. In an embodiment, if one data field from the electronic prescription matches with one data field of an entry in the pharmacy patient database200, such as the patient identification number, then a match is generated for the entry. In other embodiments, more than one data field of the electronic prescription may need to be the same as more than one data field of an entry in the pharmacy patient database200to generate a match. In some embodiments the automated pharmacy processing system places only some of the data corresponding to the matching entry into the pharmacy prescription record.

For example, with reference toFIG. 1, the automated pharmacy processing system detects patient name102as “Chris Bryant,” patient address108as “555 N. Michigan Avenue, Chicago, IL.” and patient age104as “21.” The system then looks up information in the pharmacy patient database200to find a matching entry. Because the automated pharmacy processing system does not detect a patient identification number in the electronic prescription100, the system skips the first column210and detects whether the patient name220in entry202is the same as the patient name detected in the electronic prescription100. However, the names do not match and the system proceeds to the next entry until it finds an identical name in entry206“Chris Bryant.” The system may then proceed to check whether other data fields in entry206are also the same as the data detected in the electronic prescription, because there may be multiple patients named “Chris Bryant” in the pharmacy patient database200. After comparing the patient information from the electronic prescription to an entry206in the pharmacy patient database, the automated pharmacy processing system determines whether to generate a match.

If the system determines there is a match, then information from the matching entry is used to populate the pharmacy prescription record. However, if the system determines there is no match, because the pharmacy patient database200does not store information similar to the detected patient information from the electronic prescription100, then the system generates a new entry into the pharmacy patient database200using the detected patient information and populates the pharmacy prescription record with the new entry. On the other hand, if the system determines there are multiple matches, because the system cannot distinguish the detected patient information from multiple entries of the pharmacy patient database200, the system requires manual entry into the pharmacy prescription record.

FIG. 3illustrates a portion of a pharmacy prescriber database300corresponding to the prescriber information component. Once the automated pharmacy processing system detects the data in the electronic prescription associated with prescriber information, the system compares the data from the electronic prescription to the data stored in the pharmacy prescriber database300. Data in the pharmacy prescriber database300may include a prescriber identification number310such as a National Provider Identifier (NPI) or a prescriber license number, a prescriber name320, a practice name330, a prescriber address340, a DEA number350, and a prescriber phone number360. However, this is just an example and additional or alternative data may also be stored in the pharmacy prescriber database300.

In any event, data which is detected from the electronic prescription is compared to the data entries in the pharmacy prescriber database300to find a match. If the data detected from the electronic prescription as prescriber information is the same as one entry or row of data fields in the pharmacy prescriber database300then a match is generated, and the automated pharmacy processing system places the data corresponding to the matching entry in the pharmacy prescriber database300into a pharmacy prescription record. In an embodiment, if one data field from the electronic prescription matches with one data field of an entry in the pharmacy prescriber database300, such as the prescriber identification number, then a match is generated. In other embodiments, more than one data field of the electronic prescription may need to be the same as more than one data field of an entry in the pharmacy prescriber database300to generate a match. In some embodiments the automated pharmacy processing system places only some of the data corresponding to the matching entry into the pharmacy prescription record.

For example, with reference toFIG. 1, the automated pharmacy processing system detects prescriber name116as “John Doe,” DEA number118as “AA5555555” and license number120as “111111111.” Other prescriber information fields such as prescriber phone number122and prescriber facility124are left blank.

The system then looks up information in the pharmacy prescriber database300to find a matching entry. The same prescriber identification number310is found at entry302“111111111.” At this point, the system may determine the information is the same and generates a match, because each prescriber has a unique identification number (National Provider Identifier (NPI) and/or other identifiers) and therefore duplicates do not exist. However, the system may compare the other data fields of entry302to make sure an error does not exist in either the pharmacy prescriber database300or the detected prescriber information of the electronic prescription100. In this case, the system determines the prescriber name320in entry302“John Doe” is also the same as the prescriber name116in the electronic prescription100.

If the system determines there is a match, then information from the matching entry is used to populate the pharmacy prescription record. However, if the system determines there is no match or there are multiple matches, the system requires manual entry into the pharmacy prescription record. The system determines there is no match when the pharmacy prescriber database300does not store information similar to the detected prescriber information from the electronic prescription100. Multiple matches occur when the system cannot distinguish the detected prescriber information from multiple entries of the pharmacy prescriber database300.

In addition to comparing prescriber information,FIG. 4illustrates a portion of a pharmacy medication database400corresponding to the medication information component. Once the automated pharmacy processing system detects the data in the electronic prescription associated with medication information, the system compares the data from the electronic prescription100to the data stored in the pharmacy medication database400. Data in the pharmacy medication database400may include a medication name410, a medication size420, a generic equivalent430, and whether the medication is a controlled substance440. The pharmacy medication database may also include a DAW code (not shown) and an NDC code (not shown). However, this is just an example and additional or alternative data may also be stored in the pharmacy medication database400.

In any event, data which is detected from the electronic prescription is compared to the data entries in the pharmacy medication database400to find a match. If the data detected from the electronic prescription as medication information is the same as one entry or row of data fields in the pharmacy medication database400then a match is generated. In an embodiment, if one data field from the electronic prescription matches with one data field of an entry in the pharmacy medication database400, such as the NDC code, then a match is generated. In other embodiments, more than one data field of the electronic prescription may need to be the same as more than one data field of an entry in the pharmacy medication database400to generate a match. If data detected from the electronic prescription indicates that generic substitution is permitted, then the automated pharmacy processing system places the data corresponding to the matching entry in the pharmacy medication database400, including the generic equivalent but not the medication name, into a pharmacy prescription record. In the event there are multiple manufacturers for the generic drug, the automated pharmacy processing system checks the inventory system or modules to determine the exact generic product to dispense. On the other hand, if there is no indication from the electronic prescription data that generic substitution is permitted, the automated pharmacy processing system places the medication name into the pharmacy prescription record but does not place the generic equivalent.

For example, with reference toFIG. 1, the automated pharmacy processing system detects the medication name110as “Prozac,” the medication size130as “10 milligrams,” and DAW126as “No” meaning generic substitute is permitted.

The system then looks up information in the pharmacy medication database400to find a matching entry. The same medication name410is found at entry402“Prozac.” The system may then compare the medication size420of entry402to the medication size detected in the electronic prescription. Here, the system determines the sizes are different and proceeds to entry404where both the medication name and the medication size is the same as in the electronic prescription.

If the system determines there is a match, then information from the matching entry is used to populate the pharmacy prescription record. However, if the system determines there is no match or there are multiple matches, the system requires manual entry into the pharmacy prescription record. The system determines there is no match when the pharmacy medication database400does not store information similar to the detected medication information from the electronic prescription100. Multiple matches occur when the system cannot distinguish the detected medication information from multiple entries of the pharmacy medication database400.

For example, the system places the entry404into the pharmacy prescription record, excluding the medication name Prozac but including the generic equivalent Fluoxetine HCL, because the system detects DAW126“No” in the electronic prescription100and determines generic substitution is permitted.

The automated pharmacy processing system also detects a quantity and a days' supply from the electronic prescription. With reference toFIG. 1, the system detects the quantity as “120” in the dispense field114and the days' supply as “30” in the days field128. The detected quantity and days' supply are then used to populate the pharmacy prescription record. In addition, the automated pharmacy processing system detects prescriber instructions and translates the instructions into a data field of the pharmacy prescription record. For example, the automated pharmacy processing system may include a stored list of predetermined prescriber instruction components which can be combined together and then placed into the pharmacy prescription record. The prescriber instructions from the electronic prescription may be parsed to determine individual components and then translated into a combination of predetermined prescriber instruction components from the stored list. Predetermined prescriber instruction components may include an action, dosage, frequency, route of administration, etc.

For example, with reference toFIG. 1, the automated pharmacy processing system detects prescriber instructions in the SIG field112of the electronic prescription100, which state “Ingest 4 10 mg capsules, once a day.” The system may then translate the action component, “Ingest” to “Take” which corresponds to one of the predetermined prescriber instruction components in the stored list. Moreover, the system may translate the dosage component “4 10 mg capsules” to “4 10 mg capsules.” The system may also translate the frequency component “once a day” to “daily” and combine the translated components to get the phrase, “Take 4 10 mg capsules daily.” The translated entry is then placed in the pharmacy prescription record. However, if there is no translation which corresponds to one of the predetermined instruction components in the stored list, the system requires manual entry into the pharmacy prescription record.

When there is a translation for the prescriber instructions, the translation may be compared to the days' supply and quantity to make sure a discrepancy does not exist. For example, the days' supply and quantity of the electronic prescription100is 30 and 120 respectively, meaning the patient has 120 capsules to take in 30 days. The prescriber instructions indicate taking four capsules a day, and four capsules a day for 30 days amounts to 120 capsules. Therefore, the days' supply and quantity are not at odds with the prescriber instructions. However, when there is a difference, the automated pharmacy processing system may remove the prescriber instructions, quantity, and/or days' supply from the pharmacy prescription record and may require manual entry.

After each of the prescription components have been detected, the automated pharmacy processing system determines whether manual entry is required for any of the prescription components. If manual entry is not required, the pharmacy prescription record is sent to a workstation corresponding to the selected pharmacy location and added to a list of prescriptions for a pharmacist at the selected pharmacy location to fill. On the other hand, if manual entry is required, the pharmacy prescription record is transmitted to a workstation corresponding to the selected pharmacy location for manual entry before it can be filled.

FIGS. 5A, 5B and 5Cdepict a flow diagram representing an exemplary method500for implementing the automated pharmacy processing system. A prescriber sends electronic prescriptions using electronic medical records (block502) along with a pharmacy location for filling the electronic prescription (block504) to the automated pharmacy processing system. The automated pharmacy processing system then detects patient information from the electronic prescription (block506) and compares this with pharmacy patient data stored in a pharmacy patient database (block508). If there is a match, the system populates a pharmacy prescription record with patient data from the pharmacy patient database (block514). Otherwise, the system automatically creates a new patient data entry in the pharmacy patient database using the patient information from the electronic prescription (block512) and then proceeds to block514.

Next, the system detects prescriber information from the electronic prescription (block516) and compares this with pharmacy prescriber data stored in a pharmacy prescriber database (block518). If there is a match, the system populates a pharmacy prescription record with prescriber data from the pharmacy prescriber database (block522). Otherwise, the system proceeds to block524where medication information from the electronic prescription is detected.

Continuing on toFIG. 5B, the detected medication information from the electronic prescription is compared to pharmacy medication data in a pharmacy medication database (block526). If there is no match, the system proceeds to block536. However, if there is a match, the system determines whether generic substitution of a brand name medication is permitted (block530). This can be determined, for example, by detecting whether a dispense as written field is included in the electronic prescription, or by detecting whether the electronic prescription specifies that generic substitution is allowed. If generic substitution is permitted, the system populates a pharmacy prescription record with medication data from the pharmacy medication database including the generic equivalent of the brand name medication (block532). In the event there are multiple manufacturers for the generic drug, the automated pharmacy processing system checks the inventory system or modules to determine the exact generic product to dispense. If generic substitution is not permitted, the system alternatively populates a pharmacy prescription record with the brand name medication (block534).

At block536, a quantity and days' supply is detected from the electronic prescription and the pharmacy prescription record is populated with the quantity and days' supply (block538). Then, prescriber instructions from the electronic prescription are detected (block540).

Moving on toFIG. 5C, if the prescriber instructions can be translated into instructions which have been formatted for the pharmacy prescription record (e.g., instructions which are made up of a set of predetermined prescriber instruction components from the stored list), the instructions are translated and placed in the pharmacy prescription record (block544), and the system determines whether the instructions are consistent with the quantity and supply (block546). If the instructions are consistent, the system determines whether each of patient data, prescriber data, medication data, quantity and days' supply, and prescriber instructions have been populated in the pharmacy prescription record. If they all have, the pharmacy prescription record is added to a list of prescriptions for a pharmacist to fill at the selected pharmacy location (block550). Otherwise, the pharmacy prescription record is transmitted to the pharmacy location for manual data entry (block552).

FIG. 6illustrates various aspects of an exemplary architecture implementing the automated pharmacy processing system600. In particular,FIG. 6illustrates a block diagram of the automated pharmacy processing system600. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The automated pharmacy processing system600may be roughly divided into front-end components602and back-end components604. The front-end components602are primarily disposed within a retail network610including one or more pharmacies612. The pharmacies612may be located, by way of example rather than limitation, in separate geographic locations from each other, including different areas of the same city, different cities, or even different states. The front-end components602comprise a number of pharmacy workstations628. The pharmacy workstations628are local computers located in the various pharmacies612throughout the retail network610and executing various pharmacy management-related applications. Pharmacists, technicians, and other pharmacy personnel, referred to collectively herein simply as “pharmacists” (not shown), use the pharmacy workstations628to access customer information, enter new prescriptions, access insurance and payment information and so forth. Each of the pharmacies612may be, for example, an in-store retail pharmacy, an on-line pharmacy, a mail-order pharmacy, a long-term care pharmacy, a workplace/on-site pharmacy, or a specialty pharmacy. The retail network610may also include one or more warehouses or central-filling facilities618. The warehouses or central-filling facilities618may distribute medications or retail products to the various retail pharmacies612in the retail network610, or may distribute medications or retail products directly to customers.

Those of ordinary skill in the art will recognize that the front-end components602could also comprise a plurality of facility servers626disposed at the plurality of pharmacies612instead of, or in addition to, a plurality of pharmacy workstations628. Each of the pharmacies612may include one or more facility servers626that may facilitate communications between the workstations628of the pharmacies612via a digital network630, and may store information for a plurality of customers/employees/accounts/etc. associated with each facility. Of course, a local digital network684may also operatively connect each of the workstations628to the facility server626. Unless otherwise indicated, any discussion of the workstations628also refers to the facility servers626, and vice versa. Moreover, environments other than the pharmacies612may employ the workstations628and the servers626. As used herein, the term “pharmacy” refers to any of these environments (e.g., call centers, kiosks, Internet interface terminals, etc.) in addition to the retail pharmacies612, etc. described above.

The front-end components602communicate with the back-end components604via the digital network630. One or more of the front-end components602may be excluded from communication with the back-end components604by configuration or by limiting access due to security concerns. In some embodiments, the pharmacies612may communicate with the back-end components via the digital network630. In other embodiments, the pharmacies612may communicate with the back-end components604via the same digital network630.

Additionally, electronic prescriptions692may be transmitted in the form of electronic data files from an EMR data storage entity690to the automated pharmacy processing system600via the digital network630. Alternatively, electronic prescriptions692may be transmitted from an EHR data storage entity (not shown) or a standalone e-Prescribing data storage entity (not shown). An electronic prescription692corresponding to a particular patient may be an electronic data file and may be used in lieu of or in addition to standard paper prescriptions. Information or data stored in an electronic prescription692may include, for example, the patient name, the patient address, the patient birth date, the prescriber name, the prescriber license number, the medication name, the quantity, a days' supply, specific instructions from the prescriber, etc. Privacy of patients' EMRs may be privacy protected according to local and/or federal government laws and regulations. The EMR data storage entity690may include one or more data storage devices of any known non-transitory, tangible, computer-readable storage media technology, e.g., disks, solid state devices, data banks, servers, cloud storage, etc. The central processing system640or the facility servers626may receive the electronic prescriptions692via the digital network630.

The digital network630may be a proprietary network, a secure public Internet, a virtual private network or some other type of network, such as dedicated access lines, plain ordinary telephone lines, satellite links, combinations of these, etc. Where the digital network630comprises the Internet, data communication may take place over the digital network630via an Internet communication protocol. The back-end components604include the central processing system640within a central processing facility, such as, for example, the central processing facility described in U.S. Pat. No. 8,175,891 entitled “DISTRIBUTED PHARMACY PRESCRIPTION PROCESSING SYSTEM” the entire disclosure of which is incorporated by reference herein. Of course, the pharmacies612may be communicatively connected to different back-end components604having one or more functions or capabilities that are similar to the central processing system640. The central processing system640may include one or more computer processors662adapted and configured to execute various software applications and components of the new prescription order system600, in addition to other software applications.

The central processing system640further includes a database646. The database646is adapted to store data related to the operation of the automated pharmacy processing system600(e.g., patient profile data, physician profile data as well as medication data, etc.). In some embodiments, the database646may include the pharmacy patient database200, the pharmacy prescriber database300and the pharmacy medication database400, as shown inFIGS. 2-4. The central processing system640may access data stored in the database646when executing various functions and tasks associated with the operation of the new prescription order system600. For simplicity,FIG. 6illustrates the database646as only one instance of a database. However, the database646according to some implementations includes a group of one or more databases, each storing different information. For example, one database may store patient profile data while another may store physician profile data. For the purposes of this discussion, the term “database”646may refer to an individual database or to a group of two or more databases.

AlthoughFIG. 6depicts the automated pharmacy processing system600as including the central processing system640in communication with three pharmacies612, it should be understood that different numbers of processing systems and pharmacies may be utilized. For example, the digital network630(or other digital networks, not shown) may interconnect the central processing system640to a plurality of included central processing systems640and hundreds of pharmacies612. According to the disclosed example, this configuration may provide several advantages, such as, for example, enabling near real-time uploads and downloads of information as well as periodic uploads and downloads of information. This provides for a primary backup of all the information generated in the automated pharmacy process. Alternatively, some of the pharmacies612may store data locally on the facility server626and/or the workstations628.

FIG. 6also depicts one possible embodiment of the central processing system640. The central processing system640may have a controller655operatively connected to the database646via a link656connected to an input/output (I/O) circuit666. It should be noted that, while not shown, additional databases may be linked to the controller655in a known manner.

The controller655includes a program memory660, the processor662(may be called a microcontroller or a microprocessor), a random-access memory (RAM)664, and the input/output (I/O) circuit666, all of which are interconnected via an address/data bus665. It should be appreciated that although only one microprocessor662is shown, the controller655may include multiple microprocessors662. Similarly, the memory of the controller655may include multiple RAMs664and multiple program memories660. Although the I/O circuit666is shown as a single block, it should be appreciated that the I/O circuit666may include a number of different types of I/O circuits. The RAM(s)664and the program memories660may be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example. A link635may operatively connect the controller655to the digital network630through the I/O circuit666.

The program memory660may also contain machine-readable instructions (i.e., software)671, for execution by the processor662. The software671may perform the various tasks associated with operation of the pharmacy or pharmacies, and may be a single module671or a plurality of modules671A,671B. While the software671is depicted inFIG. 6as including two modules,671A and671B, the software671may include any number of modules accomplishing tasks related to pharmacy operation including, for example, receiving prescription orders, managing prescription workflow, etc. In some embodiments, the software671may include instructions for implementing the exemplary method500as shown inFIGS. 5A-C. The central processing system640implements a server application613for providing data to a user interface application611operating on the workstations628.

As described above, the database646, illustrated inFIG. 6, includes various information about the pharmacy's customers, prescribing physicians, and prescription medications. Customer records are among the exemplary data that the automated pharmacy processing system600may store on the database646. A customer record contains important information about the customer and the various pharmacy services that have been invoked by, or on behalf of, the customer in a customer profile. The customer profile includes basic biographical information about the customer, such as a customer name, a customer social security number, a customer address, a customer phone number, a customer birth date, customer prescription history, customer allergies, customer insurance information etc. Prescribing physician records may also be stored on the database646. Prescribing physician records may include a prescriber name, a practice name, a prescriber DEA number, a prescriber phone number, a prescriber office address, etc. The database646may also store a list of predetermined prescriber instruction components. Moreover, prescription medication records may include a medication name, a size of the medication, a generic equivalent, whether the medication is a controlled substance, a Dispense as Written (DAW) code, a National Drug Code (NDC), etc.