WO2002015095A1

WO2002015095A1 - Prescription managing system

Info

Publication number: WO2002015095A1
Application number: PCT/US2001/025825
Authority: WO
Inventors: Peter Charron
Original assignee: Integrated Documents, Inc.
Priority date: 2000-08-17
Filing date: 2001-08-17
Publication date: 2002-02-21
Also published as: AU2001285040A1

Abstract

An electronic system (100) for prescribing medical items. The system (100) includes a validation mechanism which subjects certain items to verification criteria which include legal criteria, and precludes a prescription from being communicated to a dispenser unless such criteria have been fulfilled.

Description

PRESCRIPTION MANAGING SYSTEM FIELD OF THE DISCLOSURE

The present invention relates to a medication ordering system and more particularly to a prescription managing system that is both flexible and interactive and which has integrated into the system a resource and communication network providing the users with drug, patient, and prescribing information. BACKGROUND

The process of obtaining prescription medications is critically important in the healthcare field, but can be inefficient, complex and sometimes even prone to errors. Insurance preferred drug lists are increasingly numerous, complicated, and difficult to manage and, furthermore, the time a doctor has to spend with patients is at a premium in today's healthcare environment. The choice of drugs requires the physician to draw upon a huge base of information regarding the patient's condition and medical history, knowledge of drugs and pharmacology, and clinical and therapeutic data. The physician's choice of drugs greatly influences the patient's clinical course as well as the overall cost of treatment.

Traditionally, physicians order drugs by writing an order in a chart for hospitalized patients or by writing a drug prescription on a prescription blank for outpatients. The physician typically relies on personal knowledge supplemented by available reference sources (e.g., books, journals, professional consultations, etc.) together with an in depth understanding of the patient's medical condition when formulating a therapeutic drug regimen.

While it is convenient for the physician to handwrite a prescription on a prescription blank, handwritten prescriptions are time consuming for pharmacists to deal with, and often require independent verification before drags can be dispensed. The overall process of prescribing and dispensing a medication could be much improved. In particular, the possibility of misreading a physician's handwriting is almost legendary. At best, the necessity for a pharmacist to verify the content of a poorly legible prescription can cost time at the physician's office and can delay the pharmacist in dispensing the medication. At worst, a poorly legible prescription can lead to serious or even fatal mistakes.

Accordingly, systems have been proposed which provide practitioners with a way to efficiently manage the prescription process, from prescription generation to record keeping to communication with patients and pharmacies. Information from various sources ~ including the Journal of the American Medical Association (JAMA), the Institute for Safe Medical Practices and The Pharmacy Society of the State of New York (PSSNY) ~ indicates that moving to electronic prescription transfer should bring up to a 40% reduction in medication errors that occur due to misinterpretation of handwriting. This means physicians and their staff will spend less time on the phone with pharmacies clarifying prescription orders and have more time to spend with patients.

Current computer systems show promise in improving the process of ordering and prescribing drugs. For example, a drug order or prescription could be entered directly into a computer and transmitted electronically thereby reducing the time from when the order is written to when it is received in the pharmacy. Numerous systems have been developed, that focus on order entry. These do not solve certain inefficiencies in the order entry process. For example, relevant patient medication information is often not readily available to the prescriber in a complete, comprehensive and conveniently organized format. This includes lists of current and past medications, height, weight, and age, and information on drug allergies and adverse drug reactions. This information is important when making medication choices. Similarly, present systems often do not keep the prescriber informed of formulary information, drug-to-drug interactions and the effect on these interactions of biochemical and enzyme species which are known to occur in the human body. Furthermore, present systems do not keep the prescriber sufficiently informed of statutory requirements which prohibit or restrict the prescribing of medications.

While a pharmacist may have some or all of the patient and drug records required before a prescription can be dispensed, there is a need to provide input of and access to such data at the point of patient care so that they are readily accessible to authorized users.

There is a need to provide a system that makes available to the prescriber a variety of information regarding the patient's medication history, allergies, drug interactions, recommended doses, and which alerts the prescriber against drug interactions and adverse drug reactions which may result in untoward outcomes. Furthermore, there is a need to provide a system which alerts the prescriber to potential violations of legal requirements in prescribing a drug. SUMMARY OF THE INVENTION

