Pharmacy workflow management system including plural counters

A pharmacy workflow management system including plural counters and a pharmacy workflow management method. In embodiments, the system includes a housing, a first automatic object counter and a cassette dispenser which feeds objects from a cassette mounted thereto to the first object counter. A second object counter counts objects fed from a cassette mounted to the cassette dispenser. A data processing platform within the housing is programmed with instructions that enable the system to compare the counts from the first and second object counters. The data processing platform also provides for management of pharmacy workflow by providing improved control of prescription fulfillment.

FIELD

The field relates generally to pharmacy workflow management and, more particularly, to prescription management including counting of tablet-form medication.

BACKGROUND

In retail, hospital, long-term-care and mail order medication dispensing, a large number of different prescription orders made up of one or more prescriptions for single-dose medications, such as tablets, must be fulfilled. “Fulfillment” as used herein refers to the process of handling and executing customer orders. For pharmacies, the customer is most typically a patient, that is someone for whom the medication is intended. However, pharmacy customers are not limited to patients and may include persons who seek fulfillment of orders for non-prescription tablets such as nutriceuticals, vitamins and supplements. The term “tablets” as used herein should be understood as being generic to pills, tablets, capsules, caplets, gel-filled capsules (gel-caps), liquid-filled capsules, particle-filled capsules and any other solid-dose medication type including prescription and non-prescription medications and products. Tablets, as used herein, are a type of discrete object capable of being counted automatically.

For prescriptions requiring small quantities of a medication, the prescription is often filled by hand; that is, a bulk storage container containing the prescription medication is removed from a shelf and opened. A quantity of the medication is poured into a tray and the medication tablets are counted by a pharmacist and then dispensed into a patient prescription container, such as a bottle or vial. The remainder of the medication in the tray is returned to the bulk container, the bulk container is closed and then replaced on a pharmacy storage shelf.

Larger quantity prescriptions are often filled with the aid of a counting apparatus intended to more rapidly count different quantities of different tablets. For example, a prescription for ninety (90) tablets of 10 mg Claritin® may need to be filled after a prescription for sixty (60) tablets of 400 mg Motrin®. Counting apparatus can be used to expedite the process of filling prescriptions calling for larger quantities of tablets that would be time-consuming and laborious to count manually.

One type of counting apparatus effective for rapid counting of different quantities of different tablets is known as a pour-through counter. With a pour-through tablet counter, the pharmacist pours tablets from a bulk container directly into a funnel. The tablets are counted when they drop past a tablet-counting sensor. The tablets fall past the tablet-counting sensor and into a removable tray, or are directed into a container for the patient prescription order. The pharmacist pours the tablets until a digital readout of the counter apparatus displays the required number of tablets, and then stops. As such, there is usually no excess. However, should an extra tablet or so fall into the funnel, the readout clearly indicates the extra number, and the excess can easily be removed by the pharmacist and returned to the bulk storage container.

Pour-through tablet counters are quite effective at providing an accurate count of the tablets required by a prescription. However, a drawback of such tablet counters is that the counters do not manage a broader range of pharmacy workflow tasks.

As an alternative to manual pouring of tablets into the tablet counter, an automatic-type tablet feeder may be provided to feed tablets to the counter. Examples of automatic-type feeders are cassette-type or vibratory-bowl-type feeders described in U.S. Pat. Nos. 6,497,339 and 6,659,304 or a mechanical feeder such as the rotating assembly described in U.S. Pat. No. 7,219,703.

A cassette is a container that holds bulk-form tablets and objects. Each cassette is pre-loaded, or filled, by pharmacy personnel with a bulk quantity of a tablet-form medication or other product. Tablets are fed from the cassette.

There are many potential advantages to the use of cassettes by a pharmacy. For example, cassettes are efficient and reduce the time required to fulfill a prescription. Cassettes can hold a large amount of tablets, thereby reducing the need to retrieve and return to storage a container holding the medication and the need to manually pour tablets from the manufacturer's container. Cassette usage permits the pharmacist to perform other value-added tasks while tablets are automatically fed from the cassette. Cassettes for more frequently-used tablets can be stored at a convenient location proximate the tablet counter. Cassettes can be used to dispense tablets at a rapid rate, thereby reducing the time required to fulfill a prescription.

Certain cassette types are calibrated or designed for a specific size and shape tablet. U.S. Pat. No. 7,395,946 describes tablet cassettes which may be calibrated. Calibration involves adjustment of the cassette so that the cassette will dispense tablets in a singulated manner, that is one tablet after the other. Calibration can involve adjustment of the size of the cassette opening through which the tablet exits the cassette, for example, by providing a smaller opening for small-size tablets or a larger opening for large-size tablets. As an alternative to calibration, the cassette may be manufactured with a single-size opening for a particular tablet size or shape.

Problems can arise if the cassette is not calibrated properly or if the cassette is incorrectly sized for the type of tablet to be dispensed from the cassette. More specifically, use of an incorrectly calibrated or sized cassette can result in plural tablets being fed simultaneously from the cassette. The tablets are fed from the cassette and pass a sensor. Detection of the tablets by the sensor is used to make a tablet count.

The process of counting from the cassette is not completely accurate. If tablets fed from the cassette pass the sensor simultaneously, a single count may be registered even though plural tablets are dispensed. Missed tablet counts result in prescription order fulfillment errors and can amount to “giving away” costly tablet-form medication. Many dispensing cycles may be performed before the error is detected by pharmacy personnel. Small tablets or tablet fragments may not be detected by the sensor. Tablet fragments may be detected as a complete tablet, thereby failing to completely fulfill the prescription.

Because pharmacy-personnel time is valuable, obtaining an accurate count in the least amount of time is advantageous. Vibratory-type dispensers which feed tablets from a cassette as described in U.S. Pat. Nos. 6,497,339 and 6,659,304 are potentially excellent for their intended purpose, but tend to require a relatively greater amount of time to automatically dispense the required tablets or other discrete objects. This is because the vibratory action required to singulate the discrete objects from the vibrating cassette tends to be somewhat slow. Moreover, tablet counting for vibratory systems is performed only by the discrete object counter. Additional time is required for the tablets to exit the cassette, fall past the object counter to make a count and for the appropriate feedback to be provided to the vibration system which controls feeding to the objects to the discrete object counter.

The time required to count a specified quantity of tablets from a vibratory dispenser system can be excessive. For example, a pharmacy may be required to perform repetitive counting and packaging operations for unit-of-use containers. Unit-of-use containers are frequently used to hold pre-packaged 30, 60 or 90-day tablet quantities. The pre-packaged unit-of-use containers may be stocked at a pharmacy “speed-shelf” permitting rapid retrieval by pharmacy personnel. As can be appreciated, rapid, accurate counting is desirable to minimize the time required for performance of these repetitive counting operations.

Workflow in a retail, hospital or mail order pharmacy is typically managed by a computer-driven system known generally as a pharmacy management system, or PMS. For each prescription order, information required to fulfill each prescription of the prescription order is input to the PMS, typically by a pharmacy technician. The PMS processes each prescription of the prescription order to determine that the pharmacy can fulfill the prescription order.

For prescriptions requiring manual tablet counting, the PMS generates prescription order paperwork known generally by the term “label.” The paperwork includes all information necessary for fulfillment of the prescription and typically includes an adhesive-backed label for application to each container for each prescription within the prescription order. The paperwork is typically printed by an automatic printer located within the pharmacy. Each prescription of a prescription order is simply filled in the order in which the paperwork is generated by the PMS. The pharmacist or pharmacy technician follows the information on the paperwork and can use the tablet counter to count out the desired quantity of tablets as previously described. The fulfilled prescription order is provided to the patient in one or more containers once all medications required by the prescription order have been verified and payment has been made or arranged.

A drawback of such a system is that the pharmacist operating the tablet counter does not have the ability to manage pharmacy workflow. The pharmacist simply fulfills the prescription orders in the order in which they are provided by the PMS. There may be a large number of prescription orders awaiting fulfillment at any given time. By way of example only, in certain circumstances it may be desirable to fulfill patient prescription orders out of turn. One such circumstance could involve a need to fulfill a prescription order for a patient who is waiting to pick up medications before an earlier processed prescription order for a patient who will not pick up the prescription order until the following day.

By way of further example, a patient might have a question of the pharmacist operating the tablet counter. The pharmacist may be unable to respond to the question because the printed label paperwork might not yet be available from the PMS.

Presently, the pharmacist would be required to access the PMS to perform any modification of the pharmacy workflow or obtain detailed information about the patient's prescription order with which to answer the patient's questions. Utilization of the PMS for these or other purposes may be inconvenient or require more time to complete than if the workflow management process could simply be controlled by means of the tablet counter.

It would be an advance in the art to provide an improved pharmacy workflow management system which would facilitate tablet counting, would enable improved control of pharmacy workflow, and which would contribute to an improvement in the overall quality of patient care. And, it would be an advance in the art to provide an improved tablet counter which could be used with the pharmacy workflow management system or as a stand-alone apparatus and which would enable use of the tablet counter with medication-specific cassettes, also improving the quality of patient care.

SUMMARY

A pharmacy workflow management system including plural automatic object counters and a method for pharmacy workflow management are shown and described. The preferred system provides the user with the capability of fulfilling prescriptions by feeding objects from a cassette or by manual pouring of tablets into the system. The system is preferably used to feed and count tablet-form objects of the types described herein, although other types of countable objects may be counted with the system. The plural counters facilitate improved object feeding and counting.

In a preferred embodiment, the system comprises a first automatic object counter and a cassette dispenser. The first object counter is preferably within a housing. The cassette dispenser includes a cassette mount which positions a cassette mounted thereon to feed discrete objects to the first object counter. The cassette dispenser further includes a drive system which powers a mounted cassette to feed objects from the mounted cassette. The system further comprises a second automatic object counter which counts objects fed from the mounted cassette. A data processing platform compares counts of the first and second object counters.

Preferably, the data processing platform compares the counts to determine whether the counts differ by more than a predetermined amount. Preferably, the data processing platform generates a signal if the counts differ by more than the predetermined amount. The counts could differ, for example, if a jam condition were to exist preventing flow of tablets to the first tablet counter. It is also preferred that the drive system stops responsive to the signal. A visual message may appear on a video display to notify a user that the counts differ. Preferably, the data processing platform compares the counts during counting. The data processing platform may further compare the counts to determine whether the counts match a required count, such as the count required to fulfill a prescription. Such a comparison would be useful to confirm that all tablets required by the prescription were fed from the cassette.

Preferably, the first object counter count is displayed on the video display.

In an embodiment, the first object counter counts objects both fed from a mounted cassette and poured manually. To facilitate system operation, a funnel and a chute connected thereto are preferably provided. The funnel and chute direct objects to the first object counter for counting. The funnel preferably has an inlet sized to receive objects both fed from the mounted cassette and poured manually.

In a further embodiment, the second object counter comprises a cassette dispenser detector which detects an object fed from the mounted cassette and a cassette dispenser controller which increments a count responsive to each detected object. The detector preferably generates a signal responsive to each detection. The detector signal is received by the cassette dispenser controller to increment the count. The count is used by the data processing platform, for example, for purposes of the count comparison.

In an embodiment, the data processing platform is programmed with instructions which, when executed, perform a method of pharmacy workflow management. In an embodiment, the system can receive a plurality of prescriptions and store the received prescriptions. The system enables user-selection of a prescription. A stored prescription is retrieved followed by counting with the first and second automatic tablet counters of a quantity of tablets required by the retrieved prescription. Thereafter, a record may be created that the quantity of the tablet-form medication required by the retrieved prescription has been counted.

Retrieving one of the stored patient prescription orders for fulfillment preferably is triggered by touching the display proximate a displayed prescription or by reading a code on a label for the selected prescription. It is preferred that all prescriptions stored for a patient are displayed on the display collated for the patient. Thus, any number of pending prescriptions for the patient are preferably grouped together making it easier for a user of the system to fulfill all pending prescriptions for the patient. If cassette dispensing is selected by the user, the counts can then be compared by the first and second automatic tablet counters for the displayed prescription.

In embodiments, the method performed by the instructions, when executed, further comprises verifying that a cassette contains the required medication or that a container for the medication matches the medication required by the retrieved prescription. For cassettes, the verifying executed by the instructions preferably includes verifying that the cassette contains the required medication. One medication is associated with each cassette and each cassette is associated with a unique cassette identification code by means of a database stored in the non-volatile memory of the data processing platform. An identification code of the mounted cassette is read by a reader of the cassette dispenser. A match between the expected and actual cassette identification codes confirms that the correct cassette has been selected by the user. Once verified, the instructions initiate operation of the drive system which powers a mounted cassette to feed objects therefrom for counting by the first and second object counters. In the embodiment, the data processing platform compares the counts.

For containers, the verifying executed by the instructions preferably includes associating an expected container identification code with the prescription. This may be accomplished by means of a database stored in the non-volatile memory of the data processing platform. The expected identification code may be a UPC barcode on the container which may be associated with the prescription number for the patient prescription through the database. In other embodiments, the expected container identification code may be associated or with the National Drug Code (NDC) included on paperwork for the patient prescription in the database. The identification code on the container, typically a barcode, is read by a code reader such as a barcode scanner. The system then compares the expected and actual identification codes for a match. If there is a match, then the medication from the container can be poured into the system and counted to fulfill the prescription. Each prescription for the patient may be selected, retrieved and fulfilled one after the other until all collated prescriptions for the patient have been fulfilled.

The system may be configured to perform a further verification process which occurs after counting but before the prescription is given to the patient. Such verification performed by the executed instructions comprises retrieving a prescription for verification, comparing the prescription with the counted tablets and confirming that the prescription and counted tablets match.

The system may be interfaced with a pharmacy management system or may operate as a stand-alone product. The system may be enabled to perform different modes of counting depending on the level of verification desired by the user.

DETAILED DESCRIPTION

Workflow Management System11

Referring first toFIGS. 1-6, an exemplary pharmacy workflow management system11including an integrated automatic tablet counter in accordance with the present invention includes a housing13that houses an automatic tablet counter15and a data processing platform17. System11is described in U.S. patent application Ser. No. 12/182,669 filed Jul. 30, 2008, the contents of which are fully incorporated herein by reference. Data processing platform17(e.g., one or more printed circuit boards that include a microprocessor, memory and interface circuitry mounted thereon) interfaces to tablet counter15and possibly to a tablet feeder19to control the operations of system11during the pharmacy workflow management operations carried out by system11. These operations include control of pharmacy workflow involving fulfillment of prescriptions which require tablet counting and, in embodiments, may also include control of pharmacy workflow involving fulfillment of prescriptions for other medication types such as unit-of-use medications, pre-packaged medications and things (e.g., ointments, syringes, inhalers, etc.).

Data processing platform17may interface with a Pharmacy Management System (PMS)21through a communication link represented by line23inFIG. 6providing a means for bi-directional data transmission between PMS21and system11. An interface between system11and PMS21may be provided by means other than link23, such as by batch delivery of prescription orders from PMS21to system11via a portable non-volatile memory device (not shown). Prescription order data downloaded onto the memory device could then be transferred to system11by pharmacy personnel.

System11can also function as a stand-alone system which is not interfaced with PMS21. Workflow management performed by system11is described herein for embodiments of system11which are interfaced with PMS21and for embodiments of system11which are not interfaced with PMS21.

PMS21is representative of any system which manages prescription orders. As already noted, a prescription order is an order for one or more prescriptions. Pharmacy Management Systems of various types are routinely utilized by pharmacies serving retail, hospital, long-term care, mail order and other markets to manage workflow. Prescriptions to be fulfilled are output from PMS21to system11and records of fulfilled prescriptions are output from system11to PMS21providing pharmacy workflow management.

PMS21may be a computer or combination of computers running any suitable workflow management program or programs. PMS21may be accessed from one or more pharmacy workstations. PMS21may be located at a single site or at a plurality of sites. Communication link23may be any suitable connection enabling one-way or two-way data transmission between system11and PMS21and may include a cable connection, a wireless connection, or an Internet connection. Communication link23, if provided, enables real-time data transmission between system11and PMS21. Batch delivery of data as previously described, or any other suitable means of data transmission, may be used in conjunction with, or substituted for, link23.

The operations of PMS21will typically be customized for the workflow requirements of a particular pharmacy. As already noted, a prescription order comprising one or more prescriptions is entered into PMS21by a pharmacy technician or pharmacist at an input workstation. The prescription order may be delivered to the pharmacy in any suitable manner, including by physically providing a paper prescription order to the technician or by electronic data transmission.

The pharmacy technician or pharmacist enters all information relevant to fulfillment of the prescription order into PMS21using an input device such as a keyboard, mouse and/or touch-screen video display. Information entered into PMS21will typically include patient name, medication type and quantity, National Drug Code (NDC) for the prescribed medication, physician name, refill information, medication interaction information and insurance information or other information related to payment.

After data entry, the prescription order is processed by PMS21. Processing by PMS21includes any steps deemed necessary by the pharmacy to make a determination that a prescription of the order should be fulfilled. Processing can include determination of whether the prescribed medication is available in the pharmacy, determination of whether a generic medication can be substituted for a branded medication, determination of whether the prescribed medication presents any risk of adverse medication interactions with medications currently taken by the patient and a drug utilization review (DUR) which includes confirmation that a third-party payor will pay for some or all of the prescription being fulfilled.

A prescription is deemed validated once it has been determined by means of PMS21that the prescription should be fulfilled. A prescription order is deemed validated when all prescriptions of the order have been validated. Validated prescription orders are transmitted electronically from PMS21via link23, or by batch, to data processing platform17of system11for managed prescription order fulfillment as described in detail below. Following prescription order fulfillment by a pharmacy technician and/or registered pharmacist utilizing system11, a record of each completed prescription order may be sent by system11back to PMS21providing confirmation of prescription order fulfillment.

For non-interfaced embodiments of system11, PMS21provides instructions and information for fulfillment of separate prescriptions. This information may be in the form of prescription order paperwork147which includes all information required to fulfill a validated prescription as described herein.

Referring further toFIGS. 1-6, housing13includes top25and bottom walls27, sidewalls29,31and front33and rear walls35. A display37is mounted to housing13front wall33and interfaces with data processing platform17. Display37outputs information to a user of system11, such as a pharmacy technician or pharmacist. Display37preferably provides status messages to the user, including information relevant to the management of pharmacy workflow, the number of tablets counted by tablet counter15, and prescription status. Examples of screen displays are discussed in connection withFIGS. 15-36. In the examples, display37is a flat panel liquid crystal display (LCD). It is preferred that display37is a touch-screen-type display thereby enabling display37to also serve as an input device for transmission of information from the user to data processing platform17. Data is transmitted from display37to data processing platform17when a user touches display37proximate information or an image shown on display37. A touch-screen-type display may display an image of a QWERTY-type or ABC-type keypad (e.g., QWERTY keypad65,FIG. 70) which enables a user to input information to data processing platform17by touching keys of the keypad. Such a keypad would be useful for inputting information to data processing platform17, for instance user login information, prescription number information or NDC information. Other types of displays, such as a cathode ray tube (CRT) or digital numeric display, may be used. Tablet feeder19is removably seated in a mount39on housing top wall25.

Feeder19is provided to direct tablets toward tablet counter15. In the example, tablet feeder19is of a pour-through type with an upper funnel41and a vertically-oriented chute43. Tablet-form medications are poured by a user from a bulk storage container175(FIG. 12A) into funnel41and fall by means of gravity through chute43, past tablet counter15into a tray45removably positioned in tray bay47provided in housing front wall33. Tray45may be removed from housing13bay47by grasping and pulling tray handle49, thereby permitting medication in tray45to be conveniently poured into a container (not shown) such as a vial or bottle which is subsequently provided to the patient.

While a pour-through type feeder19is shown, feeder19may be of other suitable types capable of delivering tablet-form medication to tablet counter15. For example, tablet feeder19may be an automatic-type feeder such as the vibratory bowl feeder described in U.S. Pat. No. 6,497,339, a mechanical feeder such as the rotating assembly described in U.S. Pat. No. 7,219,703, or a cassette system such as described in U.S. Pat. No. 6,659,304, all of which are commonly assigned to the assignee of the present invention and hereby incorporated by reference in their entireties. Automatic-type tablet feeders19preferably feed tablets in a singulated manner to tablet counter15.

By way of further example, feeder19may include cassette dispenser601and plural counters as described below in connection with system11′.

In place of tray45, system11may include a storage compartment or possibly a cell-based architecture (such as the cell-based architecture as described in U.S. Pat. No. 7,124,791 and U.S. Pat. No. 7,395,841 both commonly assigned to the assignee of the present invention and herein incorporated by reference in their entireties) that accumulates the tablets counted by tablet counter15prior to discharge from system11.

Automatic tablet counter15within housing13is preferably an optical system which uses an optical sensor array to count tablets on a piece-count basis, such as that disclosed in U.S. Pat. No. 5,768,327, which is commonly assigned to the assignee of the present invention and is hereby incorporated by reference in its entirety.

Components of exemplary tablet counter15of system11are illustrated inFIG. 5which is a section view taken along section5-5ofFIG. 3. Tablet counter15primarily consists of optical sensors, infrared (IR) sources, and the accompanying electronics and software to perform the counting function as required for tablet counter15. These elements include IR emitters301a,301b, mirrors303a,303b, collimating lenses305a,305b, and IR sensor linear arrays307a,307b. Dotted paths309a,309bindicate the nominal optical path for the IR energy emitted from IR emitters301a,301b. Each of the optical elements are in pairs with linear sensor arrays307a,307bmounted perpendicular one to the other and the IR emitters301a,301b, mirrors303a,303b, and lenses305a,305barranged such that IR radiation is collimated into two sets of parallel beams, each set striking one of the sensor arrays307a,307bsuch that an optical grid of orthogonal beams is formed within the region bounded generally by lenses305a,305band sensor arrays307a,307b.

In this embodiment of tablet counter15, each sensor array307a,307bhas forty-eight sensor elements (spaced about 0.05 inches on center) within linear arrays307a,307b, such that the grid can be thought of as a 48×48 optical grid. Each IR emitter301a,301band its corresponding mirror303a,303band collimating lenses305a,305bform collimated IR sources308a,308beach of which illuminates its corresponding sensor array307a,307bwith a collimated beam emanating from each lens305a,305b.

FIG. 4is a section view showing components of a preferred tablet feeder19. In order to aid in the vertical separation of free-falling tablets to be counted, the vertical distance from the top of feeder19, through funnel41and chute43to the sensor arrays307a,307bis chosen to be at least six inches, and preferably approximately eight inches. Likewise, in order to aid in the horizontal separation of tablets falling through chute43, the smallest inside horizontal dimension of chute43is chosen to be at least 2.5 times the largest dimension of the tablets being counted. Thus, in system11as shown, the horizontal dimensions of chute43are approximately 2.5 inches by 2.5 inches, because the largest tablet expected to be counted is approximately 0.9 inches in its largest dimension.

Collimated IR sources308a,308bare also shown schematically inFIG. 7, as are sensor arrays307a,307b. Tablet counter15also includes circuitry310which is embedded within the circuitry of data processing platform17(FIG. 6). Other elements which cooperate to accomplish the functions of tablet counter15include display37, microprocessor-based controllers311and313, an overspeed warning indicator alarm315(which generates a message on display37), and a resetting device317, all of which are discussed in more detail hereinafter. At least some of circuitry310may be incorporated on a printed circuit (PC) board on which one of sensor arrays307aor307bis mounted.

System11includes a deflector319which is provided below sensor arrays307a,307bfor deflecting tablets into the removable tray45. Tray45preferably includes a curved inner-surface portion45awhich cooperates with and continues from deflector319. Deflector319and curved surface portion45aof tray45together present a surface which prevents tablets falling into tray45from bouncing up into feed device19and being recounted. It will be appreciated that deflector319is housed in system11housing13.

When system11is assembled as shown inFIGS. 1-6, tablets which are placed in funnel41fall into tablet feeder19and cast shadows on sensor arrays307a,307bof tablet counter15as they fall past arrays307a,307b. As is discussed below, the shadows are used in determining a count. After passing sensor arrays307a,307b, the tablets hit the deflector319which directionally deflects the tablets so that they do not bounce back up into chute43.

Referring toFIG. 5, sensor arrays307a,307bare arranged at approximately 45 degrees relative to sidewalls29,31of housing13. According to this preferred embodiment, mirrors303a,303bare each arranged so that the path of light309a,309bfrom each IR emitter301a,301bto a respective lens305a,305bis deflected approximately 90 degrees. This arrangement permits housing13to be more compact because the focal length of lenses305a,305bis traversed in two orthogonal segments, and IR emitters301a,301btherefore need not be placed so far away from lenses305a,305b.

Turning now toFIG. 7, the outputs of sensor arrays307a,307bare coupled to a microprocessor-based controller311which is also coupled to collimated IR sources308a,308b. Controller311is preferably bidirectionally coupled to microprocessor-based master controller313which provides output to display37and operates speaker63(FIG. 6) to generate audible alarm315. An overspeed indication may also be visually presented on display37. Master controller313is also preferably provided with resetting device317such as a “reset” button or switch. Resetting device317, for example, may be a switch activated by the position of tray45being fully inserted into tray bay47such that when tray45is re-inserted into tray bay47, a “reset” signal is generated. Such a switch is not shown inFIGS. 1-5. Resetting device317may also be any suitable manual input device.

In the example, controller311strobes IR emitters301a,301bat a relatively high rate and preferably alternatingly so that only one IR emitter301aor301bis activated at any instant. According to a preferred embodiment, the IR emitters301a,301bare strobed at approximately 1200-1600 Hz with a duty cycle of approximately 5%. As tablets pass between each sensor array307a,307band its respective collimated IR source308a,308b, shadows will be cast on one or more of the forty-eight sensors in each array307a,307b. The output of each array307a,307bis processed as a forty-eight bit binary number wherein sensors of arrays307a,307bwhich receive light are indicated with a binary zero and sensors of arrays307a,307bwhich are blocked from receiving light are indicated with a binary 1. Thus, when no tablet is blocking the path of light to the sensor arrays307a,307b, the outputs of the sensor arrays307a,307bwill be: 000000000000000000000000000000000000000000000000. If a single tablet passes between a collimated IR light source308aor308band sensor array307aor307b, the output of array307aor307b, for example, might be: 000000000000111111110000000000000000000000000000.

If two tablets pass side-by-side between a collimated IR light source308aor308band sensor array307aor307b, the output of array307aor307b, for example, might be: 000000000000111111110000000000000111111110000000.

Controller311is preferably programmed to perform various functional steps which are seen in the flow diagram ofFIG. 8wherein the operation of controller311is described. Upon receiving an interrupt at360, controller311activates the first collimated IR light source308a, at362. Controller311reads the output of the corresponding first sensor array307aat364and places the output in a buffer “circ_image1.” The first collimated IR light source308ais de-activated at366, and the second collimated IR light source308bis activated at368. Controller311reads the output of the second sensor array307bat370and places this output in a buffer “circ_image2.” The second collimated IR light source308bis deactivated at372.

Controller311then updates the addresses of the buffers at374, and the subroutine ends at376until the next interrupt is received at360. Those skilled in the art will appreciate that the contents of each buffer will be “n” forty-eight bit binary numbers which, when arranged as a 48×n matrix, reveal a two-dimensional projection of an image of the tablets scanned. For example, such an image (n=12) may appear as shown below:

which would represent two tablets passing in between a collimated IR light source308aor308band its corresponding sensor array307aor307b. Other possible representations of the image are shown and described in the co-owned U.S. Pat. No. 5,317,645. Each image (or frame) may be analyzed according to the methods disclosed in U.S. Pat. No. 5,317,645. As described below with reference toFIGS. 10A and 10B, each image is also preferably analyzed to determine whether the image represents a fragment of a tablet.

Co-owned U.S. Pat. No. 5,317,645 is hereby incorporated by reference in its entirety. This patent discloses a method and apparatus for counting discrete objects and addresses the issue of counting two or more clustered or bunched objects which a simple optical sensor would count as one object.

Turning now toFIGS. 9,10A and10B, the contents of the buffers circ_image1 and circ_image2 are read line-by-line to determine the start and the end of an image. An image includes at least one dark pixel (non-zero bit in an array) and typically includes many dark pixels which represent one or several tablets. The image represented in each buffer is then separately and conservatively analyzed to determine a count, and the higher count is accepted as the accurate count. For example,FIG. 9shows a schematic rendering of the contents of the buffer circ_image1 as a 48×20 grid wherein empty boxes in the grid represent digital “zeros” and boxes marked with an “X” represent digital “ones.” The image shown inFIG. 9represents possibly four tablets321,323,325and327. As will be explained below, tablet325is a tablet fragment and will not be counted as a tablet. Tablets321and327represent end views and tablet323represents a side view.

The image buffers circ_image1 and circ_image2 are analyzed according to the methods illustrated inFIGS. 10A,10B and10C. As shown inFIGS. 10A,10B and10C, starting at400, controller311repeatedly reads the buffers at402to determine if any new data is available in the buffers circ_image1 and circ_image2. When data becomes available, the first line of data is read from each buffer at404. The lines of data are analyzed at406to determine whether both lines are clear, i.e. all zeros. For example, line “A” inFIG. 9would be represented in the buffer as all zeros. If the lines from both buffers are clear, it is determined at408whether these lines represent the end of an image or the fact that no image has been encountered yet. For example, line “A” inFIG. 9represents the fact that no image has been encountered yet, and line “I” inFIG. 9represents the end of an image. If the line read represents no image encountered yet, controller311returns to402and prepares to read the next line from each buffer circ_image1 and circ_image2 at404. If at least one line read is not clear, as determined at406, both lines are appended to “image1” and “image2” (additional buffers, not shown) at410. Controller311continues to repeat this process until it again finds that both lines from the buffers circ_image1 and circ_image2 are clear at406. For example, lines “B” through “H” inFIG. 9would be appended to the buffer “image1.” Line “I” inFIG. 9indicates the end of the images which is determined at408inFIG. 10A. Prior to analyzing image1 and image2, controller311sets count1 and count2 to zero at412. Both image1 and image2 are “raster scanned.” That is, each bit of each line of the buffers image1 and image2 is read. As described above, the contents of the buffer image1 at this point in the analysis is represented inFIG. 9as lines “B” through “H.”

Generally, the scanning of image1 is commenced at414. Scanning continues until terminated at416. At419, it is determined whether the bit (pixel) at the scan position is a digital one or a digital zero. For example, referring again toFIG. 9, raster scanning would begin at the position B00 and move across to position B47, continue from C00, etc. After scanning each position, if the position does not contain a digital one, the raster scan position is advanced at427, and this is repeated until the scan is terminated at416or the raster scan position is determined at418to be a 1. The first time the raster scan detects a digital one, e.g., at B37 inFIG. 9, a subroutine “MOVE CONNECTED COMPONENT TO WORK_IMAGE” is performed at421(and described in detail below with reference toFIG. 10C). The main task of this routine is to copy the entire cluster of digital “ones” connected to the detected “one” into a new array named “work_image.” A further task of this routine is to count the number of “ones” in the given cluster. Each cluster is referred to as a “connected component.”

At423inFIG. 10A, it is determined whether the connected component represents one or more tablets or whether it is simply noise. If the area of the connected component is 1, it is considered to represent noise and the raster scan is advanced to the next pixel at427. If the area is greater than 1, the connected component is preferably conservatively analyzed at425to determine how many tablets it represents and to update the count1 for image1 accordingly. The analysis at425is preferably performed according to co-owned U.S. Pat. No. 5,317,645 and also includes a comparison of the area of the connected component with a known average area to determine if the connected component represents a fragment. The raster scan is again advanced at427and the process continues until all the lines of image1 have been scanned. This is determined at416whereupon the scanning of image2 commences at428.

The raster scanning of image2 (FIG. 10B) proceeds in substantially the same manner as the raster scanning of image1 until terminated at430. At432, it is determined whether the pixel scanned is a one or a zero. If it is a zero, the raster scan is advanced at440, and this is repeated until scan is terminated at430or the pixel scanned is determined at432to be a one. The first time a non-zero pixel is encountered in the raster scan, the subroutine “MOVE CONNECTED COMPONENT TO WORK_IMAGE” is called at434. The subroutine, mentioned above and described in detail below, determines whether the pixel is an orphan having an area of only one or part of a cluster having an area greater than one. If the area is not greater than one as determined at436, the raster scan is advanced to the next pixel at440. If the area of the work_image is greater than one as determined at436, the area is preferably conservatively analyzed at438and count2 is updated for image2 accordingly. The raster scan is again advanced at440, and the process continues until all the lines of image2 have been scanned. This is determined at430whereupon count1 and count2 are compared at442. If count1>count2, the total_count is incremented by count1 at444. If count2>count1, the total_count is incremented by count2 at446. At448, the controller returns to the start400(FIG. 10A) to analyze another two images. It will be recognized that each image is counted individually in order to provide a total count. Preferably, though not shown inFIGS. 10A-10C, controller311will maintain counts for the number of images which were analyzed as containing one tablet, the number of images which were analyzed as containing two tablets, the number of images which were analyzed as containing three tablets, etc.

FIG. 10Cillustrates the operation of the subroutine “MOVE CONNECTED COMPONENT TO WORK_IMAGE” referred to above with reference toFIG. 10Aat421. It will be understood that the subroutine “MOVE CONNECTED COMPONENT TO WORK_IMAGE” referred to above with reference toFIG. 10Bat434, operates in the same manner but with reference to image2 rather than image1. In general, when a non-zero pixel is encountered in the scan of image1, the subroutine will look at four surrounding pixels to determine whether any of them are also non-zero pixels. The surrounding pixels are referred to as child pixels, and the surrounded pixel is referred to as a parent pixel. In addition, each non-zero child pixel will be treated as a parent, and its children will be examined. So long as new children are found, the process will continue until the area of an entire “connected component” is counted. In order to keep track of which pixels have been examined and which have not, the routine uses a stack which records the x-y coordinates of parent pixels which need to be examined. The stack is a FIFO (first in, first out) stack from which data is popped in the same order in which it has been pushed. As mentioned above, the connected component is thus incrementally copied into the two-dimensional array called “work_image.”

Turning now toFIGS. 10C-1and10C-2, the routines421,434begin with initializing variables at700. Pixels_available counts the number of parent pixels that are queued in the stack to be examined, and it is initialized to zero. Pixel_index_in is the index by which new pixel x-y data is pushed into the stack, and it is initialized to zero, the first location in the stack. Pixel_index_out is the index by which pixel x-y data is popped from the stack, and it is initialized to zero. The variable “area” is the total number of pixels in the connected component, and it is initialized to zero. At702, the pixel encountered at419,432(FIGS. 10A,10B) is pushed into the stack, the variable pixel_index_in is updated, and the variable pixels_available is incremented by one. If it is determined at704that pixels_available=0, the process is complete and returns at706to423,436(FIGS. 10A,10B). Otherwise, the process continues at708to pop the next pixel from the queue, the variable pixel_index_out is updated, and the variable pixels_available is decremented by one. The popped pixel is examined at710. If the popped pixel is zero, it means that the pixel was cleared in a previous iteration of the routine at712and cannot become a parent to new children. In this case, the routine returns to704to pop another pixel if there is one available. If the popped pixel is determined at710to be a one, it is copied at712to work_image and deleted from image1, i.e., the location variable image1 (x,y) is set to zero and the location variable work_image (x,y) is set to one. The area of the work_image is incremented by one at714, and the x-coordinate of the parent pixel is decremented at716so that the child pixel to its right can be examined at718. If the child pixel has the value 1, it is pushed into the stack at720and variables are updated as described above with reference to702. In this way, the child pixel will be examined later as a parent pixel when the routine eventually returns to408. If the child pixel has the value 0 as determined at718, the routine continues to step722without pushing the pixel into the stack. At722, the x-coordinate is incremented and the y-coordinate is decremented so that the next child pixel examined is located directly above the parent pixel. Steps724and726are substantially the same as steps718and720. Both the x and y coordinates are incremented at728so that the next child pixel examined is located to the left of the parent pixel. Steps730and732are substantially the same as steps718and720. At734, the x-coordinate is decremented and the y-coordinate is incremented so that the next child pixel examined is located directly below the parent pixel. Steps736and738are substantially the same as steps718and720. Now that the four children of the parent pixel have been examined and all of the non-zero children have been pushed into the stack, the routine returns to704to examine each of the non-zero child pixels as parents.

FIGS. 11A and 11Bshow flow charts for the programming of master controller313. Referring now toFIGS. 11A and 11B, the main routine is initialized when a user activates resetting device317at501. The total count is set to zero at502. (Thus, resetting device317is referred to as a ZERO button inFIG. 11A.) If resetting device317is activated again during iterations of the routine, it is detected at503and returns at504to501. Barring a halt by activation of resetting device317, the routine obtains count information at505from controller311. According to a preferred method, controller311provides master controller313with up to five different counts, each count relating to a number of images of a number of tablets. For example, as shown inFIG. 11A, the counts received from controller311are designated new_singles, new_doubles, new_triples, new_quadruples and new_quintuples. The new_singles count refers to the number of images determined by controller311to represent single tablets. The new_doubles count refers to the number of images determined by controller311to represent two tablets, etc. The total number of tablets is computed at506by multiplying each of the counts by the appropriate number, summing the products and adding to a previous total. After computing the total count, the routine determines at507whether an overspeed condition is present by comparing a periodically updated “inaccuracy_measure” to a constant “overspeed_threshold.” If an overspeed condition is determined at507, overspeed indicator315(alarm) is triggered at508, and the routine returns at509to501. If it is determined at507that no overspeed condition exists, it is determined at510whether a preset warning_threshold has been exceeded. If the warning_threshold has been exceeded, a warning flag is set at511to “1.” If not, the warning flag is set at512to “0.” Display37Count field95,1095(e.g.,FIGS. 24,25) is then updated at513, and the routine returns to503to obtain more new counts or be halted by resetting device317.

The routine shown inFIG. 11Ais interrupted at intervals of 10 ms to obtain an updated inaccuracy_measure which is used to determine an overspeed condition and set a warning flag as described above. The inaccuracy_measure is an indication of how quickly tablets are falling past sensor arrays307a,307b. If tablets are poured into system11and pass tablet counter15at too high a rate, an accurate count cannot be assured. In this preferred embodiment, the inaccuracy_measure is a weighted sum of the clustered tablets counted during the last 0.6 seconds. According to the preferred embodiment, the inaccuracy_measure is the sum of new_singles—06+4*new_doubles—06+9*(new_triples—06+new_quadruples—06+new_quintuples—06), where new_singles—06 is the number of new_singles received in the past 0.6 seconds, new_doubles—06 is the number of new_doubles received in the past 0.6 seconds, etc. The inaccuracy_measure is therefore a function of the actual rate at which tablets are poured as well as a function of the tendency of the tablets to cluster.

FIG. 11Bshows a flow chart of the routine for updating the variable inaccuracy_measure. On a 100 Hz interrupt at514, inaccuracy_measure is updated at515. At516, the previously set warning flag is checked and if the flag is set to “1”, a warning message is triggered at517resulting in display of an overspeed message on display37. The overspeed message may, for example, be a pop-up message on display37or a message such as “Pour is Too Fast! Count Failed.” may be displayed in Main Instructions field91,1091(e.g., shown on screen displays ofFIGS. 24,25). The overspeed message presented on display37prompts the user to re-pour the medication into feeder19in order to ensure an accurate count. The routine ends at518. It will be appreciated that, although not required, the overspeed_threshold and the warning threshold values can be set according to the accuracy requirements of the user.

Referring once again toFIGS. 1-7, there are shown other external and internal components of system11. A barcode scanner51is secured to housing13sidewall31by support53. Barcode scanner51is a type of input device which enables a user to input information embedded in a barcode to data processing platform17. While barcode scanner51is shown in the example, other types of code readers, such as a radio frequency identification tag (RFID) reader (not shown) may be utilized separately or in combination with barcode scanner51. An RFID reader would be useful, for example, to read an RFID tag associated with a medication container (e.g., containers174,175inFIGS. 12A,12B).

A biometric sensor55is mounted to housing13front wall33. Biometric sensor55may be realized by a fingerprint sensor as illustrated, a voice print analyzer, or other suitable means. In the example, data processing platform17interfaces with both barcode scanner51and biometric sensor55.

Power cord57supplies electrical power to power supply58of system11. A rocker-type ON/OFF switch59is provided along housing13sidewall31to control the electrical power delivered to power supply58.

Referring now toFIG. 6, data processing platform17interfaces to a number of components that are housed within system housing13, including non-volatile data storage61(which may be realized by a hard drive, flash memory or other suitable non-volatile memory means), an audio speaker63and display37. Data processing platform17(which is preferably realized by a printed circuit board having a microprocessor, memory and supporting interface circuitry) executes operating system and application logic that is persistently stored in the non-volatile data storage61and loaded onto the data processing platform17for execution thereon. Such execution provides for automatic control over system11in accordance with the operations described herein (FIGS. 14A,14B and14C).

Optionally, a keyboard and mouse (not shown) represent further types of input devices which could be utilized with system11permitting a user to input information to data processing platform17. Optional keyboard and mouse would provide the user with the ability to enter relevant information about a prescription. Such information is more preferably input by the user through touch-screen-type display37and/or barcode scanner51as previously described. In other systems, information may be provided from another data processing system that is coupled to system11over a communication link therebetween.

Data processing platform17also preferably interfaces to an optical drive69(which may be realized by a CDROM drive, DVD-ROM drive or other suitable device) and an image scanner71. Optical drive69can be mechanically supported in an independent housing and interfaced to data processing platform17through suitable connection means. Barcode scanner51and image scanner71are preferably mechanically supported in independent housings and interfaced to data processing platform17through suitable connections (such as a wired or wireless data link therebetween). Alternatively, barcode scanner51and/or image scanner71can be housed within housing13. In addition, system11may include a printer72that prints a prescription label143and prescription order paperwork147for each prescription of a prescription order. System11may also include a connection such as a USB port or other similar connection to enable batch prescription data to be transferred to/from system11.

Non-volatile data storage61stores an image database that maintains image files for a large number of commercially-available medications indexed by NDC number (hereinafter referred to as the “medication image database”). Each image file is an electronic image of a particular medication as identified by its corresponding NDC number. Exemplary image files from medication image database are illustrated in Medication Image field77, Image field138and Collated Order field89of the interfaced system11screen displays (e.g.,FIGS. 17,18,20,22,24,26,28,30,31,34-35) and Medication Image field1077of the non-interfaced system11screen displays (e.g.,FIGS. 19,21,23,25,27,32-33). The medication image database is updated periodically by loading updated files stored on an optical disk into the system via optical drive69or via updates from PMS21via link23. Alternatively, the medication image database may be updated from a remote computer system coupled thereto over a network link (e.g., over a LAN or WAN/Internet), for example, from a database provider such as First DataBank® of San Bruno, California or Medi-Span® of Indianapolis, Ind.

Non-volatile data storage61may also store a database of records indexed by prescription numbers (hereinafter referred to as the “prescription record database”). A prescription number is a unique number assigned by the pharmacy to each prescription. Exemplary prescription numbers can be seen in Prescription Number field135of New Order screen119ofFIG. 17. The unique prescription number is used to track all information related to fulfillment of the prescription. The prescription record database may be local on storage61for systems which are interfaced with PMS21and for stand-alone systems11which are not interfaced with PMS21. Alternatively, the prescription record database could be maintained by PMS21and accessed by system11via link23.

As described below, the prescription record database for an interfaced system11may include a record of each prescription awaiting fulfillment, examples of which (prescriptions127,129,131) are seen on New Order screen119ofFIG. 17. The information could include patient name, prescription number, medication type, strength and form, and required medication quantity. Other information in prescription record database for each prescription may include the status of each such prescription (e.g., fully or partially fulfilled, held because medication is not available, held because of a prescription data error, etc.).

The prescription record database for a non-interfaced system11may include a record of each prescription for which fulfillment has been initiated as well as the status of each such prescription (e.g., fully or partially fulfilled, held because medication not available, held because of an error, etc.). The record could include the NDC, the prescription number, the medication type, strength and form, and the required medication quantity.

The prescription records for each prescription number in the prescription record database may also include an image file of the original script of the prescription (as written by the doctor) and an image file of the printed prescription label for the prescription number. These image files are output to system11prescription record database from PMS21or may be loaded into the prescription record database by means of image scanner71.

The prescription record database for each prescription number is updated following prescription fulfillment with a record such as record70a(FIG. 37A) for a single prescription or record70b(FIG. 37B) for all prescriptions collated by patient including all desired information relating to the fulfillment transaction. Record70aor70bof prescription fulfillment may be accessed from non-volatile data storage61for a user-determined amount of time.

For interfaced systems11, a prescription record database maintained by PMS21may also be updated following prescription fulfillment with a record including all desired information relating to the fulfillment transaction. Such record is maintained for archival purposes.

Pharmacy workflow in conjunction with operation of system11will now be described with reference to the flow diagram ofFIGS. 14A,1413and14C and exemplary screen displays ofFIGS. 15-36. The pharmacy workflow management executed by system11as shown in the examples ofFIGS. 14A-14Cand the screen displays ofFIGS. 15-36is enabled by a program of instructions residing in non-volatile data storage61of data processing platform17. When executed, the instructions enable system11to perform the pharmacy workflow management described herein. For interfaced systems11, the instructions enable system11to receive prescriptions from PMS21. The prescriptions may be stored in prescription record database on non-volatile storage61. The instructions further enable a user to select one of the stored prescriptions for fulfillment and for the selected prescription to be retrieved. The instructions enable required medication to be counted and can create a record (e.g., record70aor70b) that the quantity of the medication required by the retrieved prescription has been counted. For non-interfaced systems11, the instructions enable counting and verification of prescriptions as described herein.

It will be apparent that system11provides the user (e.g., a registered pharmacist, a pharmacy technician or other authorized person) with a powerful tool which enables control of pharmacy workflow directly from system11. System11enables counting of any tablet-form product including medications, nutriceuticals, and supplements. System11can also manage workflow involving containers not requiring tablet counting, such as a medication-containing box174as will be described.

The operations begin at block201when the user places an on/off switch59in the “on” position if system11is not already operating. In block203, data processing platform17is initialized, and system11is placed in a ready state.

During initialization, a check is performed to determine whether system11is interfaced with PMS21. If an interface with PMS21does not exist, system11is operable as a stand-alone system. Prescription order fulfillment processing steps are described herein for both interfaced and non-interfaced systems11. If an interface is present, all prescription orders which have been validated by PMS21are sent to system11via communication link23and are stored in prescription record database in files organized by prescription number in non-volatile data storage61awaiting fulfillment. Alternatively, validated prescription orders may be delivered to system11via batch data delivery as previously described.

In block205, a user is authenticated and logs into system11. In the example, user authentication and login can occur in several ways. For example, a user can enter a user ID (name and password in the example) into system11by means of a QWERTY-type keypad (e.g., keypad65,FIG. 70) displayed on touch-screen-type display37, by means of an optional keyboard (not shown), or by means of biometric sensor55. The user ID is received by data processing platform17.

In the example, biometric sensor55is a fingerprint sensor. Everyone is known to have unique, immutable fingerprints. A wide number of fingerprint sensors are commercially available including, for example, the VPASS fingerprint sensor distributed by Bioscrypt Inc. of Mississauga, Ontario, Canada. If the presented fingerprint matches a stored fingerprint, biometric sensor55communicates the user ID associated with the stored fingerprint to processing platform17. If the presented fingerprint fails to match a stored fingerprint, biometric sensor55communicates an error message to processing platform17.

If the user ID keyed in by the user or output from biometric sensor55to processing platform17is valid, processing platform17identifies the user and permits user login, enabling continued processing (blocks207and on). If the user ID is incorrect or if an error message is transmitted from biometric sensor55, then data processing platform17denies user access, and the continued operations of blocks207and after are not performed. In this manner, only authenticated users can use system11for its intended purpose. Similar authentication operations may be performed for other biometric sensor types. Alternatively, user authentication can be accomplished by other known means, such as a smart card reader or an RFID reader.