The present invention is a network-based electronic system for ordering or prescribing medications for a patient. The system includes an improved process for allowing a prescriber or other authorized person to identify the patient using interactive software. The system includes a database containing general medical prescribing and drug information e.g., pharmacology, dose recommendations, restrictions. In particular, this database can have stored biochemical and enzyme data which provide for the comparison of two or more pharmaceutical products or agents in context with their known human biochemical and enzyme relationships for possible interactions resulting in the inactivation, acceleration or deceleration of metabolism of one or more of the compared agents and the biochemical process or enzyme involved.

The system also includes a program for accessing the database and displaying to the prescriber a list of active and inactive medications for the patient. The system accepts and processes medication orders and prescriptions for the patient from the prescriber which are typically comprised of drug product, dose, route of administration and frequency. In addition, the system communicates the medication order to the hospital pharmacy or the prescription to the outpatient/clinic/retail pharmacy.

In accordance with one aspect of the present invention, a process is provided which facilitates in selecting a patient and accessing all relevant health and medication information for that patient (e.g., allergies, adverse drug reactions, medication history). Of course, a user may store in the database new information regarding a patient who is not already identified therein.

The system alerts the prescriber to potentially adverse situations that may result from an ordered or prescribed medication based on existing patient information. For example, the system may warn the prescriber of a potential allergic reaction or drug interaction when a medication is ordered. Furthermore, the system can flag and prevent the prescribing of drugs in a manner contrary to legal requirements.

While the prescriber can provide an authorized representative with handwritten instructions as to the desired prescription for entry into the system, this may still lead to errors. It is therefore preferred that the prescriber enter the instructions directly. Since it is often inconvenient for a prescriber to have continuous access to a computer terminal, a preferred embodiment of the invention provides that the prescriber can enter the prescription into a handheld computer or personal digital assistant (PDA), which can be interfaced with the terminal either by the prescriber or by the authorized representative. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows schematically an electronic prescribing system.

Figures 2a-2g show a flow chart of a prescription creation and transaction process.

Figure 3 shows a Data Entry Frame (DEF) window and an Interactive Information Field (IIF) window as they appear together on a display screen. Figure 4 shows a Login window.

Figure 5 shows a Patient History window.

Figure 6 is a Prescription window.

Figure 7 is a Patient Demographic window.

• Figure 8 is an Office Information window. Figure 9 is a User Information window.

Figure 10 is a User Privileges Information window.

Figure 11 is a window pertaining to access to a hand-held device.

Figure 12 is a Prescription Status window. Figure 13 is window pertaining to the status of a prescription record received from the hand-held device.

Figure 14 is an Assign Practice Administrators window.

Figure 15 is a Custom Report window.

Figure 16 is an IIF Patient Selection Index window. Figure 17 is an IIF Patient Demographics window.

Figure 18 is an IIF Pharmacy Selection Index window.

Figure 19 is an HF Directions: Action Selection window.

Figure 20 is an IIF Error Display window.

Figure 21 is a Login window of the hand-held device. Figure 22 is a Select Patient window of the hand-held device.

Figure 23 is a Select Prescription Type window of the hand-held device.

Figure 24 is a Select Drug/Item Name window of the hand-held device.

Figure 25 is a Select For Each window of the hand-held device.

Figure 26 is a Directions window of the hand-held device. Figure 27 is a Custom Directions window of the hand-held device.

Figure 28 is a Prescription Summary window of the hand-held device.

Figure 29 is a Select Pharmacy window of the hand-held device.

Figure 30 is a Patient Demographics window of the hand-held device.

Figure 31 is a Main Menu window of the hand-held device. DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawings, Figure 1 schematically shows a network-based prescribing system 100 for electronically capturing and processing information for prescribing a medication or treatment to a patient. The system 100 provides for generating, saving to database, transmitting and tracking a transaction record that is most commonly a prescription, but can also pertain to an in-practice dispensation by a practitioner of a pharmaceutical sample, or an order to another practitioner to provide therapy. The system 100 has an application server 102 which is connected electronically through a fire wall 104 and a network 106 to a plurality of prescriber practices or offices 108. The network 106 is typically a global network such as the internet but can be a local network such as an intranet. To connect with the network 106, each prescriber practice or office 108 has a network interface such as a conventional workstation 200 with a display screen 202. Optionally, a portable device which can include a laptop computer 110, and in particular a hand held device such as a personal digital assistant (PDA) 400 with a PDA display screen 402 can be used to input data. A link 112 which can be wired or wireless is provided from the PDA 400 to the workstation 200, from which the data is forwarded to the application server 102.