Following successful login at block205, a Start screen73or1073is shown on touch-screen-type display37as illustrated inFIGS. 15 and 16. Start screen73is shown if system11is interfaced to PMS21and Start screen1073is shown if system11is not interfaced to PMS21. In the example, each Start screen73,1073includes controls in the form of graphical user interfaces (GUIs) which permit the user to select from several processing options. Information-displaying fields are also provided. The controls and fields shown on Start screens73,1073and on the further displays ofFIGS. 17-36are non-limiting examples provided for purposes of illustration only. It should further be recognized that the screen displays shown inFIGS. 15-36, and the sequence of the screen displays, are illustrative and are not intended to be limiting.

In the example, each Start screen73,1073provides information indicating that three counting modes are available. The counting modes are: (1) a customer label scan/prescription selection counting mode (blocks209-253), (2) a scan override counting mode (blocks255-267) and (3) a Universal Product Code (“UPC”) barcode scan counting mode (blocks269,271,273and257-267). Each counting mode can be performed by either interfaced or non-interfaced systems11except that non-interfaced systems do not receive validated prescriptions orders directly from PMS21via link23or batch delivery. Each counting mode is described below.

Referring toFIG. 15, Start screen73of interfaced system11shows exemplary fields and controls. The fields and controls which are active on a particular screen correspond to the particular action then in process. Fields include: an Activity field75, a Medication Image field77, a Prescription Status Indicator field79, a Customer/Patient field81, a Prescription Number field83, a Medication Description field85, a Medication NDC field87, a Collated Prescription Status field89, a Main Instructions field91, a Tray Status field93and a Count Status field95. Fields for the User Name94and Date and Time of Day96are also provided. In the example, the user name is shown as “Administrator” indicating that the logged-in user is also system Administrator. System11may be configured to display the user's given and surnames in field94, if desired.

Activity field75shows the current system11operation. Medication Image field77shows a graphic image of the color, shape, markings and form of the medication required by the prescription being fulfilled. Each image is retrieved from the medication image database based on the NDC number of the medication required by each prescription. Prescription Status Indicator field79indicates the status of the prescription in the workflow. Customer/Patient field81, Prescription Number field83, Medication Description field85and NDC field87, respectively, provide information about the patient name, prescription number, medication description and medication NDC for the selected prescription. Collated Prescription Status field89shows the status of all prescriptions grouped together for the patient and may include an image of each medication required by the prescription.

Main Instructions field91prompts the user to take an action. As shown on Start screen73ofFIG. 15, Main Instructions field91includes a prompt to scan a prescription label or a UPC barcode on a medication package to initiate one of the first two counting modes. Tray Status field93indicates whether a tray45is detected in bay47. Tray45is shown as detected in Start screen73because no “x” symbol is imposed over the tray icon. Vial size field92,1092indicates a recommended vial size suitable to hold the counted tablets. The recommended vial size may be based on the size of the tablets and count. Finally, Count Status field95indicates the quantity of tablets counted by tablet counter15. Start screen73displays a 0 in Count Status field95indicating that no count has yet occurred.

Referring further toFIG. 15, controls include: a Count push button97, a New push button99, a Check push button101, a Held push button103, a Done push button105, a Help push button107, a Rpts (reports) push button109, an Errors push button111and a Logout push button113. Additional control push buttons include a Cancel Fill push button115and a Scan Override push button117.

Selection of Count push button97clears the current screen for a new count while selection of New push button99causes system11to display any existing prescription orders in non-volatile data storage61that await selection for fulfillment (block213).

Selection of Check push button101causes system11to display any prescription orders that have been counted using system11, but which await final checking and verification by a registered pharmacist (blocks247-251).

Selection of Held push button103shows any prescriptions that have been placed on hold and have not been fulfilled. Prescriptions may be placed on hold, for example, if medication is not available to fulfill the prescription.

Selection of Done push button105causes system11to display any existing prescription orders that have been fulfilled using system11. If an interface with PMS21is provided, prescriptions are preferably collated by patient for ease of review by the user.

Selection of Help push button107provides access to support, system setup and configuration details, user and medication database maintenance as well as technical resources.

Selection of Rpts (reports) push button109takes the user to a list of available reports which can be sorted by category and viewed on display37or printed with printer72. For example, the reports include a record (e.g., record70aor70bofFIGS. 37A,37B) of each prescription fulfilled by system11.

Errors push button111appears only if system11has determined that data received from PMS21cannot be processed. Selection of Errors push button111displays prescriptions flagged with the error so that the user can determine the source of the error and make appropriate corrections so that the prescription can be fulfilled using system11.

Selection of Logout push button113permits the user to log off system11.

Selection of the Cancel Fill push button115permits a user to interrupt any process at any time. The Cancel Fill push button115can be selected once a prescription is selected for processing, or counting has begun, or at any time the Cancel Fill button is visible. Interrupting a process may be useful if the user wishes to start over or stop use of system11to perform a task unrelated to system11.

Scan Override push button117permits a user to proceed directly to tablet counting without any preliminary processing steps (blocks255-267). For example, Scan Override117can be selected when only a tablet count is required as part of managing inventory by counting tablets in inventory.

Referring next toFIG. 16, Start screen1073of non-interfaced system11also includes information-providing fields and user-selectable control push buttons. These fields and controls provide the information and control as described in connection with the like fields and push buttons described in connection with Start screen73. Fields include: an Activity field1075, a Medication Image field1077, a Prescription Status Indicator field1079, a Customer/Patient field1081, a Prescription Number field1083, a Medication Description field1085, a Medication NDC field1087, a Main Instructions field1091, a Tray Status field1093and a Count Status field1095. Fields for the User Name1094and Date and Time of Day1096are provided. No Collated Prescription field89is required because the non-interfaced system11does not access PMS21to receive and manage collated prescriptions.

Control push buttons on Start screen1073include: a Count push button1097, a New push button1099, a Check push button1101, a Held push button, a Done push button1105, a Help push button1107, a Rpts (reports) push button1109and a Logout push button1113. Additional control push buttons include a Cancel Fill push button1115and a Scan Override push button1117. These controls function as described in connection with screen73. A Hold1116and a Cancel Rx1118push button (FIG. 32) may be provided to place the prescription into a hold status for fulfillment at a future time or to terminate the prescription. If desired, a single prescription or even an entire prescription order can be cancelled by pushing Cancel Rx button1118. This status will complete the processing for the prescription (e.g., prescription127) and require nothing further. Hold and Cancel Rx push buttons may also be provided on displays for interfaced systems11.

Referring again to the flow diagram ofFIG. 14A, at decision point207, the user determines the type of counting mode. The process proceeds to entry block209if the user selects the customer label scan/prescription selection counting mode, to entry block269if the user selects the medication container UPC barcode scan counting mode, or to entry block255if the user selects the scan override counting mode.

Referring toFIGS. 14A and 14B, exemplary steps of the customer label scan/prescription selection counting mode are now described with respect to blocks/decision points209-253. If an interface between system11and PMS21exists (decision point211) the process moves to block213. Entry of block213(by pressing New button99) results in display of prescriptions which await fulfillment on New Order screen119illustrated inFIG. 17. The prescriptions received from PMS21are retrieved from the prescription record database residing in non-volatile data storage61.

New Order screen119contains fields which provide information for the user regarding each prescription and the prescription order. Fields include: a Patient Name field121, a Pharmacy-Assigned Patient Identification Code field123and a Delivery-Status field125indicative of whether the patient is waiting for the prescription or will pick up the prescription later.

New Order screen119also shows one or more prescriptions for each patient. The prescriptions are preferably collated by patient as illustrated inFIG. 17. Grouping together of pending prescriptions by patient makes it easier for the pharmacist or pharmacy technician to fulfill all prescriptions of all prescription orders pending for each patient. As illustrated inFIG. 17, three prescriptions127,129,131are shown for fictitious patient Pablo Martini. Each prescription127-131shown includes fields for the patient's name133, pharmacy-assigned prescription number135, medication name, strength and form information137, medication quantity139, medication image138and status as a new or previously-fulfilled prescription140. Collectively, prescriptions127-131may represent a single prescription order if placed for fulfillment together or may represent separate prescription orders if placed separately. Touching one of the up/down arrows141permits the user to scroll up or down to view pending prescriptions for patients Zage and Gelty and others.

New Order screen119may also include some or all of the control push buttons97-113described above in connection with Start screen73. New Order screen119may also include User Name and Date/Time fields94,96or other information fields.

In block213ofFIG. 14A, a user may display New Order screen119and retrieve a prescription for fulfillment in subsequent block215. The user may select New push button99on any screen on which New push button99is displayed. This will call up the New Order screen119ofFIG. 17. The user may then touch one of the prescriptions to select a prescription for fulfillment at block215and trigger retrieval of the selected prescription from non-volatile storage61.

Referring further to New Order screen119ofFIG. 17, an arrow177may appear on any screen pointing to one of the control push buttons97-113. A number in such arrow177is indicative of the number of prescriptions residing in each control category. For example, arrow177pointing to New push button99indicates that there are 30 new prescriptions awaiting fulfillment, and arrow177pointing to Errors push button111indicates that there are five prescriptions with errors that require attention. The number in each arrow177is incremented or decremented as new prescriptions are added or removed from each control push button category.

Therefore, New Order screen119of interfaced system11provides the user with a centralized point of control including user access to all information required to fulfill any pending validated prescription order. The user may scroll up or down using arrows141to access any of the pending validated prescription orders. Access to the entirety of the pending validated prescription orders through system11provides the user with an improved level of control over pharmacy workflow because, for example, the user may fulfill any prescription in any sequence that is most efficient and is no longer required to wait for physical delivery of prescription order paperwork (e.g., paperwork147) from pharmacy PMS21. For instance, the user can advance the order for fictitious patient Martini past an order for fictitious patient Gelty because patient Martini is indicated to be waiting for his order as indicated in field125, whereas patient Gelty will pick up his order at a later time as indicated in field125next to his order on New Order screen119.

Referring again toFIG. 14A, in block215, for interfaced system11asingle prescription is selected and retrieved for fulfillment. As noted, a single prescription may be selected simply by touching touch-screen-type display37proximate the prescription (e.g., one of prescriptions127-131). Selection in block215triggers retrieval of the selected prescription from non-volatile storage61.

As an alternative to prescription selection using New Order screen119, at block215a user may select a prescription for fulfillment by scanning a prescription label143barcode145with scanner51. Prescription selection by label scanning triggers retrieval of the selected prescription from non-volatile storage61. In this case of prescription selection by label scanning, New Order screen119is bypassed and the process proceeds directly to collate all other pending prescriptions for the patient and to start processing of the prescription corresponding to the scanned label as described in connection withFIG. 18.

Referring toFIG. 13, there is shown exemplary prescription order paperwork147including an exemplary prescription label143with machine-readable indicia in the form of barcode145which may be scanned to select the prescription for fulfillment and trigger retrieval of the selected prescription from non-volatile storage61. Label143is generated by PMS21as prescription order paper work147for each prescription for each patient. Prescription label143of prescription order paperwork147is adhesive-backed and is peeled off of paperwork147and applied to the patient prescription container (not shown) for the patient's prescription.

If system11is interfaced to PMS21, then barcode145need only include a prescription number149which matches the prescription number (e.g., prescription number 015644 in Field135) in the prescription record database in data storage61. The record of the prescription in the prescription record database will include the data expected to be embedded in the UPC barcode173of the medication container175(FIG. 12A) for the medication called for in each prescription being filled. Scanning of barcode145will retrieve the corresponding prescription from prescription records database in storage61and will further result in retrieval of all other prescriptions collated for that patient so that all pending prescriptions for the patient are collated. The process for the interfaced system11moves directly to processing of the prescription of the scanned label inFIG. 18as described below.

Other information provided on prescription paperwork147includes: pharmacy identification information151, prescribing physician name153, patient name155, medication name157, NDC159, medication quantity161, prescription expiration date163, and prescription price165. Paperwork147may also include a receipt169with information corresponding to that of prescription label143.

At block217, label scanning can also be used to select a prescription for non-interfaced systems11. Selection in this context refers to selecting a prescription by selecting and scanning prescription paperwork147to initiate fulfillment of the corresponding prescription. More specifically, receipt169includes a barcode150which may be used for label scan prescription selection for non-interfaced system11. Embedded in barcode150are three fields of information152shown next to barcode150including the 11-digit NDC used by the pharmacy (00002-3228-30), the pharmacy-assigned prescription number (015644) and the quantity of tablets required by the patient's prescription (0020). For non-interfaced systems11, the NDC number in barcode150can be used with a commercially-available database provided in non-volatile storage61to look up UPC173of container175for subsequent scan verification and can be used to retrieve a reference image of the medication from non-volatile storage61in Medication Image field1077as described herein. Each NDC identifies the medication source, medication type and strength and package type and medication quantity. The database will include the specific UPC code173or other code on the container175for the medication identified by the NDC. If barcode150on paperwork147is scanned, then non-interfaced system11immediately begins to process that prescription (e.g., prescription127) resulting in selection of the prescription at block217and retrieval of the UPC173and reference image information from non-volatile storage61.

Fulfillment of prescription127requiring 20 capsules of 25 mg Eli Lily & Co. Strattera medication for fictitious patient Pablo Martini is described below for both interfaced and non-interfaced systems11. Fulfillment of prescriptions129,131for patient Martini would occur in the same manner.

If system11is interfaced, then block215ofFIG. 14Ais entered. The user selects a prescription by touching a prescription shown on New Order Screen119or by scanning a barcode145on the prescription label143as previously described. Upon selection, the screen shown on display37of interfaced system11changes to the Prescription Filling Screen179ofFIG. 18, and all relevant information pertaining to fulfillment of prescription127is presented to the user. Activity field75is set to “Filling” and Prescription Status Indicator field79is set to “Processing” to indicate that fulfillment of the prescription is in process. Patient name field81is set to show the patient name and the prescription number of the prescription being fulfilled is shown in field83. The prescribed medication image, medication name, strength and form and NDC number are set in respective fields77,85,87. All three prescriptions127,129,131are collated together in Collated Order field89with prescription127indicated as being in a “Processing” mode. Main Instructions field91prompts the user to scan the UPC barcode on a medication container for the required medication.

If system11is a stand-alone system with no interface to PMS21, then block217ofFIG. 14Ais entered. In order to fulfill prescription127(and other prescriptions), the user scans prescription paperwork147barcode150(FIG. 13) with scanner51. Barcode150may include fields for the NDC of the prescribed medication, the prescription number and required quantity of medication for the prescription as previously described. A record of the prescription (e.g., prescription127) is established for each prescription number in the prescription record database of storage61. The NDC, prescription number and medication quantity is stored in the record. A relational database stored in non-volatile data storage61is accessed to associate the UPC barcode173of medication container175(FIG. 12A) with the NDC number for the required medication.

Referring now toFIGS. 14A and 19, selection of prescription127at block217for the non-interfaced system11by scanning barcode150causes Start screen1073to be replaced with Prescription Filling screen1179. As with screen179of interfaced system11(FIG. 18), Activity field1075is set to “Filling” and Prescription Status Indicator field1079is set to “Processing” to indicate that fulfillment of the prescription is in process. Because the patient name is not known from scanning barcode150, patient name field1081is set to show the date and time of day while the prescription number of the prescription being fulfilled is shown in field1083. The medication image, medication name, strength and form and NDC number for the Strattera medication required by prescription127are again set in respective fields1077,1085,1087. This information is retrieved from a relational database corresponding to the NDC number in barcode150from non-volatile data storage61. Also retrieved from the relational database is UPC barcode173expected to be on container175. The expected UPC barcode is related directly to the NDC number embedded in barcode150. Single prescription127being filled is shown with prescription127indicated as being in a processing mode in field1079. Main Instructions field1091prompts the user to scan the machine-readable UPC barcode indicia173on container175for the required medication.

Block219ofFIG. 14Ais entered next for both interfaced and non-interfaced systems11. In block219, the user selects a medication container (e.g., container175) containing tablet-form medication required by the prescription (e.g., prescription127).

In block221, the user scans UPC barcode173on container175with barcode scanner51.

At decision point223, actual UPC173on container175is compared by the program of instructions operating on data processing platform17with the expected UPC for the medication from the prescription record database in non-volatile data storage61.

Referring toFIGS. 14A,20and21, if the comparison at point223results in a match between the actual UPC173and expected UPC, counting of tablets is enabled and Begin-Pouring screen181ofFIG. 20is shown on display37for an interfaced system11or the Begin-Pouring screen1181ofFIG. 21is shown on display37at block223for non-interfaced system11.

For the interfaced system11, if there is no match then Error screen182ofFIG. 22is presented to the user. In addition, speaker63may generate an audible signal indicating that the comparison did not result in a match. Instructions in Main Instructions field91indicate that an error has been detected to prompt the user at block223to re-scan UPC173(repeat block221) or to select a different container175(repeat block219). Prescription Status Indicator field79remains set to “Processing” and the word “Processing” also appears in Collated Order field89for prescription127because no match has occurred at point223.

For the non-interfaced system11, if there is no match then Error screen1182ofFIG. 23is presented to the user. An audible error signal can be generated by speaker63. Instructions in Main Instructions field1091indicate that an error has been detected to prompt the user at block223to re-scan UPC173(repeat block221) or to select a different container175(repeat block219).

Other error types can occur during the fulfillment process and information can be displayed to alert the user to such errors. Examples of errors can include, for example, that the medication is not in the prescription record database in storage61, that data was erroneously entered for the prescription (for example erroneously indicating that zero tablets are required), that the UPC was not found in the relational database in storage61, or that the lengths of barcodes145and173do not match. These and other error conditions can trigger system11to display instructions in Main Instructions field91or1091, prompting the user to take appropriate corrective action.

Referring toFIGS. 14A,20and21, block225is entered to start a tablet count if there is a match in block223. As illustrated inFIG. 20(interfaced system11) andFIG. 21(non-interfaced system11), Main Instructions fields91,1091of the Begin-Pouring screens prompt the user to begin pouring the tablets from a container (e.g., container175) into feeder device19in response to the match in block223. Prescription Status Indicator fields79,1079are set to “Verified” indicating to the user that UPC173of container175matches the medication required by the prescription. Collated Order field89is also set to “Verified” for prescription127also indicative of the match. (Collated Order field89is set to “New” for prescriptions129and131because fulfillment of these prescriptions has not yet commenced.) Count Status field95,1095are set to 0, and the tablet quantity required by the prescription (e.g., prescription127) is displayed.

In the example ofFIGS. 1-6, the user pours tablet-form medication from container175into funnel41. Tablet counter15automatically counts each tablet as it falls from funnel41past collimated IR sources308a,308band sensors307a,307band into tray45. The system software previously described performs the count, and Count Status fields95,1095are instantaneously updated as each tablet is counted.

Referring next toFIGS. 14B,24and25, at decision point227the actual tablet count is compared to the required tablet count for the prescription. If the actual tablet count equals the required tablet count, then Count-Complete screen183ofFIG. 24(interfaced system11) or Count-Complete screen1183ofFIG. 25(non-interfaced system11) is shown on display37. Prescription Status Indicator fields79,1079remain set to “Verified” providing continued indication to the user that correct container175was selected. Main Instructions fields91,1091instruct the user that the count is complete and prompts the user to remove tray45so that the counted tablets can be poured from tray45into a vial, bottle or other container for the patient's prescription. Speaker63may generate an audible signal indicating that the correct count has been made.

At decision point231, an undercount could occur if the user removes tray45before the required quantity of tablets is counted. An undercount may also occur if too much time elapses, i.e., because the count was not completed within a user-configurable time interval, such as 5 minutes, if, for example, a user might be asked to assist with another task in the pharmacy before completing the count. An undercount message indicating the undercount is provided in Main Instructions field91,1091. An audible signal generated by speaker63would also indicate an undercount condition to the user. If an undercount occurs at decision point231ofFIG. 14B, then additional tablets are poured from container175into funnel41until the actual count equals the required count at block233. The count is displayed in Count Status field95,1095.

If an overcount occurs at decision point235, then the user is notified of the overcount by a message in Main Instructions field91,1091and an audible signal from speaker63. The user is prompted to manually adjust the count by removing tablets or to re-pour the tablets through tablet counter15until the actual count equals the expected count as indicated in Count Status field95,1095.

If the tablets are poured too rapidly into tablet counter15, then an overspeed error condition can occur (step517ofFIG. 11B) indicating that the tablets passing by collimated IR sources308a,308band sensors307a,307bwere not accurately counted. If an overspeed error occurs, then the user is prompted by an audible signal from speaker63and an overspeed message (not shown) is presented on display37. The user is prompted to re-pour the tablets through tablet counter15until the actual count equals the expected count as indicated in Count Status field95,1095.

The result of blocks225,227,233and237ofFIGS. 14A and 14Bis that the correct quantity of tablets has been counted and the counted tablets are in tray45.

Referring again toFIG. 14Band to the screen displays ofFIGS. 26,27, at block229, tray45is removed and the tablets in tray45are poured into a patient medication container, such as a bottle or vial (not shown). Removal of tray45triggers display of “Filled” screen185ofFIG. 26(interfaced system11) or “Filled” screen1185ofFIG. 27(non-interfaced system11) indicating that the prescription status is considered to be “Filled” as indicated in field79,1079. Tray Status field93,1093includes an “x” symbol indicating removal of tray45. For interfaced system11, prescription127in Collated Order field89of Filled screen185(FIG. 26) changes to “Filled” indicating that the required tablets were counted and removed from the system11. For interfaced systems, prescription orders129,131await fulfillment as indicated by the two occurrences of the word “New” in Collated Order field89. Selected prescription127has been correctly counted, and the counted tablets in tray45are poured from tray45into a patient container, such as a vial or bottle.

At block239, tray45is returned to bay47. Return of tray45to bay47is detected by system11and represents the terminal point of the filling process for that prescription. An optional verification process described in connection with blocks241-251ofFIG. 14Bmay be subsequently performed for the prescription as described below.

If system11is interfaced to PMS21, then at decision point241, system11determines whether additional prescriptions must be filled for the patient (e.g., prescriptions129,131). If so, the process of steps213-241(FIGS. 14A,1413) are repeated resulting in all prescriptions for the patient being filled.

If system11is non-interfaced, the user may move to the optional verification process enabled at decision point243and executed in blocks247-249. If verification is not selected at point243, then the process is Done at block245.

Next, optional verification can occur if verification is enabled at point243. Verification by a registered pharmacist using system11is useful to provide further assurance that the prescriptions (e.g., prescriptions127-131) were filled accurately before the prescription order is made available to the patient. Verification can be performed as each prescription (e.g., prescriptions127-131) is fulfilled or after all prescriptions of a prescription order are fulfilled. Once all prescriptions are optionally verified, the prescription order is confirmed as done.

As illustrated in the interfaced system11screen display ofFIG. 24andFIGS. 28-31, verification is made easier and more efficient because interfaced system11can present all prescriptions to be verified collated by patient in Collated Order field89(FIGS.24and28-31). The pharmacist or other user is able to quickly and easily access all prescriptions for any patient in order to complete the verification process. Patient care is improved because order verification is made more accurate and the chance that a patient might accidentally not receive all required prescriptions is diminished.

Referring toFIG. 14B, blocks247and249illustrate steps of an optional verification process. Verification is available once tray45is inserted into bay47and verification is enabled at point243. Verification is preferably enabled by the administrator of system11as a user-configurable option.

For both the exemplary interfaced and non-interfaced systems11, two alternative processes are available to perform optional prescription verification in blocks247and249. Verification may be controlled by means of a fingerprint scan process or by a barcode scan process.FIGS. 28 and 29illustrate exemplary screen displays for a fingerprint-controlled verification process for interfaced system11andFIGS. 30 and 31illustrate exemplary screen displays for a barcode scan-controlled verification process for an interfaced system11. Enablement of verification at point243and selection of the type of scan may be based on preferences selected by the user, for example, in a system setup procedure executed after login at block205(FIG. 14A). For each of the examples ofFIGS. 28-31, the verification process is being performed following partial fulfillment of prescription127and before fulfillment of prescriptions129,131as indicated by the word “New” in Collated Order field89for prescriptions129,131.

Referring toFIGS. 28 and 29, for the fingerprint-controlled scan verification process, the pharmacist scans label barcode145which has been applied to the patient medication container or touches display37proximate displayed prescription127(e.g., prescriptions127-131). Block247is entered and Verification screen187a(FIG. 28) is shown on display37. Prescription Status Indicator field79remains set to “Filled” indicating to the user that the prescription has been fulfilled. Main Instructions field91prompts the user to begin the optional verification process. The medication image is displayed in field77. The user manually checks the information on screen187aagainst the physical appearance of the tablets in the patient's container and against the information provided on prescription order paperwork147.

If the correct medication has been loaded in the patient container, then in block249(FIG. 14B), the user places a finger against biometric sensor55to confirm the verification to interfaced system11. Check Completed screen189a(FIG. 29) appears on display37for interfaced systems, and a check mark appears for the verified prescription127in Collated Order field89. Activity field75is set to “Checking” indicating that verification is being performed and Prescription Status Indicator field79is set to “Checked” indicating that the prescription has been checked and verified as indicated by placement of the user's finger on sensor55. Main Instructions field91is set to “Check Completed” also indicative of completed verification for prescription127.

Referring now toFIGS. 14B,30and31, the process for barcode scan-controlled verification at blocks247,249is essentially the same as described for the fingerprint-controlled process. Block247is entered and Verification screen187b(FIG. 30) is shown on display37. Prescription Status Indicator field79remains set to “Filled” indicating to the user that the prescription has been fulfilled. Main Instructions field91prompts the user to scan label barcode145. At block247, the user then scans selected label barcode145of the prescription to initiate verification.

The user then manually checks the information on screen187bagainst the physical appearance of the tablets in the patient's container and against the information provided on prescription order paperwork147.

If the correct medication has been loaded in the patient's container, then at block249, the user scans label barcode145of the prescription for a second time to confirm the verification. Check Completed screen189b(FIG. 31) appears on display37for interfaced systems11and a check mark appears for verified prescription127in Collated Order field89. The Activity field75is set to “Checking,” indicating that verification is being performed and Prescription Status Indicator field79is set to “Checked,” indicating that the prescription has been checked and verified as indicated by placement of the user's finger on sensor55. Main Instructions field91is set to “Check Completed” also indicative of completed verification for prescription127.

Referring toFIGS. 14B,32and33, verification for non-interfaced systems11at blocks247,249is much the same as previously described for interfaced system11, except that the user has the option of verifying only the single prescription being fulfilled. The user has the ability to control verification by fingerprint or by scanning as described above for interfaced system11and such description is incorporated herein by reference. For simplicity and brevity, fingerprint-controlled verification is described herein, it being understood that barcode-controlled verification merely substitutes barcode scanning for placement of a finger on biometric sensor55.

Turning then toFIGS. 32 and 33, Verification screen1187(FIG. 32) appears on display37for fingerprint-controlled verification on non-interfaced system when the pharmacist or other user scans barcode150on paperwork147to initiate verification. The user then manually checks the information on screen1187against the physical appearance of the tablets in the patient's container and against the information provided on prescription order paperwork147. Based on the NDC in barcode150, the medication image is retrieved from the medication image database in storage61and displayed in field1077.

If the correct medication has been loaded in the patient container as determined at block249(FIG. 14B), the user places a finger against biometric sensor55to confirm the verification. Check Completed screen1189(FIG. 33) appears on display37for the non-interfaced system11. Prescription127for non-interfaced system11is now complete as indicated by Prescription Status Indicator field1079being set to “Complete” and the Main Instructions field1091being set to “Check Completed!.” Vial Size field1092is set to display the message “Order Complete” also indicating that the prescription has been verified.

A record70aindicating that single prescription127has been fulfilled and verified is stored in the prescription record database of non-volatile data storage61. The record corresponding to prescription127includes the prescription number, NDC, medication name, medication quantity, date and time the medication was counted and the date and time that the prescription was verified. This information allows the pharmacy to reconstruct fulfilment of the prescription127. The record for prescription127includes all of the information shown on Check Completed screen1189ofFIG. 33. And, the record for the non-interfaced system11could include a collation of all prescriptions fulfilled for patient Pablo Martini, including prescriptions129and131once those prescriptions129,131are verified. For the non-interfaced system11, the status of the prescription127is set as Done in block253.

Referring again to the interfaced system11andFIGS. 14B and 34, at decision point251it is determined whether all prescriptions (e.g., prescriptions127-131) for the patient have been filled and verified. If all prescriptions have been verified, Order Complete screen191illustrated inFIG. 34is shown on display37. Prescription Status Indicator field79is set to “Complete”, and Main Instructions field91is set to “Check Completed” indicating that the verification of all the collated prescriptions127,129,131has been completed. All prescriptions127-131are indicated as verified by the double check marks and setting of the word “Complete” in Collated Order field89.

The prescription order including all prescriptions127-131for fictitious patient Pablo Martini are now fulfilled and the order status is set to Done in block253.

Referring now toFIGS. 35 and 37B, interfaced system11creates record70bof each prescription filled collated by patient.FIG. 35illustrates a Completed Order Record screen193generated by interfaced system11for fictitious patient Pablo Martini after each of prescription127,129,131is fulfilled and verified. All prescriptions127-131are collated by the patient's name for convenience. Activity field75and Prescription Status Indicator field79are set to “Completed” and “Complete” indicating that the prescriptions127-131are complete and have been verified. The double check marks and word “Complete” for each prescription127-131in Collated Order field89is further indicating that the three prescriptions in the example have been completed and verified. Main Instructions field91informs the user that the system11is ready to begin a new counting process indicated by the text “Scan Next Rx.”

Referring toFIG. 37B, the information shown on Completed Order Screen193is maintained in prescription record database stored in non-volatile data storage61as record70bthat the prescriptions (e.g., prescriptions127-131) of the prescription order were fulfilled and verified. Record70bincludes all prescriptions127-131collated for patient Pablo Martini. Record70b(FIG. 37B) and display of Completed Order Record screen193(FIG. 35) can be called by selecting Done push button105and then selecting the patient's name from the universe of patient names within system11data storage61. A user would want to access Completed Order Record screen193to further verify each prescription fulfilled using system11.

Referring now toFIGS. 14A and 14C, the scan override mode of tablet counting may be entered at entry block255by selecting Scan Override push button117,1117for example on Start screen73or1073(FIGS. 15,16). Scan override mode is optionally provided should the user wish to perform only a tablet count. Scan override would be desirable, for example, to count tablets for a patient prescription order, to count tablets as part of an inventory procedure, or to confirm that a hand count of tablets was accurate.

Once scan override is entered (entry block255), the user delivers tablets to feeder device19for a count in block257. In the example ofFIGS. 1-5, this is done by pouring tablets into funnel41for counting by tablet counter15. Scan override is also useful for counting non-prescription objects such as vitamins, nutriceuticals or supplements.

At decision point259(FIG. 14C), it is determined whether the user has enabled optional verification. If verification is not enabled, the prescription is considered to be done at block261.

If verification is enabled at decision point259, the process moves to block263to initiate verification. The verification process is the same as described in connection with blocks247and249. If verification is enabled at decision point259, the user scans label143barcode145(or barcode150) to initiate verification in block263. The user then manually checks the prescription to confirm that the prescription was filled correctly. If the correct medication has been loaded in the patient container, then at block265, the user places her finger against biometric sensor55or scans label barcode145of the prescription for a second time to confirm the verification. The order status is set to done at block267. A record (e.g., record70aofFIG. 37A) of the completed order is stored in prescription record database in non-volatile data storage61.

Referring again toFIGS. 14A and 14Cand toFIG. 36, the optional UPC scan mode of tablet counting may be entered at entry block269. In block271, container175including UPC barcode173is selected. In block273, UPC barcode173is scanned with scanner51. Scanning of UPC barcode173as the first step of the process initiates the UPC scan mode. Scanning of UPC173causes a UPC Start screen195to appear on display37as illustrated inFIG. 36. UPC scan mode Start screen195is for interfaced system11. All of the fields and controls described in connection with Start screen73(FIG. 15) are provided, and the description of such fields and controls is incorporated by reference herein.

Fields illustrated on Start screen195(FIG. 36) include: an Activity field75, a Medication Image field77and a Prescription Status Indicator field79. Since no patient or prescription information is known for a UPC scan mode count, Customer/Patient field81and Prescription Number field83show the date and time of day of the UPC scan count. Other fields are a Medication Description field85, a Medication NDC field87, a Main Instructions field91, a Vial Size field92, a Tray Status field93and a Count Status field95. Fields for the User Name94and Date and Time of Day96are provided. No Collated Prescription field is required because the UPC scan mode is based on a count of a single medication and is not tied to a specific prescription.

Control push buttons on Start screen195(FIG. 36) include: a Count push button97, a New push button99, a Check push button101, a Held push button103, a Done push button105, a Help push button107, a Rpts (reports) push button109, an Errors push button111and a Logout push button113. Additional control push buttons can include a Cancel Fill push button115and a Scan Override push button117. These controls function as described in connection with screen73. Hold and Cancel Rx push buttons (not shown) may also be provided on display37for the purpose described in connection with Hold and Cancel Rx push buttons1116,1118.

In block257the tablets are counted by tablet counter15. Once again, in the examples ofFIGS. 1-5, this is accomplished by pouring the tablets from container175into feeder device19through funnel41. Blocks259,261,263,265and267described in connection with scan override counting mode are repeated for the UPC counting mode providing the opportunity for the user to verify and check the prescription for accuracy. The order status is set to Done at block267if verification is enabled. A record such as record70a(FIG. 37A) of the completed order is stored in prescription record database in non-volatile data storage61.

System11can also be configured to fulfill prescription orders for medication and other health-care-related products not requiring counting by tablet counter15, thereby providing a more comprehensive tool with which to manage pharmacy workflow. For example, a patient prescription order may require an ointment or other product not requiring tablet counting as represented by box174illustrated inFIG. 12B. Box174includes a UPC barcode176.

For interfaced systems11, the medication or product contained in box174can appear as a separate prescription on New Order screen119(FIG. 17). The patient name121, prescription number135, medication name, strength and form137, count139, image138and status140information can be provided for the medication or product in box174. Barcode176can be scanned with scanner51and the UPC verified to confirm that the box contains the medication or other product required by the prescription. The medication in box174can then be verified as described in connection with blocks247and249.

Accordingly, patient prescription order workflow for a wide-range of medications can be easily managed by system11. Accuracy in prescription order fulfillment is improved by providing a greater level of certainty that the patient is receiving all of the medication required by the patient's prescription order and that the selected medication is correct. Because system11reduces the time required to fulfill patient prescription orders, the pharmacist is free to perform other valuable tasks such as counseling patients. The result of system11implementation is an improvement in pharmacy management and in the general level of patient care.

Workflow Management System11′

FIGS. 38-49illustrate a further embodiment of an exemplary pharmacy workflow management system11′. System11′ includes automatic tablet counter15and is fully capable of operating as a pour-through tablet counter as described and illustrated in connection with system11.

System11′ differs from workflow management system11in that system11′ combines automatic tablet counter15with a second automatic tablet counter615of tablet feeder19thereby providing system11′ with a cassette-based dispensing capability.

In the example of system11′, each tablet counter15,615represents a system comprising apparatus and code. With respect to system11′, tablet counter15is referred to herein as a first tablet counter and tablet counter615is referred to herein as a second tablet counter. Tablet counters15,615are also referred to as object counters because counters15,615can count objects generally. The combination of first and second tablet counters15,615and other component parts described herein provides pharmacy personnel with improved control over counting tablets required for prescription fulfillment. It will be understood that first and second tablet counters15,615are described in the context of prescription fulfillment but can count objects in applications other than prescription fulfillment.

In the embodiment of system11′, tablet feeder19comprises a cassette dispenser601capable of automatically feeding tablet-form medication (e.g., tablets321-327) and other objects from a cassette603mounted to the mounting assembly601. In the example, tablets604,606,608,610are fed from cassette603into funnel41′ and chute43portions of tablet feeder19for delivery to first tablet counter15.

Cassette603may be rapidly mounted to, and removed from, cassette dispenser601. In the example, second tablet counter615includes a detector605(FIGS. 44-46), supported by cassette dispenser601and further includes a controller607(FIG. 42) which increments a tablet count as each tablet (e.g., tablet604) is fed from a mounted cassette603by cassette dispenser601. In the example, data processing platform17controls operation of cassette dispenser601and feeding of tablets from cassette603mounted thereto. In the example, the tablet count displayed to a user is provided by first tablet counter15.

In the example, the count from first tablet counter15is compared in real time by data processing platform17with the count from second tablet counter615to confirm the quantity of tablets fed from cassette603and counted by first tablet counter15. The comparison can be used for various purposes, including to confirm that tablets are moving freely through funnel41′ and chute43and to confirm that the correct quantity of tablets has been dispensed as required by the prescription being fulfilled.

Systems11and11′ share many components, video display screens and operational steps. For convenience and brevity and to facilitate ease of understanding, reference numbers and figures used previously to describe components and operational steps of system11are used to describe like components and operational steps of system11′, it being understood that the date and time stamps of the figures from system11are not sequential with the date and time stamps of the figures from system11′.

Turning then toFIGS. 38-49, system11′ includes a housing13that houses first tablet counter15and a data processing platform17. Data processing platform17includes all components necessary for data processing (e.g., one or more printed circuit boards that include a microprocessor, memory and interface circuitry mounted thereon). Accordingly, a data processing platform17includes any number of components performing some or all of the data processing.

In the example, data processing platform17interfaces to first tablet counter15and cassette dispenser601controller607of tablet feeder19to control the operations of system11′ during the pharmacy workflow management operations carried out by system11′. These operations include control of pharmacy workflow involving fulfillment of prescriptions which require tablet counting and, in embodiments, may also include control of pharmacy workflow involving fulfillment of prescriptions for other medication types such as unit-of-use medications, pre-packaged medications and things (e.g., ointments, syringes, inhalers, etc.).

Data processing platform17may interface with a Pharmacy Management System (PMS)21as described and illustrated previously in connection with system11. Data processing platform17may be connected to PMS21through a communication link represented by line23inFIG. 49providing a means for data transmission back-and-forth between PMS21and system11′. An interface between system11′ and PMS21may be provided by means other than link23, such as by batch delivery of prescription orders from PMS21to system11′ via a portable non-volatile memory device (not shown). Prescription order data downloaded onto the memory device could then be transferred to system11′ by pharmacy personnel.

As with system11, validated prescription orders consisting of one or more prescriptions are transmitted electronically from PMS21via link23, or by batch, to data processing platform17of system11′ for managed prescription order fulfillment as described in detail below. Following prescription order fulfillment by a pharmacy technician and/or registered pharmacist utilizing system11′, a record of each completed prescription order may be sent by system11′ back to PMS21providing confirmation of prescription order fulfillment.

System11′ can also function as a stand-alone system which is not interfaced with PMS21as is the case with the example of system11described previously. For non-interfaced embodiments of system11′, PMS21provides instructions and information for fulfillment of separate prescriptions. This information may be in the form of prescription order paperwork147(FIG. 13) which includes all information required to fulfill a validated prescription as described herein.

Systems11and11′ share other hardware, database, storage and code components described now in connection withFIGS. 38-49. System11′ includes top25and bottom walls27, sidewalls29,31and front33and rear walls35. System11′ includes a display37mounted to housing13front wall33and interfaced with data processing platform17. Display37outputs information to a user of system11′, such as a pharmacy technician or pharmacist. Display37preferably provides status messages to the user, including information relevant to the management of pharmacy workflow, the number of tablets counted by first tablet counter15and prescription status. First tablet counter15provides this information in real time, including near-instantaneous display of counted tablets in the Count field95,1095(e.g.,FIGS. 24,25,60,61). Examples of screen displays are discussed in connection withFIGS. 55-75and20-36.

As in system11, display37of system11′ is preferably a flat panel liquid crystal display (LCD). It is preferred that display37is a touch-screen-type display thereby enabling display37to also serve as an input device for transmission of information from the user to data processing platform17. Data is transmitted from display37to data processing platform17of the second embodiment11′ when a user touches display37proximate information or an image shown on display37. A touch-screen-type display may display an image of a QWERTY-type65(e.g.,FIG. 70) or ABC-type keypad which enables a user to input information to data processing platform17by touching keys of the keypad. Such a keypad would be useful for inputting information to data processing platform17, for instance user login information, prescription number information or NDC information. Numeric keypads may also be provided to input information to data processing platform17as described below. Other types of displays, such as a cathode ray tube (CRT) or digital numeric display, may be used. System11′ could optionally utilize an external keyboard and mouse (not shown) connected to a universal serial bus port (USB) of system11′ (not shown) if a touch-screen-type display is not used.

Funnel41′ is provided to receive tablet-form medications and other objects poured by a user from a bulk storage container175(FIG. 12A) or fed from a cassette603. Funnel41′ is attached to vertically-oriented chute43which is removably seated in mount39on housing top wall25. Tablet-form medications and other objects fall by means of gravity through funnel41′ chute43, past tablet counter15into a tray45removably positioned in tray bay47provided in housing front wall33. Tray45may be removed from housing13bay47by grasping and pulling tray handle49, thereby permitting medication in tray45to be conveniently poured into a container (not shown) such as a vial or bottle which is subsequently provided to the patient.

Referring further toFIGS. 38-43, system11′ includes other external and internal components as described in connection with the example of system11. These components include a barcode scanner51input device secured to housing13sidewall31by support53as previously described. As described in connection with the first embodiment11, other types of code readers, such as a radio frequency identification tag (RFID) reader (not shown) may be utilized separately or in combination with barcode scanner51. In the example, a biometric sensor55is mounted to housing13front wall33as described in connection with system11. Data processing platform17interfaces with both barcode scanner51and biometric sensor55.

Power cord57supplies electrical power to power supply58of system11′. A rocker-type ON/OFF switch59is provided along housing13sidewall31to control the electrical power delivered to power supply58.

Referring now toFIG. 49, data processing platform17interfaces to a number of components that are housed within system housing13, including non-volatile data storage61(which may be realized by a hard drive, flash memory or other suitable non-volatile memory means), an audio speaker63and touchscreen-type display37. Data processing platform17executes operating system and application logic that is persistently stored in the non-volatile data storage61and loaded onto the data processing platform17for execution thereon. Such execution provides for automatic control over system11′ in accordance with the operations described herein (FIGS. 50-53Aand54A-54D).

As previously described, information may be input by a user to data processing platform17through a touch-screen-type keypad65shown on display37(an example of which65is illustrated inFIG. 70) and/or barcode scanner51also as previously described. In other systems, information may be provided from another data processing system that is coupled to system11′ over a communication link therebetween. An optional keyboard and mouse (not shown) may also be used to input information to data processing platform17.

Data processing platform17also preferably interfaces to an optical drive69(which may be realized by a CDROM drive, DVD-ROM drive or other suitable device) and an image scanner71. Optical drive69can be mechanically supported in an independent housing and interfaced to data processing platform17through suitable connection means. Barcode scanner51and image scanner71are preferably mechanically supported in independent housings and interfaced to data processing platform17through suitable connections (such as a wired or wireless data link therebetween). Alternatively, barcode scanner51and/or image scanner71can be housed within housing13. In addition, system11′ may include a printer72that prints a prescription label143and prescription order paperwork147for each prescription of a prescription order. System11′ may also include a connection such as a USB port or other similar connection to enable batch prescription data to be transferred to/from system11′.

Non-volatile data storage61stores an image database that maintains image files for a large number of commercially-available medications indexed by NDC number (hereinafter referred to as the “medication image database”). Each image file is an electronic image of a particular medication as identified by its corresponding NDC number. Exemplary image files from medication image database shown on display37are illustrated in Medication Image field77, Image field138and Collated Order field89of the interfaced system11′ screen displays (e.g.,FIGS. 57-58,60,62-64,66-71,73,75) and Medication Image field1077of the non-interfaced system11′ screen displays (e.g.,FIGS. 59,61,65,72,74). The medication image database is updated periodically by loading updated files stored on an optical disk into the system via optical drive69or via updates from PMS21via link23. Alternatively, the medication image database may be updated from a remote computer system coupled thereto over a network link (e.g., over a LAN or WAN/Internet), for example, from a database provider such as First DataBank® of San Bruno, California or Medi-Span® of Indianapolis, Ind.

Non-volatile data storage61may also store a database of records indexed by prescription numbers (hereinafter referred to as the “prescription record database”). A prescription number is a unique number assigned by the pharmacy to each prescription. Exemplary prescription numbers can be seen in Prescription Number field135of New Order screen119ofFIG. 57. The unique prescription number is used to track all information related to fulfillment of the prescription. The prescription record database may be local on storage61for systems which are interfaced with PMS21and for stand-alone systems11′ which are not interfaced with PMS21. Alternatively, the prescription record database could be maintained by PMS21and accessed by system11′ via link23.

As described below, the prescription record database for an interfaced system11′ may include a record of each prescription awaiting fulfillment, examples of which (prescriptions127,129,131) are seen, for example, on New Order screen119(FIG. 57) and Prescription Filling screen179(FIG. 58). The information in the prescription record database could include patient name, prescription number, medication type, strength and form, and required medication quantity. Other information in prescription record database for each prescription may include the status of each such prescription (e.g., fully or partially fulfilled, held because medication is not available, held because of a prescription data error, etc.).

The prescription record database for a non-interfaced system11′ may include a record of each prescription for which fulfillment has been initiated as well as the status of each such prescription (e.g., fully or partially fulfilled, held because medication not available, held because of an error, etc.). The record could include the NDC, the prescription number, the medication type, strength and form, and the required medication quantity.

The prescription records in the prescription record database may also include, for each prescription number, an image file of the original script of the prescription (as written by the doctor) and an image file of the printed prescription label for the prescription number. These image files are output to system11′ prescription record database from PMS21or may be loaded into the prescription record database by means of image scanner71.

The prescription record database for each prescription number is updated following prescription fulfillment with a record such as record70a(FIG. 37A) for a single prescription or record70b(FIG. 37B) for all prescriptions collated by patient including all desired information relating to the fulfillment transaction. Record70aor70bof prescription fulfillment may be accessed from non-volatile data storage61for a user-determined amount of time.

For interfaced systems11′, a prescription record database maintained by PMS21may also be updated following prescription fulfillment with a record including all desired information relating to the fulfillment transaction. Such record is maintained for archival purposes.

Non-volatile data storage61may also store a database of records indexed by cassette603(hereinafter referred to as the “cassette record database”). The cassette record database tracks each cassette603of system11′ by a unique cassette code embedded in a barcode760on cassette sidewall759(FIG. 46A, barcode760location indicated inFIG. 46) which is detected and passed to data processing platform17when cassette603is fully mounted on cassette mount621. The unique cassette code embedded in barcode760is displayed to a user on display37(e.g., icons144,146,1146,FIGS. 57,60-61) to assist the user in selecting the correct cassette603.

The unique cassette code is used to track all information related to medication or other product in each cassette603. The cassette record database tracks the type and quantity of medication or product loaded in each cassette603. The cassette record database may also track the medication strength, lot number, expiration date and medication physical form. The cassette record database preferably also tracks cassettes603which are confirmed as having been properly loaded and verified by a registered pharmacist and therefore are available for use with system11′. The cassette record database is updated following prescription fulfillment to track the inventory of medication available to system11′. This information can be utilized for reordering of medication when the inventory becomes low. Other information about each cassette603can be stored in the cassette record database based on user requirements. Therefore, the cassette record database tracks all medication or other product in the inventory of cassettes603.

The cassette record database may be local on storage61for systems which are interfaced with PMS21and for stand-alone systems11′ which are not interfaced with PMS21. Alternatively, the cassette record database could be maintained by PMS21and accessed by system11′ via link23.

Referring now toFIGS. 42-43and49, first tablet counter15of second system embodiment11′ is preferably identical to the optical system described in connection with first tablet counter15. The first tablet counter15is capable of automatically counting tablets and other types of discrete objects. (Such discrete objects, could include, for example, non-prescription objects such as vitamins, nutriceuticals, supplements, jewelry, parts or other countable things.) Accordingly, the description of automatic tablet counter15set forth above (includingFIGS. 4,5,6,7,8,9,10A,10B,10C-1,10C-2,11A and11B) is incorporated herein by reference in its entirety to describe and illustrate first tablet counter15of system11′. A summary of the previously-described structure and operation of tablet counter15follows as adapted for use as first tablet counter15of system11′.