However, when a portable device such as the PDA 400 is used to transmit information to the application server 102, it is understood that the network interface need not be in the form of the conventional workstation 200. Any device which provides an interface between the PDA 400 and the application server 102 will suffice, for example a simple receiver which can accept a wireless transmission from the PDA 400 and relay the received information to the application server 102.

The application server 102 is also connected to a Data Base server 114, a Data Map server 116, an Electronic Data Interchange (EDI) server 118 and a Fax server 120, in the manner indicated in Figure 1. The EDI server 118 and the Fax server 120 are electronically linked to a fulfillment entity 122, which is typically a pharmacy. In the case of the Fax server 120, the electronic connection is through a phone line block 124.

The system 100 provides for use only by a preselected user, who may have any of various levels of authorization which at a minimum provide access to the system 100 and at a maximum allow the user to perform any of the actions for which the system 100 is designed, subject to authentication by the system. Typically, one level of authorization may be provided to an employee at the medical practitioner's office, while a higher level is provided to the practitioner or to a system administrator.

The user can access a transaction record generated at a second workstation associated with the user's medical practice. Also, an authorized user while associated with one medical practice can access the patient's medical history generated at a second medical practice.

The system 100 employs several layers of security. The first consists of 2-way SSL (secure socket layers) utilizing triple DES protocol and Client Side certificates. The second layer is comprised of device specific registration associated with the coupling of license strings and working keys known only to a provider of the system. The third layer consists of standard user name/password pairs with Strong passwords formatting (i.e. the requirement that a password contain at least one number.) The system 100 may also provide for a fourth tier that would require authentication of high risk transfer, i.e. narcotics, by the prescriber whose name has been associated with the prescription for transaction. At the heart of the system 100 is a central database 130 which resides at the Data Base server 114. The database 130 has information necessary to the prescribing of medicines, including patient medical history, pharmacological information regarding the medication, pharmacolegal information regarding the medication, formulary information regarding the medication and general information on drugs and their biochemical ingredients.

Formulary information specifies which medically appropriate drags an insurer deems to be acceptable. The medical history information can pertain to large numbers of patients, and a search for the medical history of a specific patient can, for example, be made of all medical history databases within a selected radius. Other important information pertains to the normal use of a drag and its side effects and drag interactions, some of which may be affected by the patient's medical history.

The system 100 has a validation mechanism which provides for validating selected items entered into the transaction if they satisfy certain rales in the database 130 pertaining to those items. The database 130 includes information on pharmacolegal matters. The pharmacolegal information pertains to applicable Federal or Central Government, State or Provincial and

Medicaid or other Governmental Health Care Entitlement Program laws and regulations affecting an order to dispense pharmaceutical products or other medical supplies or equipment. In particular, for use of the system 100 in the United States, the database 130 contains a listing of medications and medical devices classified according to controlled substance Schedules I-V, described in the Code of Federal Regulations, Title 21 Food and Drags, Part 1306. A listing of uncontrolled substances is also present in the database 130. The validation mechanism provides for that order's compliance with the aforementioned laws and/or regulations. The database 130 also contains rales pertaining to individual states if these are more stringent than the Federal rules. The validation mechanism provides that the most stringent rales in applicable to the user's locality are complied with. Of course, the database 130 can include rales for other national and lower jurisdictions.

The system 100 provides interactive feedback including detail on which law or regulation has been violated and a suggested action for correction to the system user when a prescription has failed validation. The validation mechanism can be programmed to vary, conforming at a given locality with rales required by the laws of whatever jurisdictions apply in that locality. The transaction is not considered complete until it is free of any item which has failed validation, and cannot be saved to database or transmitted until it is complete.

Referring again to the drawings, Figure 2 is a flow chart showing the steps of a prescription creation and transaction process. It will be appreciated by those skilled in the art that describing fully all features of the system 100 would be cumbersome, and that it is sufficient for the purpose of explaining the working of the invention to provide a detailed description of certain exemplary features. The following will include a description of selected windows which can appear on the display screen 202. Figure 4 shows a login window 212 with a user field 214 and a password field 216. On correctly entering an identification and password, the user can enter the system 100 by pressing a login button 218. After login, a patient history window 232, as shown in Figure 5, normally appears on the display screen 202 by default. The patient history window 232 allows for the review of patient prescription records, and is a particular instance of a data entry frame (DEF) 230, best shown in Figure 3. The DEFs 230 have in common a plurality of primary control buttons 220. The "history" control button in Figure 5 is highlighted to signify to the user that it is active. Each DEF 230 is activated by clicking the appropriate primary control button 220