Referring toFIGS. 42-43andFIGS. 7-11B, first tablet counter15of system11′ preferably includes infra-red (IR) emitters301a,301b, mirrors303a,303b, collimating lenses305a,305b, and IR sensor linear arrays307a,307ball as described and illustrated in connection with tablet counter15of system11. As illustrated inFIG. 7, sensor arrays307a,307bare coupled to a microprocessor-based controller311which is also coupled to collimated IR sources308a,308b. Controller311is preferably bidirectionally coupled to microprocessor-based master controller313which provides output to display37and operates speaker63to generate audible alarm315. Controller311strobes IR emitters301a,301bat a relatively high rate and preferably alternatingly so that only one IR emitter301aor301bis activated at any instant. Each mirror303aor303bdirects light309a,309bfrom a corresponding IR emitter301a,301bto a respective lens collimating lens305a,305bbeneath chute43. In the example, mirrors303a,303bdeflect light309a,309bapproximately 90 degrees. As with system11, this arrangement permits housing13to be more compact because the focal length of lenses305a,305bis traversed in two orthogonal segments, and IR emitters301a,301btherefore need not be placed so far away from lenses305a,305b.

As tablets pass between each sensor array307a,307band its respective collimated IR source308a,308b, shadows will be cast on one or more of the forty-eight sensors in each array307a,307b. This information is processed as described above in connection withFIGS. 8 through 11B, resulting in updating of the count at block513ofFIG. 11Aand display of the count to a user in the count field95,1095of a screen display as shown, for example, in the screen displays ofFIGS. 24,25,60and61. Processing of the data can also provide an alarm315and/or indication on display37if an overspeed condition (i.e., a pour-too-fast condition) exits which prevents accurate counting as at block517ofFIG. 11B.

As described below in connection withFIGS. 50-53B, data processing platform17compares the count from the first tablet counter15in real time with the count from the second tablet counter615to provide control over the quantity of tablets fed from cassette603and counted by first tablet counter15.

Like system11, system11′ includes a deflector319which is provided below sensor arrays307a,307bfor deflecting tablets into the removable tray45. Tray45preferably includes a curved inner-surface portion45awhich cooperates with and continues from deflector319. Deflector319and curved surface portion45aof the tray45together present a surface which prevents tablets which are falling into tray45from bouncing up into chute43and being recounted. It will be appreciated that the deflector319is housed in system11housing13.

Referring next toFIGS. 38-49, an exemplary cassette dispenser601is shown. Cassette dispenser601supports second tablet counter615and a removable, tablet-containing, cassette603mounted to cassette dispenser601. Each cassette603may be rapidly coupled to, and decoupled from, cassette dispenser601permitting a pharmacy to rapidly count and dispense different types of tablet-form medication from a cassette603. Certain users may prefer to utilize cassettes603as an alternative to use of a container from the manufacturer (e.g., container175,FIG. 12A), particularly for more frequently-used tablet-form products.

Cassette dispenser601of system11′ controls feeding of tablets from a mounted cassette603and second tablet counter615provides a second tablet count. Comparison of the counts from the first and second tablet counters15,615by data processing platform17provides assurance that the correct quantity of tablets have been dispensed. The count redundancy provided by first and second tablet counters15,615overcomes inaccurate counts associated with prior cassette counters which would fail to detect that too many tablets had been dispensed if two tablets (e.g., tablets321,323) were fed simultaneously from the cassette (essentially “giving away” the medication) and which would fail to detect that insufficient tablets were dispensed if a tablet fragment were dispensed from the cassette, thereby failing to meet the patient's prescription needs. And, use of cassettes603is convenient and efficient. Therefore, cassette dispenser601provides improved control over dispensing and counting of tablet-form medication and other products.

A pharmacy may utilize any number of cassettes (e.g., cassette603). Each cassette is loaded with one type of tablet-form (e.g., tablet321or604) medication or other product. Each cassette603has an identical mating structure enabling any cassette603to be rapidly coupled to, and decoupled from, cassette dispenser601. Each cassette603may be calibrated for a particular size and shape of tablet or may have a single design provided to accommodate only one tablet size or shape. When not coupled to cassette dispenser601, each cassette may be stored at a storage location (not shown) convenient to the tablet counter system11′.

The exemplary cassette dispenser601will now be described with reference toFIGS. 38-49followed by description of an exemplary cassette603suitable for use with cassette dispenser601. In the embodiment, cassette dispenser601includes a base609with feet (one indicated by reference number611). Feet (e.g., foot611) may be made of a tactile material permitting adapter601to rest firmly on a bench or desktop surface (not shown). In the example, system11′ is supported on base609. Flanges613,614extend away from base609and are secured to a respective tablet counter sidewall29,31, for example by fasteners such as machine screws (each indicated by reference number617). Support column619is rigidly attached to base609and extends upward from base609in the example.

Referring toFIGS. 38-48, cassette mount621is rigidly supported on an upper end of column619. Cassette mount621is provided to receive and support a tablet-containing cassette603in position to feed tablets into funnel41′, chute43and first tablet counter15. Thus, tablets are provided to first tablet counter15through the intermediate funnel41′ and chute43parts of tablet feeder19in the example. Cassette mount621permits rapid and secure coupling and decoupling of cassettes (e.g., cassette603) thereto.

Referring toFIGS. 38-42and44-48cassette mount621includes top623, bottom625, front627, rear629and side walls631,633defining a housing which forms an enclosure for cassette-drive motor635with a drive shaft637, micro-switch639with a switch arm641, reader645and printed circuit board647, including cassette dispenser controller607. Controller607may be an off-the-shelf microcontroller, many variants of which are commonly available for use in controlling devices similar to cassette dispenser601.

Cassette dispenser601base609, column619and mount621walls623-633may be made of any suitable material having sufficient rigidity and strength. Support column619of the example is preferably fabricated of lightweight rectangular tubing, or other suitable material.

Exemplary cassette dispenser601motor635is a DC motor which powers operation of a cassette603when the cassette603is mounted on cassette mount621. Motor drive shaft637is couplable (i.e., capable of being coupled) to a linkage in a cassette603mounted on cassette mount621. Motor635and motor drive shaft637are referred to herein collectively as a “drive system.” Other systems for powering operation of a cassette603may be utilized (e.g., gears, belts, etc.). Micro-switch639is closed by contact between switch arm641and cassette cam765. Closure of switch639generates a signal to controller607indicative that a cassette603is completely coupled to mount621.

Reader645detects barcode760(FIG. 46A) on each cassette603when cassette603is fully mounted as illustrated in FIGS.44and46-48. Reader645is preferably a binary optical sensor. In the example, each cassette603includes a barcode760on cassette sidewall759and the barcode760is positioned in the path of reader645when cassette603is fully mounted on cassette mount621. The barcode760is detected by reader645and reader645generates a signal to data processing platform17uniquely identifying the cassette603from records in the cassette record database thereby enabling system11′ to immediately identify the contents of any cassette603once mounted on mount621. Any type of machine-readable code may be used. Therefore, an RFID tag could be used in place of barcode760and reader645could be an RFID tag reader.

Cassette dispenser601controller607is operatively connected to data processing platform17, preferably by an RS 232 serial connection649(shown schematically inFIGS. 24 and 50), permitting data communication between data processing platform17and controller607as indicated by the dual-headed arrow649inFIG. 50. Controller607is operatively connected to motor635, switch639and reader645by means of respective conductors651,653,655. Electrical power is supplied to controller607, motor635, switch639and reader645from power supply58.

As illustrated inFIGS. 38-42and44-46, cassette mount621includes a pair of fixed-position elongate receivers657,659. Each receiver includes a pair of spaced apart walls661(outer),663(inner) and665(outer),667(inner), a bottom wall669,671and stop walls673,675forming a female opening677,679therebetween for snugly receiving a cassette603male sidewall portion759,761thereby supporting a cassette603at cassette mount621. Walls661-675limit lateral and downward movement of a cassette603coupled to mount621. Cassette mount621is a “universal” mount in that any cassette (e.g., cassette603) may be mounted and supported thereon.

Referring toFIGS. 42,44and46-48, detector605is supported on mount621in the path681of tablets fed from cassette603as described below. Detector605is operatively connected to cassette dispenser controller607through a suitable conductor683. Detector605includes an emitter685which may emit an infra-red (IR) energy beam687and a receiver689onto which the IR energy beam687is directed. Passage of a tablet (e.g., tablet321or604) along path681in the direction of arrow690(FIG. 48) between emitter and receiver685,689momentarily breaks beam687causing receiver689to generate a signal which is indicative of a tablet falling along path681and toward funnel41′. The signal generated by receiver689of detector605is received by cassette dispenser controller607causing controller607to increment a tablet count830(FIG. 52) by one tablet. As described in connection withFIGS. 50-53B, the tablet count830from controller607of the second tablet counter615is compared with the tablet count814from first tablet counter15.

Tablets fed from cassette603(or manually poured from a container175) fall into funnel41′. In the example, funnel41′ has a somewhat rectangular cross-sectional area at the upper open end of funnel41′ as illustrated inFIGS. 38-42. This shape makes it easy for a user to manually pour tablets into funnel41′ without removing a mounted cassette603as well as to feed tablets from mounted cassette603. Funnel41′ includes a rear portion691and a front portion693. Funnel rear portion691includes a sloped surface695proximate path681as illustrated inFIGS. 44-45and directs tablets from cassette603toward chute43. Funnel41′ sidewalls697,699along front portion693are relatively higher than sidewalls697,699along rear portion691to facilitate manual pouring of tablets into funnel41′ by a user and to direct tablets to chute43without spilling of tablets out of funnel41′.

Tablets (e.g., tablet321or604) fall through funnel41′ and into vertically-oriented chute43. Tablets are then counted by first tablet counter15as they fall past sensors307a,307b.

Tablets (e.g., tablets321or604) fall into tray45. Deflector319and tray curved inner portion45ahelp to guide tablets into tray45and to limit any bouncing of tablets back past sensor arrays307a,307bto avoid an overcount. Tray45may be removed from housing13bay47and the tray tablet contents poured into a vial, bottle or other container.

Turning now toFIGS. 38-42and44-48, there is shown an exemplary cassette603capable of being mounted on cassette dispenser601to feed tablets past second tablet counter615, into funnel41′ and to first tablet counter15. In the example, each cassette603includes a case751which defines an opening for receiving tablets and a removable lid753over the opening. Case751and lid753are preferably made of plastic materials but may be made of any suitable materials or materials. Case751includes a handle755which can be grasped by the hand of a user to mount a cassette603on cassette mount621of cassette dispenser601, to remove a cassette603from cassette mount621of cassette dispenser601or otherwise handle or transport cassette603. Case751includes a hopper757which holds a plurality of bulk-form tablets. Removal of lid753permits tablets to be poured into hopper757through a top opening defined by case751.

As previously described, cassette603includes elongate male sidewall portions759,761. Sidewall portion759preferably includes a barcode760which is read by reader645to uniquely identify the cassette603to system11′ by data processing platform17. Inwardly-facing resilient fingers (each indicated by763) are urged against a respective receiver inner wall663,667to snugly couple cassette603to receivers657,659of cassette mount621. Sidewall portions759,761abut a respective stop wall673,675when cassette603is fully coupled to mount621. Cam765acts on switch arm641to close switch639when cassette603is fully coupled to cassette mount621. Closure of switch639generates a signal to controller607indicative that cassette603is coupled as previously described.

Rotor767is provided in hopper757mounted on a shaft769. Rotor767has a top surface771with a conical shape. In the example, three vanes (each indicated by773) extend outwardly from the rotor767top surface771. Vanes773are pitched so as to push tablets toward the outer circumferential surface775of rotor767(i.e., periphery of rotor767) during rotor767rotation in the direction of arrow777.

Referring toFIGS. 46-47, a plurality of pockets, several of which are indicated by reference number779, are spaced apart at equal angular intervals in a radially-outward direction along rotor circumferential surface775. Each pocket779has a width, depth and height that allows it to hold only one tablet (e.g., tablet321or604). As illustrated inFIG. 48, an opening781is provided in a bottom wall783of cassette case751hopper757. Opening781has a cross-sectional area which permits alignment of only one pocket779of rotor767above opening781as illustrated inFIG. 48.

Cassette drive system consisting of motor635and motor shaft637powers rotor767rotation through a cassette linkage consisting of worm gear785, coupling787, pinion793and intermediate gears795in the example. Coupling787is coupled to motor drive shaft637. Coupling teeth789mesh with complementary teeth791of motor drive shaft637when cassette603is fully mounted on cassette mount621. Rotation of motor drive shaft637in the direction of the arrow797proximate shaft637(FIG. 47) causes worm gear785to drive pinion gear793on rotor shaft769through intermediate gear795. The cassette drive system consisting of motor635and drive shaft637causes rotor767to rotate in the direction of arrow777inFIGS. 46-48. Vanes703push tablets outward on the rotor767conical top surface771. One tablet (e.g., tablet321or604) falls into each pocket779. One tablet is fed from cassette603as the tablet608in a pocket779is aligned with opening781. Each tablet604,606,608,610(or tablet321) fed from the cassette603falls along path681and past detector605in the direction of arrow690(FIG. 48). Breaking of beam687registers a count by controller607of second tablet counter615as previously described.

Controller607of second tablet counter615controls motor635operation, turning motor635“on” to rotate rotor767to feed tablets from cassette603and turning motor635“off” once the required quantity of tablets have been detected by detector605and counted by controller607of second tablet counter615. Motor635is capable of powering rotor767at a high rate of revolutions per minute (RPM) for rapid dispensing of tablets from cassette603. By way of example only, motor635can power rotor767so that thirty tablets are fed from cassette603in four seconds or less.

As illustrated inFIG. 44, singulation of tablets (e.g., tablets604,606,608,610) fed from cassette603facilitates accurate counting by first tablet counter15. Singulation provides spacial separation between tablets dispensed from cassette one-after-the-other so that separate tablets fall past sensors307a,307b. Separate tablets are more accurately detected by first tablet counter15improving the accuracy of the tablet count. Singulation also facilitates avoidance of an overspeed condition and a “Pour is Too Fast! Count Failed” message as described above in connection withFIG. 11B, thereby avoiding the necessity for a re-pour of tablets (e.g., tablets604,606,608,610) into first tablet counter15. (An overspeed condition can exist where multiple tablets pass sensors307a,307bsimultaneously, preventing identification of discrete tablets by first tablet counter15. This is an error condition.) By providing spacial separation between tablets (e.g., tablets604,606,608,610), the overspeed condition is avoided and a more accurate count by first tablet counter15is produced.

According to a preferred aspect of system11′, logic of controller607can regulate motor635speed. In the example, controller607regulates motor635to provide six different RPM settings, from 1 to 6. Speed setting 1 is the highest RPM setting and speed setting 6 is the lowest RPM setting. Tablets which are harder can be fed from a cassette603at a relatively faster rate whereas tablets which are softer and may stick to the hopper757(e.g., gel caps) or which are more fragile and may break are preferably dispensed at a relatively slower rate. Speed setting 4 may be set as a default speed setting. The user can set a speed setting from one to six for each cassette603through touch screen display37as described below in connection with cassette-empty window901ofFIG. 66or cassette count window945ofFIG. 75.

Controller607sets motor635to the highest designated setting for the cassette603to commence feeding of tablets from the cassette603. As the count from second tablet counter615approaches the required count (point829,FIG. 52), controller607decreases motor635RPMs to a lower speed setting slowing rotation of rotor767and the rate at which tablets are fed from cassette603. This speed control feature avoids excessive rotation of rotor767as the required tablet count is approached, thereby avoiding the feeding of tablets in excess of the quantity required from cassette603and substantially preventing unwanted tablet overcounts by second tablet counter615.

Referring next toFIGS. 50-53B, there are shown block diagrams which illustrate the logical flow of information and logical decisions made within system11′ in order to count tablets with first and second tablet counters15,615and to compare the counts. The instructions which carry out such logical flow and decisions may reside in firmware or software without limitation, depending on the specific hardware which is utilized within an embodiment. In system11′, the instructions may reside in both forms within the various elements of system11′.

FIG. 50is a schematic block diagram showing system logical component interaction for the comparison of tablet counts as well as other elements of system control. First tablet counter15includes tablet counter controller311, instructions for which reside in firmware within controller311. Cassette dispenser601(indicated as “CD” inFIGS. 52 and 53B) includes second tablet counter615which in turn includes cassette dispenser controller607. Instructions for controller607reside in firmware within controller607. In the example of system11′, first tablet counter15and data processing platform17are within housing13, and second tablet counter615is associated with cassette dispenser601as represented by the dotted line boxes inFIG. 50.

Processing platform17includes software instructions which carry out the logical flow and decisions which utilize information and commands from both first tablet counter and second tablet counter15,615. The instructions enable counting with the first and second tablet counters15,615of the quantity of tablets required by the prescription being fulfilled. Information is passed bi-directionally between processing platform17and the first and second tablet counters15,615via two data connections802and649, respectively as represented by the dual-headed arrows inFIG. 50. Data connections802and649may be, for example, standard RS232 serial port connections.

Logical flow of information and logical decisions within system11′ occur in four cooperating portions, illustrated inFIGS. 51-53B.FIG. 51is a high-level logic flow diagram of first tablet counter controller311; the logic flow within controller311is indicated by reference number804.FIG. 52is a high-level logic flow diagram of cassette dispenser controller607; the logic flow within controller607is indicated by reference number816.

FIG. 53Ais a high-level logic flow diagram illustrating software operation for data handling and for displaying the tablet count of first tablet counter15; the logic flow within this portion of the instructions within data processing platform17is indicated by reference number832.FIG. 53Bis a high-level logic flow diagram illustrating software operation for data handling and for displaying the tablet count of second tablet counter615; the logic flow within this portion of the instructions within data processing platform17is indicated by reference number846.

The four logic flow portions804,816,832, and846are only partial representations of the logical operations which are performed within tablet counter controller311, cassette dispenser controller607, and data processing platform17. Many other specific functions may be included to enhance the performance of a product which includes the inventive system utilizing two tablet counters15,615but which are not essential to the cooperating operation of the two tablet counters15,615. The logical flow elements depicted in such four logic flow portions describe the flow of information and the logical decisions within system11′ necessary for such cooperating operation.

These four portions804,816,832,846of the logical flow of information and logical decisions within system11′ operate in parallel and cooperate together via firmware and software instructions and device connectivity, as follows. Referring first toFIG. 51illustrating logic flow portion804of tablet counter controller311, upon start-up (power-up or restart), controller311enters the logic flow at start-up block806and proceeds to initialize logic flow portion804at initialization block808. Initialization includes allowing controller311to establish normal operating voltage levels and resetting internal variables. Logic flow portion804then enters its main loop at block810. Logic flow portion804then sequentially loops through its main loop, the principal task of which is to update a status buffer812at block812. (In this description of logic flows, the reference number of a logic flow block may be used to refer both to the process occurring within the block as well as the variable, such as, in this case, a status buffer which is set by such process.)

During status buffer812updating, an actual tablet count814from a counter module814within controller311is passed to status buffer812. Thus, as the main loop within logic flow portion804of controller311continues to cycle, status buffer812maintains an up-to-date value for actual tablet count814of first tablet counter15. Tablet count814is sometimes referred to herein as the “host” count, indicating that such count is obtained from the first tablet counter15which is “hosting” the second tablet counter615.

In a similar fashion, cassette dispenser controller607of second tablet counter615, maintains an up-to-date value of its own tablet count. Referring toFIG. 52illustrating logic flow portion816of cassette dispenser controller607, upon start-up (power-up or restart), controller607enters the logic flow at start-up block818and proceeds to initialize logic flow portion816at initialization block820. As with controller311, initialization includes allowing controller607to establish normal operating voltage levels and to reset internal variables. Logic flow portion816then enters its own main loop at block822, the principal tasks of which are to receive and process requests and to update a status buffer828and block828. Controller607is configured to receive requests from data processing platform17at decision point824. Point824includes a logical decision to direct logic flow based on whether or not such a request has been received. Such requests include but are not limited to (1) a request from data processing platform17to simply acknowledge that the controller607is active, (2) a request to commence operation of cassette dispenser601to count a required amount of tablets needed to fulfill a prescription, (3) a status request, and (4) other requests such as cancelling, pausing, and resuming a fill request, and emptying a cassette.

If a request has been received at block824, all such requests are processed in block826(through a “YES” decision at point824) and involve the setting of a portion of a status buffer828at update status buffer block828. For example, if a prescription fulfillment request is received from data processing platform17and the proper cassette603is mounted to cassette dispenser601, processing of such prescription fulfillment request initiates operation of cassette dispenser601including starting motor635. If no request has been received at point824, request processing block826is bypassed through a “NO” decision at point824.

During status buffer828updating, an actual tablet count830from a counter module830within controller607is passed to status buffer828. This actual tablet count830is incremented when detector605detects a tablet fed from cassette603and detector receiver689sends a signal to controller607indicative of the tablet detection. Thus, as the main loop within logic flow portion816of controller607continues to cycle, status buffer828maintains an up-to-date value for the actual tablet count830of second tablet counter615and requests for fulfillment of a prescription are processed as they are received.

The main loop of logic flow portion816then continues with decision point829which determines if the actual tablet count830is approaching the required count. A predetermined value defines a difference between the actual and required tablet counts in order for the counts to be considered to be “close.” In system11′, this preset value is shown as 5 at decision point829ofFIG. 52, but other values may be used depending on a variety of parameters. At point829, if the actual count830approaches the required count such that the difference between the counts is four (4) or fewer, then a “YES” decision at point829is reached and logic flow portion816proceeds to slow cassette dispenser601motor635(slowing rotor767) in block835to facilitate accurate dispensing of tablets by cassette dispenser601.

If a “NO” decision is reached at decision point829, block835is bypassed and logic flow portion816continues with decision point831at which point the actual count830is compared with the required count to determine if counting is complete. If the actual count830equals the required count resulting in a “YES” decision at point831, then drive motor635is stopped, ceasing dispensing operation of cassette dispenser601. If the required count has not been reached, a “NO” decision is reached at decision point831and the main loop of logic flow portion816within controller607continues to its next cycle.

Logic flow portions832and846are programmed to operate in parallel within data processing platform17and are described inFIGS. 53A and 53B.FIG. 53Aillustrates logic flow portion832, the main tasks of which are to communicate with controller311of first tablet counter15in order to display and make available tablet count814from first tablet counter15. Logic flow portion832accomplishes these tasks by regularly reading status buffer812within its own main loop. Among other information, status buffer812contains tablet count814of first tablet counter15.

Upon start-up (power-up or restart) at start-up block834, logic flow portion832enters its main loop at block836. Logic flow portion832cycles through this main loop by sequentially reading status buffer812at block838, processing status flags at block840, displaying tablet count814on display37, and looping back through the main loop through a delay block844which can be set to slow the rate at which the main loop is cycled. Status flags include but are not limited to indication of the operation of the first tablet counter15and various error conditions which may exist.

FIG. 53Billustrates logic flow portion846operating in parallel with logic flow portion832within data processing platform17. Upon start-up (power-up or restart) at start-up block848, logic flow portion846sends a handshake request at block850to cassette dispenser601to determine whether cassette dispenser601is ready to operate. Decision point852determines whether or not a handshake response is received from dispenser601. A “NO” decision at point852displays an error message at block854and ends the logic flow accordingly. An error message could be displayed in Main Instructions field91,1091at block854. A “YES” decision at point852permits logic flow portion846to enter its own main loop at block856. The main loop of logic flow portion846cycles with the principal tasks of processing commands and making a determination whether or not the tablet count814from first tablet counter15and tablet count830from second tablet counter615are within a predetermined number of each other.

Upon entering the main loop of logic flow portion846, any command flags which are set at block860are processed in block858. Command flags include, but are not limited to, information related to a request to fulfill a prescription (e.g., prescription127) to be sent to cassette dispenser601and the other types of requests listed above which may be received by controller607.

In block862, logic flow portion846requests the status of second tablet counter615. If this request is not answered at decision point864, a “NO” decision triggers the display of an error message in Main Instructions Field91,1091on display37and ends the logic flow in block866. A “YES” decision at point864continues logic flow portion846to another decision point868which simply determines if counting is taking place by second tablet counter615. The status information obtained from the status request of block862contains, among other information, the actual tablet count830from second tablet counter615.