Other DEFs are: a Prescription window 234 (Figure 6), which allows for the generation of prescription records; a Patient Demographics window 236 (Figure 7), allows for the entry of patient specific information; an Office Information window 238 (Figure 8), which allows for the entry of office specific information; a User Information window 240 (Figure 9), which allows for the entry of user related information; a User Privileges Information window 242 (Figure 10), which allows system access to be assigned to users; a PDA Access window 244 (Figure 11), which allows for the assignment of hand-held or Personal Digital Assistant (PDA) devices to users; a Prescription Status Window 246 (Figure 12), which allows for the monitoring of pending prescriptions; a PDA Prescription Status window 248 (Figure 13), which allows the user to monitor the status of PDA entered data; an Assign Practice Administrators window 250 (Figure 14), which allows for a user to be designated as a Practice Administrator; and a Custom Report window 252 (Figure 15), which allows for the creation of custom reporting from the prescription records.

The PDA 400 allows the interactive input of data by a user such as a practitioner who cannot always be present at the workstation 200. The PDA 400 provides for writing a prescription and viewing an abbreviated version of the Patient Demographics window 236. Being readily portable, the PDA 400 provides the practitioner with a convenient way to enter data, which can subsequently be transmitted to the workstation 200 for uploading to the database 130 by providing the link 112 between the PDA 400 and the workstation 200. The PDA 400 also provides for designating whether a newly entered prescription, once it has been uploaded to the workstation 200, is for transmittal, printing, or save-to-database-only. Each DEF 230 is always accompanied on the display screen 202 by an interactive information frame (IIF) 260, as shown particularly in Figure 3. The IIF 260 can be a blank window, an informational window or a selection index window. A particular selection index window is normally opened in response to the user clicking an appropriate field of the DEF 230. In other words, any one of a plurality of IIFs 260 can be current alongside a particular DEF, depending on the corresponding field which was most recently clicked.

Depending on the particular field, data can be entered into a DEF 230 by a variety of ways. Using the following examples which refer to the prescription window 234 of Figure 5, one skilled in the art may infer from the drawings how data can be entered into any of the DEFs 230. Like any DEF, the prescription window 234 may be selected for display by clicking with the mouse on the appropriate primary control button 220; once it has been selected, the "prescription" control button is highlighted as shown in Figure 5 to signify to the user that it is active.

Clicking a Select Patient button 262 in the prescription window 234 causes an IIF Patient Selection Index window 264 (Figure 16) to open. This window 264 lists patients associated with any office 108 for which the current user has Prescription Entry privileges. It allows the user to change the patient associated with a prescription without clearing any prescription information.

Clicking an Edit Patient button 266 opens an IIF Patient Demographics window 268 (Figure 17) if the user attempting to do so has been properly authenticated by the application server 102; otherwise, a message indicating that the user is unauthorized appears. If authorized, the user may then edit information for the selected patient in the Patient Demographics window 236.

A Pharmacy Field 270 defaults to a pharmacy previously used by the patient. Clicking the Pharmacy Field 270 causes an IIF Pharmacy Selection Index window 272 (Figure 18) to open, showing a list of fulfillment entities any of which can be selected in preference to a default pharmacy, causing the preferred fulfillment entity 122 to appear in the Pharmacy Field 270.

A Date Field 274 defaults to the current Server date, and may be directly edited by the user to a past date.

An Rx (Prescription) Type Pull Down List Box 276 provides a list of prescription categories including Standard, Compound, OTC (over the counter), Homecare, and Sample. Normally the list defaults to "Standard", indicating that a standard prescription consisting of a single prescription medication is desired. When "Sample" is selected, this provides for in- practice dispensation by the practitioner of a pharmaceutical sample, the resulting transaction not being a prescription intended for fulfillment at a pharmacy facility and including an identifier to that effect. When "Compound" is selected, this provides for the practitioner to select two or more pharmaceutical products or agents, specifying quantity and unit, and compile them into a list in the form of a formula for pharmacist compounding. This list of components becomes part of the prescription intended for conveyance to the pharmacy. Clicking a Drug/Item Name Field 278 opens an IIF Drag Name Selection Index window

(not shown). The specific IIF displayed depends on Prescription Type; Standard & Sample displays a Drug Name Selection; OTC displays an OTC Drag Name Selection; Homecare displays Homecare Item Selection; and Compound displays Compound Builder. These IIFs are not illustrated. The content of the Drag/Item Name Field 278 can only be modified via the IIF Drug Name Selection Index window.

A Strength Field 280 and a Form Field 282 are read-only fields displaying the strength and form of the drug item selected, but remaining empty if the prescription type is Homecare or

Compound.

A Quantity (Qty.) Field 284 requires the user to enter directly therein a metric quantity of units of medication to be dispensed.

Clicking on an Action Field 286 opens an IIF Directions: Action Selection window 288

(Figure 19), which contains a list of actions, for example "take", "give", "spray" and "apply".

The user can click on any of these actions, causing it to be displayed in an IIF Action Field 290 and in the Action Field 286. Clicking on a Number Field 292 opens an IIF Directions: Number window (not shown), which provides for the user to select a single one- or two-digit number or two such numbers to signify a number of units or a range of units of dosage of the drug or item to be administered, the number or range then being displayed in the number field 292.

Clicking on a Route Field 294 opens an IIF Directions: Route Selection window (not shown), which provides for the user to select a route of administration of the prescribed substance, from a list of such routes. Examples of routes are "in both ears" or "intravenously".

Each route has an associated letter code which appears in the Route Field 294.

Clicking on a Schedule Field 296 opens an IIF Directions: Schedule Selection window

(not shown) which provides for the user to select a schedule of administration of the prescribed substance, from a list of such schedules. Examples of schedules are "twice daily" or "every other day". Each schedule has an associated letter code which appears in the Schedule Field 296. icking on a Cond. (condition) 1 Field 298 opens an IIF Directions: Cond. 1 Selection window (not shown) which provides for the user to select an event-based condition from a list of such conditions. Examples of event-based conditions are "before meals", "in the morning" or "as needed". Each event-based condition has an associated letter code which appears in the Cond. 1 field 298.

Clicking on a Cond. (condition) 2 Field 300 opens an IIF Directions: Condition 2 Selection window (not shown) which provides for the user to select a symptom-oriented condition from a list of such conditions. Examples of symptom-oriented conditions are "for shortness of breath", "for pain" or "for nausea". Each symptom-oriented condition has an associated letter code which appears in the Cond. 2 field 300.

An Each Dose field 302 provides for the user to enter directly therein additional information associated with the units of medication to be administered from a non-unit dose Quantity expressed as a volume. This is typically used to confirm the intended dosage of medications in liquid form, since they are not provided in discrete units such as tablets, capsules and so on.

Field 304 provides for the user to enter directly therein the number of refills of the prescription which may be dispensed.

A Free Form Directions Field 306 allows the user to optionally enter directly therein additional directions associated with the use of medication to be dispensed. In certain cases, other fields which provide directions may not have been completed. For example, they may not have been completed for prescription types not involving controlled substances; in such cases, the Free Form Directions Field 306 must be completed.

Clicking on a Prescriber Field 308 opens an HF Prescriber Name Selection Index window (not shown) which provides for the user to select from a list of Prescribers associated with the current office of login who have a user status of "Active".

A License Field 310 is a read-only filed displaying a State license number corresponding to the selected prescriber.

A DEA Number Field 312 is a read-only filed displaying a DEA number corresponding to the selected prescriber. Clicking on a Dispense As Written Check Box 314 causes the displayed box to appear checked. Clicking on a Controlled Substance Exception Code Field 316 opens an IIF Controlled

Substance Exception Codes Selection Index window (not shown), which provides for the user to select from a list of letter codes, each of which corresponds to an enabling condition for prescribing a controlled substance. It is evident from the foregoing description that the system 100 allows for the recording of each portion of the directions of a prescription separately. This method of data capture allows for high levels of validation calculations on each of the individual variables that together represent the directions.

Other buttons in the prescription window which may collectively be referred to as Transaction buttons are a Transmit-Save button 318, a Print-Save button 320 , a Save for History

Only button 322 and a Validate Only button 324. Clicking any Transaction button results in data currently displayed on the prescription window 234 being subjected to a validation process if those data are subject to validation.