A “NO” decision at point868sends the logic flow through a delay block876which cycles the logic flow back to the entry block856of the main loop after a delay in block876to control the cycle time of the main loop of logic flow portion846. A “YES” decision at point868results in logic flow portion846obtaining tablet count814in block870.

At decision point872, a comparison is made between tablet count814from first tablet counter15and the actual tablet count830from second tablet counter device. The comparison determines if the cassette dispenser601actual count830exceeds the host tablet count814by more than a predetermined amount.FIG. 53Bshows a value of 10 for such predetermined amount, but other values for the predetermined amount may be used depending on the desired performance of system11′.

If the actual count830of the cassette dispenser601exceeds the host count814by more than 10 (a “YES” decision at point872), then a signal is generated by data processing platform17which stops the operation of cassette dispenser601at block874. The signal turns off motor635and displays a visual message to the user on display37. The signal-generated message alerts the user that an error condition exists and that corrective action should be taken. An error condition could exist, for example, if there is a tablet jam in funnel41′ such that tablets fed from cassette603and counted by second tablet counter615remain in funnel41′ and do not flow freely to first tablet counter15. The signal-generated visual message (e.g., “Count differential exceeded. Attention required.”) could be displayed in Main Instructions field91,1091on display37, shown inFIGS. 60 and 61.

A “NO” decision at decision point872allows the main loop to cycle through delay block876to control the rate at which logic flow portion846cycles.

Referring now toFIGS. 54A,54B,54C,54D, system11′ is capable of performing pharmacy workflow management in a manner similar to that described in connection with system11andFIGS. 14A,14B and14C in which tablets are manually poured into funnel41for counting by first tablet counter15, but with the enhanced capability of automatic cassette-based dispensing and dual counting provided by tablet counters15,615. Therefore, many of the processes performed in connection withFIGS. 14A-14Care performed in connection with the processes described in connection withFIGS. 54A-54Dand the related exemplary screen displays ofFIGS. 55-75and20-36. References to screen displays associated withFIGS. 14A-14Care made as appropriate to describe the workflow ofFIGS. 54A-54D.

The pharmacy workflow management executed by system11′ as shown in the examples ofFIGS. 54A-54Dand the screen displays ofFIGS. 55-75and20-36is enabled by a program of instructions (e.g., instructions according to the logic ofFIGS. 50-53B) residing in non-volatile data storage61of data processing platform17. When executed, the instructions enable system11′ to perform the pharmacy workflow management described herein. For interfaced systems11′, the instructions enable system11′ to receive prescriptions from PMS21. The prescriptions may be stored in prescription record database in non-volatile storage61. The instructions further enable a user to select one of the stored prescriptions for fulfillment and for the selected prescription to be retrieved. The instructions enable required medication to be counted and can create a record (e.g.,FIGS. 37A,37B, record70aor70b) that the quantity of the medication required by the retrieved prescription has been counted. For non-interfaced systems11′, the instructions enable counting and verification of prescriptions as described herein.

System11′ provides the user (e.g., a registered pharmacist, a pharmacy technician or other authorized person) with a powerful tool which enables control of pharmacy workflow directly from system11′ and fulfillment of one or more prescriptions of a prescription order by cassette dispensing or by manual pouring. System11′ enables counting of any tablet-form product including medications, nutriceuticals, and supplements and could be used for counting other discrete object types. System11′ can also manage workflow involving containers not requiring tablet counting, such as a medication-containing box174as will be described.

Referring toFIG. 54A, the operations for system11′ begin at block201when the user places an on/off switch59in the “on” position if system11′ is not already operating. In block203, data processing platform17is initialized and system11is placed in a ready state.

During initialization, a check is performed to determine whether system11′ is interfaced with PMS21. If an interface with PMS21does not exist, system11′ is operable as a stand-alone system. Prescription order fulfillment processing steps are described herein for both interfaced and non-interfaced systems11′. If an interface is present, all prescription orders which have been validated by PMS21are sent to system11′ via communication link23and are stored in prescription record database in files organized by prescription number in non-volatile data storage61awaiting fulfillment. Alternatively, validated prescription orders may be delivered to system11′ via batch data delivery as previously described.

In block205, a user is authenticated and logs into system11′. In the example, user authentication and login can occur in several ways. For example, a user can enter a user ID (name and password in the example) into system11′ by means of a QWERTY-type keypad65(e.g.,FIG. 70) displayed on touch-screen-type display37, by means of an external keyboard or mouse (not shown), or by means of biometric sensor55. The user ID is received by data processing platform17.

Biometric sensor55of system11′ is a fingerprint sensor as described with respect to system11. The user places his or her finger against the sensor55and, if the presented fingerprint matches a stored fingerprint, biometric sensor55communicates the user ID associated with the stored fingerprint to processing platform17. If the presented fingerprint fails to match a stored fingerprint, biometric sensor55communicates an error message to processing platform17.

If the user ID keyed in by the user or output from biometric sensor55to processing platform17is valid, processing platform17identifies the user and permits user login, enabling continued processing (blocks207and on). If the user ID is incorrect or if an error message is transmitted from biometric sensor55, then data processing platform17denies user access and the continued operations of blocks207and on are not performed. In this manner, only authenticated users can use system11for its intended purpose. Similar authentication operations may be performed for other biometric sensor types. Alternatively, user authentication can be accomplished by other known means, such as a smart card reader or an RFID reader.

For system11′, following successful login at block205, a Start screen73is shown on touch-screen-type display37as illustrated inFIG. 55. In the example, the Start screen73is preferably the same for both interfaced and non-interfaced systems11′.FIG. 56described below illustrates a Start screen1073which could appear for a non-interfaced system11′, indicative of the similarity between Start screens73,1073. As with system11, Start screen73of system11′ includes controls in the form of graphical user interfaces (GUIs) which permit the user to select from several processing options. Information-displaying fields are also provided. The controls and fields shown on Start screen73and on the further displays ofFIGS. 55-75and18-36are non-limiting examples provided for purposes of illustration only. It should further be recognized that the screen displays shown inFIGS. 55-75and18-36, and the sequence of the screen displays are illustrative and are not intended to be limiting.

In the example of system11′, Start screen73(FIG. 55) provides information indicating that four counting modes are available. The counting modes are: (1) a customer label scan/prescription selection counting mode (blocks209-253), (2) a scan override counting mode (blocks255-267), (3) a Universal Product Code (UPC) barcode scan counting mode (blocks269,271,273and257-267) and (4) a cassette count mode (blocks298-300and257-267). Each counting mode can be performed by either interfaced or non-interfaced systems11′ except that non-interfaced systems do not receive validated prescriptions orders directly from PMS21via link23or batch delivery. Each counting mode is described below.

Exemplary Start screen73of interfaced system11′ illustrated inFIG. 55shows exemplary fields and controls similar to those of Start screens73,1073illustrated inFIGS. 15 and 16but with a further prompt that the process may include cassette603usage. The fields and controls which are active on a particular screen correspond to the particular action then in process. Fields include: an Activity field75, a Medication Image field77, a Prescription Status Indicator field79, a Customer/Patient field81, a Prescription Number field83, a Medication Description field85, a Medication NDC field87, a Collated Prescription Status field89, a Main Instructions field91, a Tray Status field93and a Count Status field95. Start Screen73of interfaced system11′ differs from Start screens73,1073in that Count Status field95would include a cassette icon144if a cassette603is fully mounted on cassette dispenser601. Start screen Fields for the User Name94and Date and Time of Day96are also provided. In the example, the user name is shown as “Administrator” indicating that the logged-in user is also system Administrator. System11′ may be configured to display the user's given and surnames in field94, if desired.

Activity field75shows the current system11′ operation. Medication Image field77shows a graphic image of the color, shape, markings and form of the medication required by the prescription being fulfilled. Each image is retrieved from the medication image database based on the NDC number of the medication required by each prescription. Prescription Status Indicator field79indicates the status of the prescription in the workflow. Customer/Patient field81, Prescription Number field83, Medication Description field85and NDC field87, respectively, provide information about the patient name, prescription number, medication description and medication NDC for the selected prescription. Collated Prescription Status field89shows the status of all prescriptions grouped together for the patient and may include an image of each medication required by the prescription.

Main Instructions field91prompts the user to take an action. As shown on Start screen73ofFIG. 55, Main Instructions field91includes a prompt to scan a prescription label or a UPC barcode on a medication package to initiate one of the first two counting modes. Tray Status field93indicates whether a tray45is detected in bay47. Tray45is shown as detected in Start screen73because no “x” symbol is imposed over the tray icon. Vial size field92,1092indicates a recommended vial size suitable to hold the counted tablets. The recommended vial size may be based on the size of the tablets and count. Finally, Count Status field95indicates the quantity of tablets counted by first tablet counter15. Start screen73displays a 0 in Count Status field95indicating that no count has yet occurred.

Referring further toFIG. 55, controls include: a Count push button97, a New push button99, a Check push button101, a Held push button103, a Done push button105, a Help push button107, an INV push button109, an Errors push button111and a Logout push button113.

As illustrated, for example, inFIGS. 55 and 58additional control push buttons can include a Cancel Fill push button115, a Scan Override push button117and a Registered Cassette Query push button120(e.g.,FIGS. 60,62,64).

Selection of Count push button97clears the current screen for a new count while selection of New push button99causes system11′ to display any existing prescription orders in non-volatile data storage61that await selection for fulfillment (block213).

Selection of Check push button101causes system11to display any prescription orders that have been counted using system11, but which await final checking and verification by a registered pharmacist (blocks247-251).

Selection of Held push button103shows any prescriptions that have been placed on hold and have not been fulfilled. Prescriptions may be placed on hold, for example, if medication is not available to fulfill the prescription.

Selection of Done push button105causes system11′ to display any existing prescription orders that have been fulfilled using system11′. If an interface with PMS21is provided, prescriptions are preferably collated by patient for ease of review by the user.

Selection of Help push button107provides access to support, system setup and configuration details, user and medication database maintenance as well as technical resources. Selection of Help push button107also takes the user to a list of available reports which can be sorted by category and viewed on display37or printed with printer72. For example, the reports include a record (e.g., record70aor70bofFIGS. 37A,37B) of each prescription fulfilled by system11′.

Selection of Inv (inventory) push button109allows a user to perform inventory-related tasks.

Errors push button111appears if system11′ has determined that data received from PMS21cannot be processed. Selection of Errors push button111displays prescriptions flagged with the error so that the user can determine the source of the error and make appropriate corrections so that the prescription can be fulfilled using system11′. Errors push button111can appear for other reasons, such as if a barcode145falsely indicates that 0 tablets are required for a prescription.

Selection of Logout push button113permits the user to log off system11′.

Selection of the Cancel Fill push button115(e.g.,FIGS. 59,60) permits a user to interrupt any process at any time. The Cancel Fill push button115can be selected once a prescription is selected for processing, or counting has begun, or at any time the Cancel Fill button is visible. Interrupting a process may be useful if the user wishes to start over or stop use of system11′ to perform a task unrelated to system11′.

Scan Override push button117(e.g.,FIG. 55) permits a user to proceed directly to tablet counting without any preliminary processing steps (blocks255-267). For example, Scan Override117can be selected when only a tablet count is required as part of managing inventory by counting tablets in inventory.

Registered Cassette Query push button120(e.g.,FIGS. 60,62,64,67,71,73) is provided to query system11′ for identification of all cassettes603including a particular medication type. This push button120appears in the Medication Description field85next to the medication description. Registered Cassette Query push button116can be selected to display a window188(FIG. 63) showing all cassettes603registered as containing the type of medication described in Medication Description field85. This feature is useful to assist the user in selecting the required cassette603from a group of cassettes at a pharmacy.

Referring next toFIG. 56, Start screen1073which could appear on a non-interfaced system11′ is shown. Start screen1073includes information-providing fields and user-selectable control push buttons as described in connection with the like fields and controls of Start screen73. Fields include: an Activity field1075, a Medication Image field1077, a Prescription Status Indicator field1079, a Customer/Patient field1081, a Prescription Number field1083, a Medication Description field1085, a Medication NDC field1087, a Main Instructions field1091, a Tray Status field1093and a Count Status field1095. These fields are identical, respectively, to fields75,77,79,81,83,85,87,91,93,95described previously. Fields for the User Name1094and Date and Time of Day1096are provided. No Collated Prescription field89is required because the non-interfaced system11′ does not access PMS21to receive and manage collated prescriptions.

Control push buttons on Start screen1073include: a Count push button1097, a New push button1099, a Check push button1101, a Held push button1103, a Done push button1105, a Help push button1107, an Inv (inventory) push button1109and a Logout push button1113as described previously in connection with respective push buttons97,99,101,105,107,109,113. Additional control push buttons include a Cancel Fill push button1115(e.g.,FIGS. 21,23,25,27,59,61,65,72,74), a Registered Cassette Query push button1120(e.g.,FIGS. 61,65,72) and a Scan Override push button1117(e.g.,FIGS. 56,59). These controls function as described in connection controls115,117,120of interfaced system11′. A Hold1116and a Cancel Rx1118push button (e.g.,FIGS. 32,62) may be provided to place the prescription into a hold status for fulfillment at a future time or to terminate the prescription. If desired, a single prescription or even an entire prescription order can cancelled by pushing Cancel Rx button1118. This status will complete the processing for the prescription (e.g., prescription127) and require nothing further. Hold and Cancel Rx push buttons (identical to buttons1116,1118) may also be provided on displays for interfaced systems11.

While not shown in the non-interfaced screen displays (FIGS. 56,59,61,65,72,74), an Errors push button identical to Errors push button111and located in the same position as button111can appear. An Errors push button for a non-interfaced system could include information about a previous prescription which could not be completed, for example, if a barcode (e.g., barcode150,FIG. 13) was scanned requesting a count of 0 tablets. Selection of Errors push button displays prescriptions flagged with the error so that the user can determine the source of the error and make appropriate corrections so that the prescription can be fulfilled using system11′.

Referring again to the flow diagram ofFIG. 54A, the user determines the type of counting mode at point207. The process proceeds to enter decision point209if the user selects the customer label scan/selection via software counting mode, to entry block269if the user selects the medication container UPC barcode scan counting mode, to entry block255if the user selects the scan override counting mode or to entry block298if the user selects the cassette-count mode.

Referring toFIGS. 54A and 54B, exemplary steps of the customer label scan/selection via software counting mode are now described with respect to blocks/decision points209-253. At decision point209, the user selects a prescription by label scan selection or by selection via software.

If the prescription selection is via software, the user pushes New button99and enters block213which results in display of prescriptions which await fulfillment on New Order screen119illustrated inFIG. 57. The prescriptions received from PMS21are retrieved from the prescription record database residing in non-volatile data storage61.

New Order screen119ofFIG. 57contains fields which provide information for the user regarding each prescription and the prescription order. Fields include: a Patient Name field121, a Pharmacy-Assigned Patient Identification Code field123and a Delivery-Status field125indicative of whether the patient is waiting for the prescription or will pick up the prescription later.

New Order screen119ofFIG. 57also shows one or more prescriptions for each patient. The prescriptions are preferably collated by patient as illustrated inFIG. 57. Grouping together of pending prescriptions by patient makes it easier for the pharmacist or pharmacy technician to fulfill all prescriptions of all prescription orders pending for each patient. As illustrated inFIG. 57, three prescriptions127,129,131are shown for fictitious patient Pablo Martini. Each prescription127-131shown includes fields for the patient's name133, pharmacy-assigned prescription number135, medication name, strength and form information137, medication quantity139, medication image138and status as a new or previously-fulfilled prescription140. Collectively, prescriptions127-131may represent a single prescription order if placed for fulfillment together or may represent separate prescription orders if placed separately. Touching one of the up/down arrows141permits the user to scroll up or down to view pending prescriptions for patient Gelty and others.

New Order screen119for system11′ also contains a field of information142alerting the user that medication for a prescription (e.g., prescription127,129or131) is available from a cassette603. The availability of a cassette603containing the required tablets is represented by cassette icon144in field142. The user can select the identified cassette or select a container175(FIG. 12A) in order to fulfill the prescription.

InFIG. 57, new order screen119displays two cassette icons (each represented by144in field142). As illustrated inFIG. 57, the numbers “16” and “15” appearing with the cassette icons144are the unique identifier for each cassette603from cassette record database. Each cassette603is marked with the unique identifier in human-readable form to enable the user to select the correct cassette. Cassette record database in non-volatile memory61is programmed to associate the number of each cassette603with a particular tablet loaded in that cassette603during cassette603replenishment and registration as described below.

New Order screen119ofFIG. 57may also include some or all of the control push buttons97-113described above in connection with Start screen73. New Order screen119may also include User Name and Date/Time fields94,96or other information fields.

In block213ofFIG. 54A, a user may display New Order screen119and retrieve a prescription for fulfillment in subsequent block215. The user may select New push button99on any screen on which New push button99is displayed. This will call up the New Order screen119ofFIG. 57. The user may then touch one of the prescriptions to select a prescription for fulfillment at block215and trigger retrieval of the selected prescription from non-volatile storage61. The selected prescription is displayed in block218as described below.

Referring further to New Order screen119ofFIG. 57, an arrow177may appear on any screen pointing to one of the control push buttons97-113. A number in such arrow177is indicative of the number of prescriptions residing in each control category. For example, arrow177pointing to New push button99indicates that there are 30 new prescriptions awaiting fulfillment, and arrow177pointing to Errors push button111indicates that there are five prescriptions with errors that require attention. The number in each arrow177is incremented or decremented as new prescriptions are added or removed from each control push button category.

Therefore, New Order screen119of interfaced system11′ (FIG. 57) provides the user with a centralized point of control including user access to all information required to fulfill any pending validated prescription order. The user may scroll up or down using arrows141to access any of the pending validated prescription orders. Access to the entirety of the pending validated prescription orders through system11′ provides the user with an improved level of control over pharmacy workflow because, for example, the user may fulfill any prescription in any sequence that is most efficient and is no longer required to wait for physical delivery of prescription order paperwork (e.g. paperwork147) from pharmacy PMS21. For instance, the user can advance the order for fictitious patient Martini past an order for fictitious patient Gelty because patient Martini is indicated to be waiting for his order as indicated in field125, whereas patient Gelty will pick up his order at a later time as indicated in field125next to his order on New Order screen119.

As an alternative to prescription selection via software, the user may select the prescription by label scan at decision point209.

If system11′ is interfaced at point210, scanning of a prescription label143barcode145with scanner51at block212triggers prescription selection. Selection by scanning at block212triggers retrieval of the selected prescription and all other prescriptions collated for the patient from non-volatile storage61. In the label scan prescription selection mode, system11′ bypasses New Order screen119and proceeds directly to fulfillment of the selected prescription corresponding to the scanned label as illustrated in connection withFIG. 58.

If system11′ is not interfaced at point210, scanning of prescription paperwork barcode150with scanner51at block214triggers prescription selection. System11′ proceeds directly to fulfillment of the selected prescription corresponding to the scanned label as illustrated in connection withFIG. 59.

Exemplary label scan mode prescription selection for an interfaced system11′ is entered at steps209,210and212and operates in the following manner.

In the example, the label143which is scanned is part of the prescription order paperwork147. Label143is generated by PMS21as prescription order paper work147for each prescription for each patient. The user is provided with paperwork147for each prescription to be fulfilled with system11′. Prescription label143includes machine-readable indicia in the form of barcode145. Prescription label143of prescription order paperwork147is adhesive-backed and is peeled off paperwork147and applied to the patient prescription container (not shown) for the patient's prescription.

If system11′ is interfaced to PMS21, then barcode145need only include a prescription number149which matches the prescription number (e.g. prescription number 015644 in Field135) in the prescription record database in data storage61. The record of the prescription in the prescription record database will include the data expected to be embedded in the UPC barcode173or other container identification code of the container175(FIG. 12A) for the medication called for in each prescription being filled. The UPC barcode173or other expected container identification code may be provided by means of a relational database or other suitable database type, such as a hierarchical database.

Scanning of barcode145at block212retrieves the corresponding prescription from prescription record database in storage61and further results in retrieval of all other prescriptions for that patient so that all prescriptions for that patient are collated together and can be easily fulfilled by the user. Processing of the prescription corresponding to the scanned label is commenced immediately by system11′ as described below in connection withFIG. 58. At block218, the selected prescription is displayed to the user on display37as described in detail below.

System11′ can permit other information to be present on the prescription paperwork147. As described previously, this information can include: pharmacy identification information151, prescribing physician name153, patient name155, medication name157, NDC159, medication quantity161, prescription expiration date163, and prescription price165. Paperwork147may also include a receipt169with information corresponding to that of prescription label143.

Exemplary label scan mode prescription selection for a non-interfaced system11′ is entered at steps209,210and214and operates in the following manner.

In the example, the label which is scanned is the receipt portion169of prescription order paperwork147illustrated inFIG. 13. Receipt169includes a barcode150. Embedded in barcode150are three fields of information152shown next to barcode150including the 11-digit NDC used by the pharmacy (00002-3228-30), the pharmacy-assigned prescription number (015644) and the quantity of tablets required by the patient's prescription (0020).

For non-interfaced systems11, the NDC number in barcode150can be used with a commercially-available database provided in non-volatile storage61to look up UPC173(or other identification code) of container175in storage61for subsequent scan verification and can be used to retrieve a reference image of the medication from non-volatile storage61in Medication Image field1077as described herein. The database including the expected UPC173may be a relational database, or other suitable database type (i.e, a hierarchical database). As previously described, each NDC identifies the medication source, medication type and strength and package type and medication quantity. The relational database will include the specific UPC code173or other code on the container175for the medication identified by the NDC.

Also for non-interfaced systems11, the NDC number in barcode150can be used with cassette record database in non-volatile storage61to look up the cassette603identification code (which corresponds to the code embedded in barcode on cassette sidewall759) for the cassette603containing the required medication should the user prefer to dispense the medication from a cassette603rather than by manual pouring from a manufacturer's container175.

If barcode150on paperwork147receipt169is scanned, then the non-interfaced system11immediately begins to process that prescription (e.g., prescription127) resulting in selection of the prescription at block214and retrieval of the UPC173or cassette identification code (icons144,146,1146) and reference image information from non-volatile storage61.

Fulfillment of prescription127requiring 20 capsules of 25 mg Eli Lily & Co. Strattera medication for fictitious patient Pablo Martini is described below for both interfaced and non-interfaced systems11′. Fulfillment of prescriptions129,131for patient Martini would occur in the same manner, providing that medication is available in a cassette603.

Referring toFIG. 54A, block218is entered to display information relating to the selected prescription for both interfaced and non-interfaced systems11′.

If system11′ is interfaced, prescription selection via software at block215or by label scan at block212results in appearance of Prescription Filling screen179(FIG. 58) on display37and all relevant information pertaining to fulfillment of prescription127is presented to the user. Prescription Filling screen179illustrated inFIG. 58, Activity field75is set to “Filling” and Prescription Status Indicator field79is set to “Processing” to indicate that fulfillment of the prescription is in process. Patient name field81is set to show the patient name and the prescription number of the prescription being fulfilled is shown in field83. The prescribed medication image, medication name, strength and form and NDC number are set in respective fields77,85,87. All three prescriptions127,129,131are collated together in Collated Order field89with prescription127indicated as being in a “Processing” mode.

If the required medication is available in a cassette603or a container175, the user is able to choose whether to fulfill the prescription127from the cassette603or by manually pouring the medication through the system11′. For system11′, Main Instruction field91, prompts the user to select a cassette603or container175to fulfill the prescription. In the example, three cassettes603are designated as containing the required Strattera tablets (i.e., cassettes “16”, “91”, “106”), and the user is prompted to select any one of the three cassettes603.

If system11′ is non-interfaced, prescription selection by label scan at block214results in display of the selected prescription at block218. Entry of block218for non-interfaced system11′ by scanning barcode150during the label scan selection process block214causes Start screen1073(FIG. 56) to be replaced with Prescription Filling screen1179′ (FIG. 59). As illustrated inFIG. 59, Prescription Filling screen1179Activity field1075is set to “Filling” and Prescription Status Indicator field1079is set to “Processing” to indicate that fulfillment of the prescription is in process.

Because the patient name and prescription number are not known from scanning barcode150, patient name field1081and prescription number field are set to show the date and time of day. The medication image, medication name, strength and form and NDC number for the Strattera medication required by prescription127are again set in respective fields1077,1085,1087. This information is retrieved from a relational database corresponding to the NDC number in barcode150from non-volatile data storage61.