If the data are successfully validated, they are committed to the database 130 to provide a record of the prescription or in-practice dispensation, along with other actions appropriate to the given button. The Transmit-Save button 318 provides for the prescription to be transmitted to the selected pharmacy. The Print-Save button 320 provides for the prescription to be printed as a hard copy. The Save for History Only button 322 provides only for the data to be saved in the database 130, without any output. The Validate Only button 324 provides for the prescription to be displayed on a Prescription Status screen (not shown) for output mode assignment. This for example provides for an otherwise valid transaction prepared by a user at a lower authorization level to be held in a suspense area to await review and approval by a user with a higher authorization level than the current user.

If the Prescription window 234 has been entered via the PDA 400, a Change Output button (not illustrated) appears which permits the user to change the mode of Transaction originally assigned on the PDA device 400.

All of the Transaction buttons when clicked initiate validation of all appropriate logic other than that associated with transmit/print modes. When the Transmit-Save button 318 or the

Print-Save button 320 is clicked, this additionally initiates validation of logic associated with transmit or print modes. In particular, it validates whether the current user is authorized to transmit or print the prescription.

Clicking any of the Transaction buttons and successful completion of the validation process causes the action appropriate to the particular transaction button. However, if there is a validation error, an IIF Error Display window 328 (Figure 20) is displayed to inform the user as to the nature of the error and provides an opportunity for a corrective action, which is then subject to revalidation. If the validation is successful, the item will then be transacted as appropriate to the function of the Transaction button clicked. It is reiterated that the validation mechanism precludes the prescribing of any prohibited medication or of an otherwise permitted medication outside legally specified limits such as pertain to the quantity prescribed, the frequency at which it is prescribed, or the number of refills. If the error is a formulary error, i.e., the prescription is permissible but not included in an insurance formulary, the user may override the error, validating an otherwise invalid item and providing for the prescription to be fulfilled but only at the patient's expense. The system 100 contains database information on drug-to-drag interactions and further contains drag-related biochemical information; for example, certain biochemical and enzyme species that can occur in the human body may result in possible interactions which inactivate, accelerate or decelerate the metabolism of medications that are simultaneously present in the body. A DEF 230 and an IIF 260 allows the user to select a plurality of drugs; if the drags have an undesirable interaction, an error window so indicates and recommends corrective action, such as the selection of an alternative drug.

Optionally the system 100 could have an IIF 260 allowing the user to enter one or more biochemical or enzyme species which maybe present in the patient's body, for example as a result of the patient's condition. If the biochemical or enzyme species interacted with one or more of the plurality of drugs to produce an undesirable outcome, an error window would so indicate and recommend a corrective action, such as the selection of an alternative drag. Alternatively, the IIF 260 which would allow the user to enter a condition of the patient which would be prone to producing such a biochemical or enzyme species. Again if an undesirable outcome were indicated, an error window would suggest a corrective action, such as the selection of an alternative drug.

The PDA 400 can store and provide for the retrieval of selected data from a PDA subset 404 of the database 130, and allows the authorized practitioner to enter therein data for a new prescription or for an in-practice dispensed medication. The PDA 400 has the following PDA windows which can appear on the PDA display screen 402: a PDA Login window 408 (Figure 21) which allows the practitioner to authenticate to the PDA device prior to use; a Select Patient window 410 (Figure 22) which allows the user to select the patient to be associated with the new prescription; a Select Prescription Type window 412 (Figure 23) which allows the practitioner to select the prescription type and associated parameters; a Select Drag/Item Name window 414

(Figure 24) which allows the user to select a drag or item to be associated with the prescription; a Select For Each window 416 (Figure 25) which contains selections associated with quantity, refills and the dispense as written parameters; a Directions window 418 (Figure 26) which allows the user to build the prescription directions, such directions being built in a manner similar to that provided by the main prescription window 234; a Custom Directions window 420 (Figure 27) which allows the user to enter custom or "free form" direction text, again in a manner similar to that provided by the main prescription window 234; a Prescription Summary window 422 (Figure 28) which provides a summary display of the prescription record the practitioner has constructed via the previous windows and also provides opportunity to edit this record; a Select Pharmacy window 424 (Figure 29) which allows the practitioner to select a pharmacy to be associated with the prescription record and the patient; a PDA Patient Demographics window 426 (Figure 30) which allows the practitioner to view information from the PDA local patient record; and a Main Menu window 428 (Figure 31) which allows the user to select a category of function to proceed to.