Also retrieved from the relational database is UPC barcode173expected to be on container175and the cassette identification code for the cassette603or cassettes containing the required medication as previously described. The expected UPC barcode and cassette identification code are related directly to the NDC number embedded in barcode150. Single prescription127being filled is shown with prescription127indicated as being in a processing mode in field1079.

If the required medication is available in a cassette603or a container175, the user is able to choose whether to fulfill the prescription127from the cassette603or by manually pouring the medication through the system11′. For non-interfaced system11′, Main Instruction field91, prompts the user to select a cassette603or container175to fulfill the prescription. In the example ofFIG. 59, one cassette603is designated as containing the required Strattera tablets (cassette “91”), and the user is prompted to select the designated cassette603.

Block219ofFIG. 54Ais entered next for both interfaced and non-interfaced systems11′. In block219, the user selects a cassette603or a container175containing tablet-form medication required by the prescription (e.g., prescription127).

If a cassette is selected at block219, the user mounts cassette603on cassette dispenser601. In the interfaced system11′ example ofFIG. 60, cassette603with cassette identification code “16” is selected by the user from a storage location (not shown) and is mounted on cassette mount621. In the non-interfaced system11′ example ofFIG. 61, cassette603with cassette identification code “91” is selected by the user from the storage location (not shown) and is mounted on cassette mount621. In the examples, cassette identification codes “16” and “91” are embedded in a respective barcode760.

At block221ofFIG. 54A, reader645reads the barcode760(FIG. 46A, barcode760location indicated inFIG. 46) on the mounted cassette603, and a signal corresponding to the cassette identification code is transmitted to data processing platform17via serial connection649. A cassette icon146,1146appears in Main Instructions field91,1091corresponding to the unique cassette identification number of mounted cassette603as detected by reader645. The cassette icon146,1146remains in Main Instructions field91,1091until the mounted cassette603is removed from cassette mount621as detected by opening of switch639.

At decision point223ofFIG. 54A, the signal including the actual cassette identification code is compared by the program of instructions operating on data processing platform17with the expected cassette identification code for the cassette603containing the required medication from the cassette record database in non-volatile data storage61. The purpose of the comparison is to confirm that the cassette603including the medication required by the prescription127is mounted on the cassette dispenser.

If the comparison at point223results in a match between the cassette identification code detected by reader645and expected cassette identification code, then system11′ immediately enters block225and commences tablet counting as described in connection with the Cassette Counting screen184ofFIG. 60(interfaced system11′) or1184ofFIG. 61(non-interfaced system11′) below.

If there is no match at point223, the process is as follows. For the interfaced system11′, if there is no match between the mounted cassette603and the expected cassette at point223, then Error screen182ofFIG. 62is presented to the user. In addition, speaker63may generate an audible signal indicating that the comparison did not result in a match. Instructions in Main Instructions field91indicate that an error (a cassette mismatch) has been detected to prompt the user at block219to select the correct cassette603(i.e., repeat block219) or to remove the cassette603and repeat the reading process of block221. In the example ofFIG. 62, cassette “15” was erroneously mounted to cassette mount621, and the user is prompted to select one of cassettes “16”, “91” or “106” as a substitute for cassette “15”. Cassettes “16”, “91” or “106” are registered in cassette record database as containing the required Strattera medication. Prescription Status Indicator field79remains set to “Processing,” and the word “Processing” also appears in Collated Order field89for prescription127because no match has occurred at point223.

For the non-interfaced system11′, an identical error message is displayed (not shown) prompting the user to select the a replacement cassette603(block219) for reading (block221) and to determine whether the expected cassette identification code of the replacement cassette603matches the actual cassette identification code read by reader645(point223).

Referring to FIGS.60and62-63, pressing of the Registered Cassette Query button120in the Medication Description field85brings up a Registered Cassette window186which informs the user of all cassettes603which include the medication described in the Medication Description Field85. The information in window186is useful to assist the user in selecting the correct loaded cassette603to fulfill the prescription. In the example, window186includes a field188showing that three cassettes (numbers “16”, “91” and “106”) are loaded with 25 mg strength capsule-form Strattera and are registered with system11′ as being “Ready” for use. Window186includes an Image field196providing an image of the Strattera medication, an NDC number field197providing the NDC number of the Strattera medication and a word description of the Strattera medication. A Stock Location field198may be provided to indicate the storage location of a container175of the Strattera medication for cassette603replenishment. Window186can be accessed by pressing Registered Cassette Query button120on any screen on which button120is displayed. An Exit push button199is provided to exit window186

For manual pour through of tablets from a container175with an interfaced system11′, the process is essentially identical to that described in connection with system11and results in verification that the correct container175has been selected to fulfill the prescription.

Block219ofFIG. 54Ais entered for both interfaced and non-interfaced systems11′. In block219, the user selects a medication container (e.g., container175) containing tablet-form medication required by the prescription (e.g., prescription127). Container175is retrieved from its storage location.

At block221ofFIG. 54A, the user scans the UPC barcode173on container175with barcode scanner51, and a signal corresponding to the actual UPC barcode173is transmitted to data processing platform17.

At decision point223ofFIG. 54A, the actual UPC barcode173on container175is compared by the program of instructions operating on data processing platform17with the expected UPC barcode for container175containing the required medication from the prescription record database in non-volatile data storage61.

Referring to FIGS.54A and20-21, if the comparison at point223results in a match between the actual UPC barcode173and the expected UPC, counting of tablets is enabled and Begin-Pouring screen181is shown on display37for an interfaced system11′ and or the Begin-Pouring screen1181ofFIG. 21is shown on display37for non-interfaced system11′.

For the interfaced system11′, if there is no match at point223, then Error screen182ofFIG. 22is presented to the user. In addition, speaker63may generate an audible signal indicating that the comparison did not result in a match. Instructions in Main Instructions field91indicate that an error (a cassette mismatch) has been detected to prompt the user at block219to re-scan UPC173(repeat block221) or to select a different container175(repeat block219). Prescription Status Indicator field79remains set to “Processing,” and the word “Processing” also appears in Collated Order field89for prescription127because no match has occurred at point223.

For the non-interfaced system11, if there is no match at point223, then Error screen1182ofFIG. 23is presented to the user. An audible error signal can be generated by speaker63. Instructions in Main Instructions field1091indicate that an error has been detected to prompt the user at block223to re-scan UPC173(repeat block221) or to select a different container175(repeat block219).

As with system11, other error types can occur during the fulfillment process and information can be displayed to alert the user to such errors. Examples of errors can include, for example, that the medication is not in the prescription record database in storage61, that data was erroneously entered for the prescription (for example erroneously indicating that zero tablets are required), that the UPC was not found in the relational database in storage61, or that the lengths of barcodes145and173do not match. These and other error conditions can trigger system11′ to display instructions in Main Instructions field91or1091, prompting the user to take appropriate corrective action.

At this point in the workflow for both cassette-based and manual pour-through counting, the medication has been selected and the source of the medication (cassette603or container175) has been verified. Counting occurs next at block225.

Tablet counting at block225is first described for cassette-based counting with reference toFIG. 54Aand block225. Cassette-based counting at block225is identical for interfaced and non-interfaced systems11′. Tablet counting begins immediately once a match is determined at point223resulting in display of Cassette Counting screen184ofFIG. 60(interfaced) or Cassette Counting screen1184ofFIG. 61(non-interfaced). Prescription Status Indicator fields79,1079ofFIGS. 60,61are set to “Verified” indicating to the user that cassette603matches the expected cassette containing the medication required by prescription127. Collated Order field89for interfaced system11′ is also set to “Verified” for prescription127also indicative of the match. (Collated Order field89is set to “New” for prescriptions129and131because fulfillment of these prescriptions has not yet commenced.)

Data processing platform17initiates operation of controller607. Controller607automatically activates motor635resulting in rotation of rotor767and feeding of tablets one after the other through opening781. Tablets604,606,608,610fall along path681and past detector605whereupon a signal is sent via receiver689to controller607indicative of tablet detection. Controller607increments a count for each detected tablet as previously described. In the example of prescription127, twenty counts would be expected corresponding to the quantity of tablets required to fill that prescription. Controller607stops motor635operation when the tablet count matches the required count. Controller607may slow motor635as the tablet count approaches the required count as previously described.

Tablets (e.g., tablet604) fed from cassette603fall past detector605and into funnel41′ and chute43. First tablet counter15automatically counts each tablet as it falls through funnel41′ and chute43past collimated IR sources308a,308band sensors307a,307band into tray45. The system software previously described performs the count, and Count Status fields95,1095of Cassette Counting screen184ofFIG. 60(interfaced) or Cassette Counting screen1184ofFIG. 61(non-interfaced) is instantaneously updated as each tablet is counted.FIGS. 60 and 61are “snapshots” representative of the appearance of display37at the point at which eight and seventeen tablets of the required twenty tablets have been counted by the respective interfaced and non-interfaced systems11′.

The tablet count from first tablet counter15is compared to the tablet count from the second tablet counter615during counting as previously described in connection withFIGS. 50-53Bto ensure that the counts are within a predetermined count of the other, thereby ensuring that the required tablets are being fed out from the cassette603.

Tablet counting at block225is next described for manual pour-through counting with reference toFIG. 54A. Manual pour-through counting is like that described above in connection withFIGS. 20-27. Manual pour-through counting from a container175at block225is identical for interfaced and non-interfaced systems11′. Cassette dispenser601is not required for manual pour-through counting. Cassette dispenser601could be utilized, however, to supply any required tablets not available from container175, for example if container175becomes empty before the required quantity of tablets are counted by counter15.

Referring to FIGS.54A and20-21, verification of the selected container175in block223causes the “Begin Pouring Now” message to be displayed, prompting the user to manually pour tablets into funnel41′ from container175. As illustrated inFIG. 20(interfaced system11) andFIG. 21(non-interfaced system11), Main Instructions fields91,1091of the Begin-Pouring screens prompt the user to begin pouring the tablets from a container (e.g., container175) into funnel41′ in response to the match in block223. Prescription Status Indicator fields79,1079are set to “Verified,” indicating to the user that UPC173of container175matches the medication required by the prescription. Collated Order field89is also set to “Verified” for prescription127, also indicative of the match. (Collated Order field89is set to “New” for prescriptions129and131because fulfillment of these prescriptions has not yet commenced.) Count Status field95,1095are set to 0, and the tablet quantity required by the prescription (e.g., prescription127) is displayed.

In the example ofFIGS. 38-49, the user pours tablet-form medication from container175into funnel41′. First tablet counter15automatically counts each tablet as it falls from funnel41′ past collimated IR sources308a,308band sensors307a,307band into tray45. The system software previously described performs the count, and Count Status fields95,1095are instantaneously updated as each tablet is counted.

Next, decision point227ofFIG. 54Bis entered and a determination is made with respect to whether the actual count equals the required count.

For cassette-based counting, the process moves toFIGS. 54B,64(interfaced system11′) or65(non-interfaced system11′) and decision point227. At point227, the actual tablet count made by first tablet counter15is compared to the required tablet count for the prescription. Tablets are fed from cassette603until the required quantity of tablets is counted by second counter615. Tablets fall from cassette603into funnel41′ and fall past first tablet counter15.

At point227, the actual tablet count made by first tablet counter15is compared to the required tablet count for the prescription. If the actual tablet count of first tablet counter15equals the required tablet count, then Count-Complete screen183ofFIG. 64(interfaced system11′) or Count-Complete screen1183ofFIG. 65(non-interfaced system11′) appears on display37.

As described in connection withFIGS. 50-53B, the actual tablet count made by both the first and second tablet counters15,615is compared during counting within data processing platform17to provide verification that all necessary tablets are fed from cassette603. Optionally, the total number of tablets counted by both the first and second tablet counters15,615can be compared to the required count for added assurance of accuracy. For example, the count of each counter15,615can be compared once the count of counter615equals the required count (20 counts in the example of prescription127). If the counts of counters15,615match, the process can move forward. If the counts of counters15,615do not match, an error message can be presented to user in the Main Instructions field91,1091ofFIGS. 60-61as described above. The error message would prompt the user to repeat the counting process or otherwise take corrective action.

Referring further toFIGS. 64 and 65, Prescription Status Indicator fields79,1079remain set to “Verified” providing continued indication to the user that correct cassette603or container175was selected. Main Instructions fields91,1091instruct the user that the count is complete and prompts the user to remove tray45so that the counted tablets can be poured from tray45into a vial, bottle or other container for the patient's prescription. Vial size field92,1092indicates a recommended vial size suitable to hold the counted tablets. Vial size “6” or “8” is recommended in the example. Vial size refers to the volumetric DRAM size in the example. Speaker63may generate an audible signal indicating that the correct count has been made.

For manual pour-through counting, the process also moves toFIGS. 54B,24and25and decision point227. At point227, the actual tablet count made by first tablet counter15is compared to the required tablet count for the prescription. Again, if the actual tablet count equals the required tablet count as determined by first tablet counter15, then Count-Complete screen183ofFIG. 24(interfaced system11′) or Count-Complete screen1183ofFIG. 25(non-interfaced system11′) is shown on display37. Prescription Status Indicator fields79,1079remain set to “Verified” providing continued indication to the user that correct cassette603or container175was selected. Main Instructions fields91,1091instruct the user that the count is complete and prompts the user to remove tray45so that the counted tablets can be poured from tray45into a vial, bottle or other container for the patient's prescription. Vial size field92,1092indicates a recommended vial size suitable to hold the counted tablets. Vial size “6” is recommended in the example ofFIGS. 24 and 25. Speaker63may generate an audible signal indicating that the correct count has been made.

For both cassette-based and manual pour-through counting, an undercount could occur at decision point231if the user removes tray45before the required quantity of tablets is counted. An undercount may also occur during manual pouring if too much time elapses, for example, because the count was not completed within a user-configurable time interval (such as 5 minutes). Such a time out could occur if, for example, a user were asked to assist with another task in the pharmacy before completing the count. An undercount message indicating the undercount is provided in Main Instructions field91,1091ofFIGS. 24,25,64,65. An audible signal generated by speaker63would also indicate an undercount condition to the user. If an undercount occurs at decision point231ofFIG. 54B, then additional tablets are poured from container175into funnel41until the actual count equals the required count at block233. The count is displayed in Count Status field95,1095.

For both cassette-based and manual pour-through counting, an overcount could occur at decision point235if too many tablets are counted by first tablet counter15. For example, two tablets could be ejected simultaneously from cassette603registering only a single count on second tablet counter615. In this situation, the overcount would be detected by first counter15avoiding a situation in which potentially costly medication is essentially “given away” free of charge to the patient. If there is an overcount at decision point235, then the user is notified of the overcount by a message in Main Instructions field91,1091ofFIGS. 24,25,64,65and an audible signal from speaker63. The user is prompted to manually adjust the count by removing tablets or to re-feed tablets from cassette603or to manually re-pour the tablets (e.g., from tray45) through first tablet counter15until the actual count equals the expected count as indicated in Count Status field95,1095.

If the tablets are poured too rapidly past first tablet counter15, then an overspeed error condition can occur (step517ofFIG. 11B) indicating that the tablets passing collimated IR sources308a,308band sensors307a,307bwere not accurately counted. If an overspeed error occurs, then the user is prompted by an audible signal from speaker63and an overspeed message (not shown) is presented on display37and the screens ofFIGS. 24,25,64,65. The user is prompted to re-pour the tablets through first tablet counter15until the actual count equals the expected count as indicated in Count Status field95,1095. A benefit of cassette-based tablet feeding is that overspeed conditions are avoided by tablet singulation.

For cassette-based counting, the process moves toFIG. 54Ddecision point275if cassette603runs out of tablets before the tablet count of first tablet counter15matches the required tablet count in decision block227. Decision point275is the entry step for cassette603replenishment or manual pouring of tablets from a container175to achieve the tablet count required for the prescription being fulfilled.

At decision point275, first tablet counter15has not counted the required tablets (e.g., tablet604) and has not made a count for a preset time. This condition is indicative of an empty cassette603or another error, such as tablets (e.g., tablets604,606) having become bridged or jammed in funnel41′. In a cassette-empty state, first and second tablet counters15,615have not counted the required quantity of tablets. In a jammed state, second tablet counter615has counted the required quantity of tablets while first tablet counter15has not counted the required quantity of tablets.

A tablet-jam state can exist if tablets have become jammed in funnel41′ or chute43and are not moving freely toward first tablet counter15. The count comparison at point872(FIG. 53B) would indicate that the counts of the first and second tablet counters15,615are not in agreement. If the cassette is not empty (i.e., second tablet counter615has counted the required tablet quantity) and there is a tablet jam, then block277is entered indicative that there is an error requiring user attention. An error prompt may appear in Main Instructions field91,1091screens ofFIGS. 64,65to alert the user. The user could manually clear any tablet jam and then complete the counting process.

Referring toFIGS. 54D and 66, if cassette603is empty as indicated by both the first and second tablet counters15,615not having counted the required quantity of tablets, then cassette-empty window901appears on display37at block279providing user options, including cassette603replenishment. Non-interfaced system11′ includes an identical Cassette-empty window901and user options. For convenience and brevity, the description of window901and related options for the interfaced system11are incorporated herein for the non-interfaced system11′. For both interfaced and non-interfaced systems11′, the empty cassette603is inactivated and cannot be utilized to dispense tablets until the cassette is refilled and registered to system11′. The empty cassette603can be inactivated simply by updating cassette record database in non-volatile data storage61to indicate that the code associated with the empty cassette603is not valid.

Referring toFIG. 66, window901of interfaced system11shows exemplary fields and controls. Fields include: a Medication Image field902, a Customer/Patient identification field903, a Prescription Number field904, a Medication NDC field905, a Medication Description field906, and a Cassette Status field907. Controls include: a Refill Cassette push button908, an Adjust Manually push button909, a Cancel Fill push button910, an Empty and Restart push button911, a Finish by Pouring push button912, a Retry Cassette push button913and a Partial Fill push button914.

In the example, information for prescription127for Strattera 25 mg strength capsules for fictitious patient Pablo Martini is displayed in respective fields901-907. Cassette Status field907indicates that cassette603is empty indicative that the actual tablet count counted by first tablet counter15did not reach the required count at point227before the cassette603became empty.

Selection of Refill Cassette push button908permits the user to refill cassette603as described below. Adjust Manually push button909permits the user to manually adjust motor635RPM output to adjust the rate at which tablets are fed from cassette603. This control is useful to avoid tablet jams within a cassette resulting in a false indication that the cassette is empty. Adjustment of motor635output has been found to be a way to improve movement of tablets out of a cassette603. Selection of button909permits the user to increase or, alternatively, decrease motor RPM output635.

Cancel Fill push button910permits the user to terminate the fulfilment process for prescription127. The prescription can be filled at any time in the future. The prescription is unaffected and stays unfilled. The prescription would be added to the queue of “held” prescriptions accessible by touching the Held push button103,1103. Empty and Restart push button911permits a user to reenter block218and to start over. Finish by Pouring push button912permits a user to manually pour the required tablets from a container175to complete the prescription and to enter block227. Retry Cassette push button913permits a user to start again from beginning, removing the tray and restarting the prescription counting from point209. Partial Fill push button914permits a user to accept the counted tablets as partial fulfillment of the prescription and to finish counting manually. The counting process is terminated and it is assumed the operator will manually deliver the prescribed quantity.

Referring next toFIG. 67, Finish by Pouring screen915appears on display37responsive to selection of push button912. Instructions in Main Instructions field91prompt the user to scan the UPC barcode173of container175for the Strattera 25 mg tablets. If the information embedded in the UPC barcode173matches the expected UPC in database of non-volatile memory61, the user is prompted to pour the tablets needed so that the actual count equals the required count at point227. In the example, six of twenty tablets have been counted by first tablet counter15and twelve additional tablets must be poured from container175to fill prescription127. Cassette icon144indicates that the cassette603from which the six tablets had been counted is now empty. The process moves to block229once the required tablets are poured from container175.

Referring next toFIGS. 54D,68,69and70, a cassette refill process is initiated at block281by selecting Refill Cassette push button908opening Refill window916(FIG. 68). At this point in the exemplary workflow, system11′ is in the process of filling prescription127with Strattera 25 mg strength capsules. Information for refilling cassette603number “91” with Strattera 25 mg strength capsules required to complete prescription127for fictitious patient Pablo Martini appears on Refill window916. Refilling of other cassettes603occurs in the same manner.

Referring toFIG. 68, Refill window916of interfaced system11′ shows exemplary fields and controls. Fields include: a Medication Image field917, a Medication Description field918, a Medication NDC field919, a Refill Count field920and an Instructions field921. Controls include: a Lot Number push button922, an Expiration Date push button923, a keypad924, a Cancel push button925and an Ok push button926. As illustrated inFIG. 68, fields917,918and919show information to assist the user with correctly identifying the Strattera 25 mg capsules to be loaded into cassette603number “91.” The expiration date and lot number information in Medication Description field918awaits updating. Expiration date refers to the date by which the tablets should no longer be taken by a patient, and the lot number refers to the manufacturer's lot number which is used to track medication, for example for purposes of product recalls.

Referring further toFIG. 68, Instructions field921prompts the user to “Scan the Stock Bottle UPC for Verification.” At block283ofFIG. 54D, the user selects a container175with a UPC barcode173. Preferably, container175should hold a sufficient quantity of medication to fully reload cassette603.

At block285, the user scans the UPC barcode173on container175with barcode scanner51. At decision point287, the actual UPC barcode173on container175is compared by the program of instructions operating on data processing platform17with the expected UPC for the container175from the cassette record database in non-volatile data storage61. If the comparison at point287results in a match, refilling of cassette603number “91” is enabled. If the comparison at point287does not result in a match, an error message (not shown) in Instructions field921prompts the user to select a different container and to scan the UPC of the different container. The scan process of block285is repeated until a match is reached at point287.

After a match at point287, the user can enter the total number of tablets in the container175using key pad924(FIG. 68) at block289. Alternatively, the container175contents could be poured into funnel41′ and counted by first tablet counter15. The total count is then keyed into system11′ using keypad924at block289. Cassette record database in non-volatile data storage61is updated with the count for the cassette603. The user then selects the Ok push button926to complete block289.

Continuing with the cassette refill process and referring further toFIGS. 54Dand69, Expiration Date window927appears next on display37, permitting the user to update cassette record database in non-volatile data storage61with the expiration date for the tablets loaded in cassette603at block291. Expiration Date window927of interfaced system11′ shows exemplary fields and controls. Fields include: a Medication Image field928, a Medication Description field929, a Medication NDC field930, an Expiration Date Instructions field931and an Expiration Date Data Entry field932. Controls include: a keypad933, a Cancel push button934and an Ok push button935. As illustrated inFIG. 69, fields928,929and930show information to assist the user with correctly identifying the Strattera 25 mg capsules to be loaded into cassette603number “91.” At block291, the user enters the month, date and year of the expiration date provided on the stock bottle. This information appears in the Expiration Date Data Entry field932. The user then selects the Ok push button935to complete block291.

Continuing still further with the cassette refill process and referring toFIGS. 54D and 70, Lot Number window936appears next on display37permitting the user to update cassette record database in non-volatile data storage61with the lot number for the tablets loaded in cassette603at block293. Lot Number window936of interfaced system11′ shows exemplary fields and controls. Fields include: a Medication Image field937, a Medication Description field938, a Medication NDC field939, an Instructions field940and a Lot Number Data Entry field941. Controls include: a QWERTY keypad65, a Cancel push button943and an Ok push button944. As illustrated inFIG. 70, fields937,938and939show information to assist the user with correctly identifying the Strattera 25 mg capsules to be loaded into cassette603number “91.” At block293, the user enters the lot number provided on the container175using keypad65or by scanning the lot number from a barcode173on the container175with barcode scanner51. This lot number information appears in Lot Number Data Entry field941. The user then selects the Ok push button944to complete block293.

At block295, the refilled cassette603and its contents are verified by a registered pharmacist. In the example, the refilled cassette603is optionally examined by the registered pharmacist to confirm that the cassette603contents match the image and description in the Medication Image field937and Medication Description field938. If there is match, the refilled cassette603is deemed verified as containing the correct medication. Such optional verification is not mandatory because of the match at point287.

The cassette refill process is completed atFIG. 54Dblock297when the cassette record database in non-volatile data storage61is automatically updated with the quantity, expiration date and lot number for the tablets loaded in verified cassette603. Cassette603number “16” is registered and ready for use. System11′ automatically operates the refilled cassette603when mounted on cassette dispenser601and the workflow re-enters point227until the actual count matches the required count.

The result of blocks225,227,233,237and297ofFIGS. 54A,54B and54D is that the correct quantity of tablets has been counted and the counted tablets are in tray45.

For both cassette-based and manual pour-through counting, the counted tablets are next removed from tray45. Referring toFIGS. 54B,26-27(manual pour through) and71-72(cassette dispensing), at block229tray45is removed and the tablets in tray45are poured into a patient medication container, such as a bottle or vial (not shown).

For cassette-based counting, removal of tray45triggers display of Filled screen185ofFIG. 71(interfaced system11′), or Filled screen1185ofFIG. 72(non-interfaced system). For manual pour-through counting, removal of tray45triggers display of Filled screen185ofFIG. 26(interfaced system11′) or Filled screen1185ofFIG. 27(non-interfaced system11′), indicating that the prescription status is considered to be “Filled” as indicated in field79,1079.

For both cassette-based and manual pour-through counting, Tray Status field93,1093ofFIGS. 26-27(manual pour through) and71-72(cassette dispensing), includes an “x” symbol indicating removal of tray45. For interfaced system11′, prescription127in Collated Order field89of Filled screen185(FIGS. 26,71) changes to “Filled” indicating that the required tablets were counted and removed from the system11′. For interfaced systems, prescription orders129,131await fulfillment as indicated by the two occurrences of the word “New” in Collated Order field89.

For both cassette-based and manual pour-through counting, tray45is returned to bay47at block239ofFIG. 54B. Return of tray45to bay47is detected by system11′ and represents the terminal point of the filling process for that prescription.FIGS. 73 and 74respectively show Filled screens185,1185for interfaced and non-interfaced systems11′ after cassette603dispensing once tray145is returned to bay47. The “x” symbol is no longer present indicative that tray45is fully seated in bay47.

If system11′ is interfaced to PMS21, then at decision point241, system11determines whether additional prescriptions must be filled for the patient (e.g., prescriptions129,131). If so, the process of steps209-241(FIGS. 54A,54B) are repeated resulting in all prescriptions for the patient being filled.

If system11′ is non-interfaced, the user may move to the optional verification process enabled at decision point243and executed in blocks247-249. If verification is not selected at point243, then the process is “Done” at block245.

For both cassette-based and manual pour-through counting, optional verification can occur next if verification is enabled at point243. In the example, verification is identical for both cassette counting and manual pour-through counting. Accordingly, reference is made toFIGS. 28-35for the description of verification and prescription order completion. Verification by a registered pharmacist using system11′ is useful to provide further assurance that the prescriptions (e.g., prescriptions127-131) were filled accurately before the prescription order is made available to the patient. Verification can be performed as each prescription (e.g., prescriptions127-131) is fulfilled or after all prescriptions of a prescription order are fulfilled. Once all prescriptions are optionally verified, the prescription order is confirmed as “Done” in block253.

As illustrated, for example, in the interfaced system11′ screen display ofFIGS. 28-31, verification is made easier and more efficient because interfaced system11′ can present all prescriptions to be verified collated by patient in Collated Order field89(e.g.,FIGS. 24,29-31). The pharmacist or other user is able to quickly and easily access all prescriptions for any patient in order to complete the verification process. Patient care is improved because order verification is made more accurate, and the chance that a patient might accidentally not receive all required prescriptions is diminished.

Referring toFIG. 54B, blocks247and249illustrate steps of an optional verification process. Verification is available once tray45is inserted into bay47, and verification is enabled at point243. Verification is preferably enabled by the administrator of system11′ as a user-configurable option.

For both cassette-based and manual pour-through counting, two alternative processes are available to perform optional prescription verification in blocks247and249for interfaced systems11′. Verification may be controlled by means of a fingerprint scan process or by a barcode scan process.FIGS. 28 and 29illustrate exemplary screen displays for a fingerprint-controlled verification process for interfaced system11′ andFIGS. 30 and 31illustrate exemplary screen displays for a barcode scan-controlled verification process for an interfaced system11′. Enablement of verification at point243and selection of the type of scan may be based on preferences selected by the user, for example, in a system setup procedure executed after login at block205(FIG. 54A). For each of the examples ofFIGS. 28-31, the verification process is being performed for prescription127and before fulfillment of prescriptions129,131as indicated by the word “New” in Collated Order field89for prescriptions129,131of interfaced system11′.

Referring toFIGS. 28 and 29, for the fingerprint-controlled scan verification process, the user scans label barcode145which has been applied to the patient medication container or touches display37proximate displayed prescription127(e.g. prescriptions127-131). Block247is entered and Verification screen187a(FIG. 28) is shown on display37. Prescription Status Indicator field79remains set to “Filled” indicating to the user that the prescription has been fulfilled. Main Instructions field91prompts the user to begin the optional verification process. The medication image is displayed in field77. The user manually checks the information on screen187aagainst the physical appearance of the tablets in the patient's container and against the information provided on prescription order paperwork147.

If the correct medication has been loaded in the patient container, then in block249(FIG. 54B), the user places a finger against biometric sensor55to confirm the verification to interfaced system11′. Check Completed screen189a(FIG. 29) appears on display37for interfaced systems, and a check mark appears for the verified prescription127in Collated Order field89. Activity field75is set to “Checking” indicating that verification is being performed and Prescription Status Indicator field79is set to “Checked” indicating that the prescription has been checked and verified as indicated by placement of the user's finger on sensor55. Main Instructions field91is set to “Check Completed” also indicative of completed verification for prescription127.

Referring now toFIGS. 54B,30and31, the process for barcode-scan-controlled verification at blocks247,249is essentially the same as described for the fingerprint-controlled process. Block247is entered and Verification screen187b(FIG. 30) is shown on display37. Prescription Status Indicator field79remains set to “Filled” indicating to the user that the prescription has been fulfilled. Main Instructions field91prompts the user to scan label barcode145. At block247, the user then scans selected label barcode145of the prescription to initiate verification.

The user then manually checks the information on screen187bagainst the physical appearance of the tablets in the patient's container and against the information provided on prescription order paperwork147.

If the correct medication has been loaded in the patient's container, then at block249, the user scans label barcode145of the prescription for a second time to confirm the verification. Check Completed screen189b(FIG. 31) appears on display37for interfaced systems11, and a check mark appears for verified prescription127in Collated Order field89. The Activity field75is set to “Checking,” indicating that verification is being performed and Prescription Status Indicator field79is set to “Checked,” indicating that the prescription has been checked and verified as indicated by placement of the user's finger on sensor55. Main Instructions field91is set to “Check Completed” also indicative of completed verification for prescription127.

Referring toFIGS. 54B,32and33, verification for non-interfaced systems11′ at blocks247,249is much the same as previously described for interfaced system11′, except that the user has the option of verifying only the single prescription being fulfilled. The user has the ability to control verification by fingerprint or by scanning as described above for interfaced system11′, and such description is incorporated herein by reference. For simplicity and brevity, fingerprint-controlled verification is described herein, it being understood that barcode-controlled verification merely substitutes barcode scanning for placement of a finger on biometric sensor55.

Turning then toFIGS. 32 and 33, Verification screen1187(FIG. 32) appears on display37for fingerprint-controlled verification on non-interfaced system11′ for both cassette dispensing and manual pouring when the pharmacist or other user scans barcode150on paperwork147to initiate verification. The user then manually checks the information on screen1187against the physical appearance of the tablets in the patient's container and against the information provided on prescription order paperwork147. Based on the NDC in barcode150, the medication image is retrieved from the medication image database in storage61and displayed in field1077.

If the correct medication has been loaded in the patient container as determined at block249(FIG. 54B), the user places a finger against biometric sensor55to confirm the verification. Check Completed screen1189(FIG. 33) appears on display37for the non-interfaced system11. Prescription127for non-interfaced system11is now complete as indicated by Prescription Status Indicator field1079being set to “Complete” and the Main Instructions field1091being set to “Check Completed!.” Vial Size field1092is set to display the message “Order Complete” also indicating that the prescription has been verified.

Referring again to the interfaced system11′ andFIGS. 54B and 34, at decision point251it is determined whether all prescriptions (e.g., prescriptions127-131) for the patient have been filled and verified. If all prescriptions have been verified, Order Complete screen191illustrated inFIG. 34is shown on display37. Prescription Status Indicator field79is set to “Complete”, and Main Instructions field91is set to “Check Completed” indicating that the verification of all the collated prescriptions127,129,131has been completed. All prescriptions127-131are indicated as verified by the double check marks and setting of the word “Complete” in Collated Order field89.

The prescription order including all prescriptions127-131for fictitious patient Pablo Martini is now fulfilled and the order status is set to Done in block253.

Records of the prescriptions127-131fulfilled by system11′ may be created as described and illustrated in connection with system11.

For non-interfaced system11′, a record70aindicating that single prescription127has been fulfilled and verified is stored in the prescription record database of non-volatile data storage61as represented schematically inFIG. 37A. The record70acorresponding to prescription127includes the prescription number, NDC, medication name, medication quantity, date and time the medication was counted and the date and time that the prescription was verified. This information allows the pharmacy to reconstruct fulfilment of the prescription127. The record for prescription127includes all of the information shown on Check Completed screen1189ofFIG. 33. And, the record for the non-interfaced system11′ could include a collation of all prescriptions fulfilled for patient Pablo Martini, including prescriptions129and131once those prescriptions129,131are verified. For the non-interfaced system11′, the status of the prescription127is set as Done in block253.

Referring now toFIGS. 35 and 37B, interfaced system11′ creates record70bof each prescription filled collated by patient.FIG. 35illustrates a Completed Order Record screen193generated by interfaced system11′ for fictitious patient Pablo Martini after each of prescriptions127,129,131is fulfilled and verified. All prescriptions127-131are collated by the patient's name for convenience. Activity field75and Prescription Status Indicator field79are set to “Completed” and “Complete” indicating that the prescriptions127-131are complete and have been verified. The double check marks and word “Complete” for each prescription127-131in Collated Order field89is further indicating that the three prescriptions in the example have been completed and verified. Main Instructions field91informs the user that the system11′ is ready to begin a new counting process indicated by the text “Scan Next Rx.”

Referring toFIG. 37B, the information shown on Completed Order Screen193is maintained in prescription record database stored in non-volatile data storage61as record70bthat the prescriptions (e.g., prescriptions127-131) of the prescription order were fulfilled and verified. Record70bincludes all prescriptions127-131collated for patient Pablo Martini.

Record70b(FIG. 37B) and display of Completed Order Record screen193(FIG. 35) can be called by selecting Done push button105and then selecting the patient's name from the universe of patient names within system11′ data storage61. A user may want to access Completed Order Record screen193to further verify each prescription fulfilled using system11′.

System11′ may include a scan override mode which is identical to scan override mode of system11. The scan override mode of tablet counting may be entered at entry block255(FIG. 54A) by selecting Scan Override push button117, for example on Start screen73(FIG. 55). In the scan override mode, system11′ is set to count tablets without regard to any particular prescription. Scan override would be desirable, for example, to count tablets for a patient prescription order, to count tablets as part of an inventory procedure, or to confirm that a hand count of tablets was accurate. Scan override mode is also useful for counting non-prescription objects such as vitamins, nutriceuticals, supplements, jewelry, parts or other countable things.

Once scan override is entered (entry block255), the user manually pours tablets into funnel41′ for counting by first tablet counter15. The count from first tablet counter instantaneously appears on display37.

At decision point259(FIG. 54C), it is determined whether the user has enabled optional verification. If verification is not enabled, the prescription is considered to be done at block261.

If verification is enabled at decision point259, the process moves to block263to initiate verification. The verification process is the same as described in connection with blocks247and249. If verification is enabled at decision point259, the user scans label143barcode145to initiate verification in block263. The user then manually checks the prescription to confirm that the prescription was filled correctly. If the correct medication has been loaded in the patient container, then at block265, the user places a finger against biometric sensor55or scans label barcode145(or barcode150) of the prescription for a second time to confirm the verification. The order status is set to done at block267. A record (e.g., record70aofFIG. 37A) of the completed order is stored in prescription record database in non-volatile data storage61.

Referring again toFIGS. 54A and 54Cand toFIG. 36, the optional UPC scan mode of tablet counting may be entered at entry block269. UPC scan mode is provided for pouring from a container, such as container175, which includes a UPC-type barcode173. As previously stated, it is envisioned that codes other than UPC codes may be used with containers175in the future, and system11′ can be adapted to operate with such codes.

In block271, container175including UPC barcode173is selected. In block273, UPC barcode173is scanned with scanner51. Scanning of UPC barcode173as the first step of the process initiates the UPC scan mode. Scanning of UPC173causes a UPC Start screen195to appear on display37as illustrated inFIG. 36. UPC scan mode Start screen195is for interfaced system11′. All of the fields and controls described in connection with Start screen73(FIG. 55) are provided, and the description of such fields and controls is incorporated by reference herein.

Fields illustrated on Start screen195(FIG. 36) include: an Activity field75, a Medication Image field77and a Prescription Status Indicator field79. Since no patient or prescription information is known for a UPC scan mode count, Customer/Patient field81and Prescription Number field83show the date and time of day of the UPC scan count. Other fields are a Medication Description field85, a Medication NDC field87, a Main Instructions field91, a Vial Size field92, a Tray Status field93and a Count Status field95. Fields for the User Name94and Date and Time of Day96are provided. No Collated Prescription field is required because the UPC scan mode is based on a count of a single medication and is not tied to a specific prescription.

Control push buttons on Start screen195(FIG. 36) include: a Count push button97, a New push button99, a Check push button101, a Held push button103, a Done push button105, a Help push button107, a Rpts (reports) push button109, an Errors push button111and a Logout push button113. Additional control push buttons can include a Cancel Fill push button115and a Scan Override push button117. These controls function as described in connection with screen73. Hold and Cancel Rx push buttons (not shown) may also be provided on display37for the purpose described in connection with Hold and Cancel Rx push buttons1116,1118.

In block257the tablets are counted by first tablet counter15. Once again, in the examples ofFIGS. 38-49, this is accomplished by pouring the tablets from container175into feeder device19through funnel41′. Blocks259,261,263,265and267described in connection with scan override counting mode are repeated for the UPC counting mode providing the opportunity for the user to verify and check the prescription for accuracy. The order status is set to Done at block267if verification is enabled. A record such as record70a(FIG. 37A) of the completed order is stored in prescription record database in non-volatile data storage61.

Referring now toFIG. 54Cand toFIG. 75, the optional cassette count mode of tablet counting may be entered at entry block298. The cassette count mode of tablet counting is provided for feeding tablets from a cassette603to fill a prescription or for another purpose such as unit-of-use container filling, inventory counting, or verification of a hand count. In the example, the cassette count mode of tablet counting is identical for both interfaced and non-interfaced systems11′.

In block298, selection and mounting of a cassette603on cassette mount621of cassette dispenser601without first scanning a label barcode (e.g., barcodes143,150) or making a prescription selection via software (FIG. 54Apoint209) brings up Cassette Count screen945. Cassette Count screen945appears when switch639is closed by action of cam765against switch arm641and optical reading of the cassette identification barcode760by reader645in block299. Also in block299, the software of data processing platform17will look up this unique cassette identification number in the cassette record database residing in non-volatile storage61. Cassette Count screen945appears on display37if the cassette identification number is found in the cassette record database.

Referring toFIG. 75, Cassette Count screen945of interfaced and non-interfaced systems11′ shows exemplary fields and controls. All of the fields and controls described in connection with Start screen73(FIG. 55) are provided, and the description of such fields and controls is incorporated by reference herein.

Fields illustrated on Cassette Count screen945(FIG. 75) include: an Activity field75and a Medication Image field77. Since no patient or prescription information is known for a Cassette Count mode count, no information is shown in the Prescription Status Indicator field79Customer/Patient field81and Prescription Number field83. Other fields are a Medication Description field85, a Medication NDC field87for medication contained in the cassette603, a Main Instructions field91, a Tray Status field93and a Count Status field95. Fields for the User Name94and Date and Time of Day96are provided. A Count Data Entry field946and a Count Number Data Entry field947. No Collated Prescription field is required because the cassette count mode is based on a count of a single medication and is not tied to a specific prescription.

Control push buttons on Cassette Count screen945(FIG. 75) include: a Count push button97, a New push button99, a Check push button101, a Held push button103, a Done push button105, a Help push button107, an Inv push button109and a Logout push button113. Additional control push buttons can include a Cassette Query push button120and a Scan Override push button117. These controls function as described previously.

An Errors push button identical to Errors push button111inFIG. 55and located in the same position as button111can appear. An Errors push button could include information about a previous prescription which could not be completed as previously described. Selection of Errors push button displays prescriptions flagged with the error so that the user can determine the source of the error and make appropriate corrections so that the prescription can be fulfilled using system11′.

Other controls include: a numeric keypad948(including backspace button), a Deactivate push button949, a Remove push button950, a Count push button951, a Stock Check push button952, a Refill push button953, a Speed push button954and an Exit push button955. As illustrated inFIG. 75, fields77,85and87show information to assist the user with correctly identifying the Strattera 25 mg capsules to be counted from cassette603number “91” in the exemplary cassette count mode.

Keypad948(numbers and backspace keys) allow user entry of the number of tablets required and the number of count cycles required. The user first touches the Count Data Entry field946and then touches the numbers of keypad948to achieve the desired quantity. This process is repeated for Count Number Data Entry field947.

Deactivate push button949is provided for use by authorized personnel responsible for operation of system11′. Selection of deactivate push button949activates or deactivates the mounted cassette603allowing or disallowing use of the cassette603. Remove push button950enables a user to associate or disassociate a medication with a cassette603.

Selection of Count push button951initiates counting by cassette dispenser615. Selection of Stock Check push button952begins emptying the cassette603counting the tablets to report how many were in the cassette603. Selection of Refill push button953initiates a cassette refill process and brings up Refill Cassette window616(FIG. 68). Selection of Speed push button954enables the user to adjust the RPMs of motor635to improve movement of tablets (i.e., tablets604,606) from cassette603. In the example, from one to six motor635speed settings are available. Selection of Exit push button955exits the Cassette Count screen945so that the user can enter a different count mode at step207(FIG. 54A).

At block300, the user touches field946and uses keypad948to enter the quantity of tablets to count from cassette603and the quantity appears in Count Data Entry field946. Also in block300, the user touches field948and uses keypad948to enter the number of counts of this quantity which are desired and this information appears in Count Number Data Entry field947. These settings are desirable when repetitively filling unit-of-use containers which include, for example, a 30, 60 or 90-day allotment of tablets. Such unit-of-use containers are routinely required for frequently-used medications. Any number of unit-of-use containers are loaded and then the containers are stocked at an accessible location, such as a “speed shelf,” enabling rapid access to the containers by pharmacy personnel to fill patient prescriptions.

If cassette603has not yet been associated with a medication and is not registered as active to system11′, the operator is notified by a message in Main Instructions field91. A cassette603may not be recognized, for example, if the cassette603has not been used previously with system11′. If the cassette is not registered, push button949changes to “Activate” and push button950changes to “Add.” If the user is authorized, the user can register the cassette603with the medication by pushing button949and following the refill process described previously. The cassette603code760is identified by data processing platform and the user will be required to confirm that this code is to be associated with a particular medication. Button950, which states “Add” is pushed to confirm that the now-registered cassette603should be added to inventory of available cassettes and the cassette record database in non-volatile storage61is updated accordingly. If the user is not authorized to register the cassette603, the user is denied the ability to count using the cassette603.

Tablet counting begins immediately once the user selects the Count push button951. Controller607automatically activates motor635resulting in rotation of rotor767and feeding of tablets one after the other through opening781. Tablets604,606,608,610fall along path681and past detector605whereupon a signal is sent via receiver689to controller607indicative of tablet detection. Controller607increments an actual count830for each detected tablet as previously described. Controller607stops motor635operation when the actual tablet count matches the required count entered by the user in field946. Controller607may slow motor635as the tablet count approaches the required count as previously described.

Tablets (e.g., tablet604) fed from cassette603fall past detector605and into funnel41′ and chute43. First tablet counter15automatically counts each tablet as it falls through funnel41′ and chute43past collimated IR sources308a,308band sensors307a,307band into tray45. The system software previously described performs the count, and Count Status fields95,1095of Cassette Count screen945ofFIG. 75is instantaneously updated as each tablet is counted.

The tablet count from first tablet counter15is compared to the tablet count from the second tablet counter615during counting as previously described in connection withFIGS. 50-53Bto ensure that the counts are within a predetermined number of the other, thereby ensuring that the required tablets are being fed out from the cassette603.

Tray45is removed and the tablets in tray are poured into a unit-of-use container or other suitable container.

If multiple cassette count cycles are selected as indicated by Count Number Data Entry field947, then insertion of tray45back into tray bay47is detected by system11′ and such detection triggers system11′ to immediately commence counting of the requested tablets. This process of counting, emptying tray45and replacing tray45in tray bay47is repeated until the requested number of cassette count cycles have been completed.

Blocks259,261,263,265and267described in connection with scan override counting mode are repeated for the cassette counting mode providing the opportunity for the user to verify and check the counted tablets for accuracy. The count status is set to Done at block267if verification is enabled. A record such as record70a(FIG. 37A) of the completed cassette count is stored in prescription record database in non-volatile data storage61.

System11′ can also be configured to fulfill prescription orders for medication and other health-care-related products not requiring counting by first or second tablet counters15,615, thereby providing a more comprehensive tool with which to manage pharmacy workflow. For example, a patient prescription order may require an ointment or other product not requiring tablet counting as represented by box174illustrated inFIG. 12B. Box174includes a UPC barcode176.

For interfaced systems11′, the medication or product contained in box174can appear as a separate prescription on New Order screen119(FIG. 57) or can appear in the Collated Order field89. The patient name121, prescription number135, medication name, strength and form137, count139, image138and status140information can be provided for the medication or product in box174. Barcode176can be scanned with scanner51and the UPC verified to confirm that the box contains the medication or other product required by the prescription. The medication in box174can then be verified as described in connection with blocks247and249.

Exemplary system11′ provides a number of useful advantages. For example, dispensing of tablets (e.g., tablets604,606) by means of a cassette603enables pharmacy personnel to multitask, that is perform different tasks simultaneously. A technician can set the system11′ to dispense from a cassette603and simultaneously perform another task while the tablets1are being counted by system11′.

System11′ can also save valuable pharmacy personnel time because the most frequently-used medications can be loaded in cassettes603and the cassettes for these medications can be stored in close proximity to system11′. Such an arrangement permits pharmacy personnel to avoid having to walk to a static storage shelf location to retrieve a manufacturer's medication container175.

System11′ can also save valuable pharmacy personnel time because cassette dispenser601can feed large quantities of tablets from a cassette603and count with second tablet counter615faster than pharmacy personnel can pour tablets into funnel41. System11′ can be set to feed tablets faster than a vibratory dispenser while maintaining count accuracy. And, cassette-based dispensing is accurate because singulation made possible by cassette dispenser601avoids “overspeed” conditions (i.e., a pour-too-fast condition), thereby avoiding the necessity for a recount.

System11′ provides accurate counts because two tablet counters15,615are used and the counts of each tablet counter15,615are compared by data processing platform17.

Finally, system11′ provides user-flexibility because tablets can be dispensed from a manufacturer's bulk storage container175(FIG. 12A), a cassette603, or both.

Like system11, patient prescription order workflow for a wide-range of medications can be easily managed by system11′. Accuracy in prescription order fulfillment is improved by providing a greater level of certainty that the patient is receiving all of the medication required by the patient's prescription order and that the selected medication is correct. Because system11′ reduces the time required to fulfill patient prescription orders, the pharmacist is free to perform other valuable tasks such as counseling patients. The result of system11′ implementation is an improvement in pharmacy management and in the general level of patient care.

While the principles of this invention have been described in connection with specific embodiments, it should be understood clearly that these descriptions are made only by way of example and are not intended to limit the scope of the invention.