Since the system 100 is network-based, security is a prime concern. The system 100 is therefore designed to permit only encrypted data to be exchanged in either direction between the workstation 200 and the application server 102.

In a typical example of the system's use, the practitioner has authorized access to a PDA which is preregistered for use in the current practice of login. The practitioner logs into the PDA via the PDA login window 408 on entry of a valid password, and the PDA defaults to the PDA

Select Patient window 410. The practitioner then builds the prescription by appropriately following actions provided for by the PDA windows.

When one or more prescriptions have been recorded in the PDA 400, the link 112 between the PDA and the application server 104 is established; as stated earlier, the link 112 may be either wired via a workstation conduit, or wireless. The PDA record is uploaded from the

PDA 400 to the database 130 and any new data (such as new patient records) are downloaded from the database 130 to the PDA 400.

Typically, the system 100 is programmed to automatically flag records for download if the creation date is more recent than the date of the previous synchronization event. Once the prescription has been uploaded into the database 130, the user can view it through the PDA Prescription Status window 246 (Figure 13), which allows the status of PDA entered data to be monitored on the display screen 202; at this time the user is typically an authorized individual other than the practitioner who entered the prescription into the PDA 400.

If the prescription has no invalid item and was tagged for printing, it appears in a PDA Print Queue portion 330 of the PDA Prescription Status window 246, wherein it can be highlighted and printed by clicking a Print Selected button 332. If the prescription has no invalid item and was tagged for send, it will be automatically forwarded electronically to the selected Pharmacy. If it has failed validation, it appears in a PDA Failed Validations portion 334 of the Prescription Status window 246, wherein it can be highlighted. Clicking a highlighted field 336 causes the corresponding Prescription window 234 to open, which allows the prescription to be edited if the user is so authorized.

In summary, the invention provides a secure network-based electronic system 100 with a database 130 containing patient information, drug information and user information, and has a display 202 whereon can concurrently be displayed a DEF 230 and an IIF 260 which is interactive therewith. The drug information includes pharmacolegal information. Selected data can be drawn from the database 130 and entered into a transaction which can if validated be saved to database. The transaction may fail validation if it contains items which lie outside statutory limits, which alert the user to undesirable drag interactions or which conflict with formulary requirements. The transaction may take the form of a formal prescription for fulfillment by a pharmacy, or it may provide a record of an in-practice dispensed medication sample. The system 100 provides the user with an opportunity to remedy failed validations by taking corrective actions. The system 100 provides for data to be entered into the hand held device for subsequent uploading through the wired or wireless link 112 to the application server 102 through a network interface such as the conventional workstation 200. However, it is also contemplated that the network interface can be in the from of any receiver which can wirelessly receive information from the hand held device 400 for relay to the application server 102. The system further provides that the practitioner responsible for an aspect of a given patient's care, who generates medication or prescription histories, can authorize access to selected records of such histories to other appropriate physicians or medical practitioners involved in the care of the aforementioned patient. Further, the patient's medical history information can be retrieved by an authorized search of all accessible records of all patients in a selected region.

While the invention has been shown and described with particularity, it will be appreciated that various changes and modifications may suggest themselves to one having ordinary skill in the art upon being apprised of the present invention. It is intended to encompass all such changes and modifications as fall within the scope and spirit of the appended claims.

Claims

I claim:

1. An electronic medication prescribing system comprising:

(a) a database containing patient information, a list of a plurality of medications and medical devices, pharmacolegal rules regarding the plurality of medications and medical devices and formulary rales regarding the plurality of medications and medical devices; (b) means for selecting a patient from the database;

(c) means for designating at least one of the plurality of medications and medical devices in the database;

(d) means for entering directions for use of the designated medication or medical device, a prescriber name, a dispensed quantity and a number of refills; (e) means for validating each of the entered items against the pharmacolegal and formulary rules in the database;

(f) means for identifying an invalid item to a user;

(g) means for changing the invalid item;

(h) means for repeating steps (e), (f) and (g) until all items are valid; and (i) means for outputting a completed transaction containing the valid items.

2. The system of Claim 1, wherein the database is accessed through a network.

3. The system of Claim 1, wherein the database contains a listing of medications and medical devices pertaining to each of a plurality of classifications of controlled substances and a listing pertaining to uncontrolled substances, and further contains a listing of the rales pertaining to each of the classifications.

4. The system of Claim 3, wherein the classifications are the five United States federal schedules of controlled substances.

5. The system of Claim 4, wherein the rales for the controlled substances include the rales provided for by United States federal laws and regulations, and also include such more stringent rules as are provided for by the State jurisdiction of the user.

6. The system of Claim 1 , comprising a workstation which provides the user with access to the database.

7. The system of claim 6, wherein the user can access a transaction record generated at a second workstation associated with the user's medical practice.

8. The system of Claim 6, wherein the user can retrieve from the database medical information regarding the selected patient which was generated at a medical practice other than the user's medical practice.

9. The system of claim 1, having a network interface which can receive input information from a hand-held device and transmit said information to the database.

10. The system of claim 9, wherein the network interface can wirelessly receive input information from the hand held device.

11. The system of claim 6, wherein only encrypted data can be transferred in either direction between the user and the database.

12. The system of claim 1 , comprising also means for the user to add new patient information to the database.

13. The system of claim 1, comprising also overriding means for accepting as valid an invalid formulary item.

14. The system of claim I, the directions for use including an action, a medication dosage, a medication schedule, a medication route, an event-based condition and a symptom- oriented condition.

15. The system of Claim 1 , comprising means for identifying potential medication interactions to the user.

16. The system of claim 1, comprising means for electronically transmitting the completed transaction as a prescription to a fulfillment entity.

17. The system of claim 1, comprising means for producing a printed prescription for presentation at a fulfillment entity.

18. The system of claim 1, comprising an identifier indicating that the transaction pertains to an in-practice dispensed drug sample and is not a prescription indicated for fulfillment at a pharmacy facility.

19. The system of claim 1, comprising means for holding in a suspense area a completed transaction prepared by a user at a lower authorization level pending review and approval by a user with a higher authorization level than the original user.

20. The system of claim 1 , wherein the database is at a central location remote from the user.

21. The system of claim 1 , having a means of assigning one of a plurality of authorization levels, a lower level permitting access to the system while not permitting certain actions, the highest level permitting access to the system and permitting all actions designed into the system.

22. The system of Claim 21 , having also a means of authenticating the authorization of the user.

23. The system of claim 1, wherein the patient's medical history information is retrievable by an authorized search of all accessible records of all patients in a selected region.

24. The system of claim 1, wherein the completed transaction has a formula containing a specification pertaining to each of at least two designated medications intended for compounding.

25. A network-based method for electronically generating a medical transaction, comprising the steps of:

(a) authenticating from an application server a user's authorization to access a remote database containing patient information, a list of a plurality of medications and medical devices, pharmacolegal rales regarding the plurality of medications and medical devices and formulary rules regarding the plurality of medications and medical devices;

(b) accessing the database;

(c) selecting a patient from the database;

(d) designating one of the plurality of medications and medical devices in the database; (e) entering directions for use of the designated medication or medical device, a prescriber name, a dispensed quantity and a number of refills;

(f) validating each of the entered items against the pharmacolegal and formulary rules in the database and identifying any invalid item;

(g) changing the invalid item; (h) repeating steps (f) and (g) until all items are valid; and

(i) outputting a transaction containing only valid items.

26. The method of claim 25, wherein the step of changing the invalid item includes overriding the invalidation of the item to render it valid, if the item is a formulary item.

27. The method of Claim 25, including also the step of adding new patient information to the database.

28. The method of Claim 25, including also the step of electronically transmitting the outputted transaction as a prescription to a fulfillment entity.

29. The method of Claim 25, including also the step of converting the outputted transaction to a printed prescription for presentation at a fulfillment entity.

30. A network-based method for electronically generating a medical transaction, comprising the steps of:

(a) using a PDA to interactively prepare a PDA record for a PDA database, the PDA record including patient information, a medication or medical device, directions for use and a prescriber name; (b) sending the PDA record to a network interface;

(c) validating sent PDA record items against pharmacolegal and formulary rales in a central database and identifying an invalid item;

(d) changing the invalid item; (e) repeating steps (c) and (d) until all items are valid; and

(f) outputting a transaction containing the valid items.

31. The method of claim 30, wherein the step of changing the invalid item includes overriding the invalidation of the item to render it valid, if the item is a formulary item.

32. The method of Claim 30, wherein the step of sending the PDA record to the network interface includes wirelessly sending the PDA record.