System and method for automated prescription management

[0001] This invention relates to automated prescription administration, and more particularly, an automated prescription voice system accessible to a user via a conventional telephone using DTMF tones interconnected with databases using fax on demand and internet protocols.

[0002] Hospitals and medical offices in the United States handle millions of requests for prescription refills a day from pharmacies seeking to meet patients needs. These requests are typically handled in one of the following three ways. The pharmacy may leave a voice mail message that is transcribed by hand. The prescription is then authorized by the physician and called back to the pharmacy over the telephone or transcribed again and faxed to the pharmacy. Alternately, the pharmacy faxes the prescription request to the physician's office and the physician approves the fax and faxes it back to the pharmacy. In many cases the fax is unclear and the physician's office must telephone the pharmacy for clarification. Finally, the pharmacy may send a written form over the internet, either through e-mail or as a completed form using a prescription generation service.

[0003] Each of the above methods suffers from disadvantages. Listening to voice mail prescription requests and transcribing these requests is time consuming and expensive. Additionally, there are 89,000 unique prescriptions available for dispensing in the U.S. today, many of them with similar sounding names. For example, Celebrex is an arthritis drug, Cerebyx is a seizure drug and Celexa is an antidepressant, each of which has been mistaken for the other in clinical settings. Voice systems, which rely on transcribing information by hand, create the opportunity for physicians to make prescription errors. Faxed prescription requests are often hard to read because of poor transmission quality. Electronic communication of prescription requests is the most accurate, but with many physician's in the US not having computers in their office, the penetration of this technology is low. Also, physicians and pharmacies do not communicate about drugs in the same manner. Pharmacies use a numerical identification and physicians almost exclusively use brand marketing or generic nomenclature. The available systems that deal with prescription requests allow the pharmacy to identify the patient from a preexisting database and then record a voice message defining the drug and dosage being requested.

[0004] Current Interactive Voice Response (IVR) systems allow users to call a specified telephone number and, using DTMF tones or the human voice, navigate a menu to various application modules (i.e. services). These automated systems provide voice messages to a user over a telephone line and process the user's tone type telephone key presses (DTMF tones) as input. The messages played by the system can be tape recorded human voice messages or machine generated speech. These systems answer the telephone call and begin interacting with the user automatically.

[0005] IVR systems may require the entry of an account number, customer number, or password before access to the application modules is allowed. Once in the module, the messages from the system can provide the user with information, prompt the user to enter data or make a selection from a variety of choices. For example, a message can state: “For choice A, press one; For choice B, press two; For choice C, press three.” If the number of choices is large, it may be necessary to present the choices in more than one menu. In that case, the final part of the message would prompt the user to provide a particular input in order to receive an additional message that lists other choices (i.e., “Press nine to hear more options”).

[0006] The user navigates through the system by providing appropriate input at each message to get to the next desired message or to activate a desired option. The user may gain access to information stored in one of the many databases. This information may be communicated using recorded human voice messages or machine generated speech. The user may also be allowed to take action based on a provided service. For example, a user may activate a newly issued credit card by entering personal identification information and card information. The user may also be able to enter information into the system either by using their voice to create a recording or by using their voice to cause the system to recognize words and their preprogrammed action. The user may also enter information using the tones generated on the telephone keypad. For example, a voice query may ask the user to input their telephone number using the keys on the telephone. In this case the user may have already identified himself by the use of a particular account name or personal identification number. The system may create a record of the identity of the user from a preprogrammed database and add to that record information that the user enters or selects, such as their telephone number.

[0007] Prior art allows for the selection of options to add to the newly created record from a pre-existing database. Though the creation of a database record is possible, most IVR systems are designed to provide information to users, or to allow users to take some action such as credit card activation. Most systems are not designed to create database records as their primary function.

[0008] A database is a set of information characteristics about a unique subject. Database tables are often stored in database programs on computer hard disks. IVR systems can be made to create records in database tables if these databases reside on computers with an IVR interface. In the table below, the database captures certain demographic information about the subject parties.

[0009]

TABLE 1
				Patient
Last name	First Name	Date of Birth	Social Security	Number
Fox	Tom	Feb. 4, 1038	476-32-9374	Franklin
Wilkins	Maria	Dec. 23, 1954	559-93-2836	Simms
Anderson	Julie	Jul. 15, 1972	020-68-0022	Hardgrove

[0010] The information can be sorted in many ways. For example, the database may be made to display all subjects who were born in a particular year or who have a particular first name. This stored information can be linked in relational databases. A relational database is a database that has the ability to link two or more database tables together using unique characteristics or keys.

[0011] Prior systems, however, do not adequately create an interactive relational database that captures specific information to make a medical decision regarding prescription drug use and, once the decision is made, execute the planned action of that decision. Prior art does not allow for the consolidation of this information into a database about specific patients for transmission to healthcare providers over fax and internet protocols. Additionally, the prior art does not provide the service of consolidating a patient's full range of active prescription drug regime that is bid out to various commercial entities using internet protocols.

[0012] Accordingly, it is an object of this invention to provide an interactive voice response system that allows for absolute identification of drug and dosage information.

[0013] It is another object of this invention to provide a system that links patient identification to a specific medical record held by the physician and creates a patient prescription history database.

[0014] It is another object of this invention to provide a system that makes databases available to practitioners using fax on demand and internet protocols.

[0015] The present invention is directed to a system of creating a database based on prescription drug refill requests that are free from incorrect prescription drug identification and incorrect patient identification. The system reduces the time required to process such requests and creates a patient drug history that is accessible to “fax on demand” and internet protocols.

[0016] Removing the hand written transcription component of the prescription drug request process allows for the exact identification of prescription medication using a universally accepted 13 digit unique identifier. There are approximately 89,000 prescriptions available in the United States. Many of these drugs have similar names. The invention allows for the exact identification of the drug based on the 13 digit unique identifier called an NDC number. All drugs available for dispense in the United States are issued an NDC number which stipulates the drug name, dosage and delivery method (solid or liquid) by the FDA.

[0017] The invention creates a database entry of the prescription request and asks the pharmacist to identify the desired medication by keying in the 13 digit NDC number. This NDC number is then confirmed by the invention, which speaks the commercial name to the pharmacist and asks for approval of the drug and dosage. The invention creates 3 safety checks for correct identification of the drug. NDC numbers are typically not known and not used by physicians. Physicians typically use a drug's commercial or generic name. The invention causes a database entry to be created for each request that lists the NDC number as well as the commercial name and dosage of the requested drug. This information is then displayed to the processing physician. The physician who is processing this request does not have to guess as to the true name or dosage of the request. The invention generates a database prescription refill request that has a verified unique NDC number as well as the unique nomenclature and dosage.

[0018] Additionally, the exact identification of the desired patient may be based on a social security number, patient name or date of birth. Similar to errors generated for incorrectly transcribed prescription drugs, confusion over which patient is requesting the prescription refill request currently exist. A physician's staff or pharmacy may incorrectly identify a patient by shortening a name, for example, from Robert to Bob, or omitting a middle initial on a faxed request or voice mail transcription. The consequences are often as disastrous as prescribing an incorrect drug. The system solves this problem by forcing the pharmacist to identify a patient based on unique information generated from the patient's medical record stored at the physician's office. This unique identifier is linked to the internal record number used by the physician's office for the patient's chart. In cases where identity and diagnosis information is required to ensure that the correct patient is approved for appropriate medication the chart or electronic medical record can be pulled to immediately determine if the refill request is appropriate. The invention virtually eliminates the possibility for incorrect prescriptions caused by transcription errors or illegible faxes.

[0019] The invention generates a unique tracking number for each prescription refill request that records all data provided by the pharmacy, the user who authorized the refilled prescription, and the date and time the prescription was authorized for refill. The invention drastically reduces the time required to process a prescription refill request. The invention improves on current practice by forcing the pharmacy to select a patient from a patient database that correctly matches that patient to a medical record that contains the patient's prescription history.

[0020] Further, the invention allows the refill of prescriptions to be completed at any location with a computer terminal. Because the invention is stored on a computer hard disk that may be shared over a network or the internet, a prescription refill request may be answered from any location accessible to a wire or wireless communication source. The invention also allows physicians to access a patients drug history. This makes it possible for emergency room physicians who are treating a patient to call a specified number, enter a unique pin number, identify the patient and have the prescription history faxed or e-mailed to their location immediately. This results in better medical decisions making at a time crucial to the care of a patient.

[0021] Furthermore, the invention allows for the sorting of approved prescription refill requests. This allows physicians to identify patients who have been given drugs that are being recalled, identify patients who may benefit from new drugs recently approved or identify patients who may qualify for clinical trials for new therapy. This also allows physicians to identify patients with classified disease states as stipulated by ICD-9 codes. This allows administrators to evaluate the plan of treatment for specific disease states.

[0022] The invention allows for the consolidation of all ongoing medication into a single Super Prescription request and allows for the bidding out of that Super Prescription request to commercial entities. Patients are often prescribed single drug prescriptions for varying lengths of time by potentially different physicians. The invention automatically captures all prescription refill requests from pharmacies when they telephone into the system or access it using internet protocols into a single database. The invention also captures new prescription information automatically when a physician writes a prescription during a patient visit. Additionally, the invention has a method for entering prescriptions issued by other physicians who may have seen the patient and prescribed medication. The result is a prescription database for a patient that includes all active medications, all discontinued medications and all drugs that the patient is allergic to or intolerant to.

[0023] The database can be made to produce a “Super Prescription” that displays all active medications that is electronically approved by the primary care physician for a uniform period of time, typically until the next patient visit. The prescription can then be sent electronically to all subscribing pharmacies for the lowest cost bid on the full super prescription. The result is that the patient gets the lowest price on a complete medication package without having to shop individually for each prescription. The patient also does not have to worry about a single prescription expiring before their next regularly scheduled visit, as all prescriptions will be made to expire at the same time. The physician provides better and more complete care for the patient by ensuring that the patient's treatment regime of pharmaceuticals is not interrupted. This process also reduces the number of individual prescription refill requests the physician must process between visits, reducing the physician's workload by approximately 30 minutes per day.

[0024] The following detailed description of embodiments of the invention, taken in conjunction with the appended claims and accompanying drawings, provide a more complete understanding of the nature and scope of the invention.

[0039] FIG. 1 illustrates the interactive voice response (IVR) system of the present invention that is connected to the Triage Administrator network database (FIG. 6). The IVR system detects incoming telephone calls, answers the telephone call and provides the caller with various voice prompts. The IVR system accepts and processes input provided by the caller. The user provides input by pressing buttons on a DTMF telephone during the call. The IVR system allows the user to access a menu where the user is presented with three options for using the system. In the first option 120, the user depresses the “1” key if he is a pharmacy desiring to create a prescription refill request. In the second option 110, the user depresses the “2” key if he is calling from another healthcare entity and desires to create a patient medical history request. In the third option 102, the user depresses the “3” key if he is a healthcare professional desiring a prescription history for a patient.

[0040] Option 120 allows the user to create a prescription refill request. Step 122 presents the option of creating another prescription refill request for the same or a different patient. Step 124 allows the physician to review the refill request and approve or disapprove the request. In step 126 the physician completes any additional refill requests. In step 128 the refill request is either faxed or e-mailed to the requesting pharmacy. In step 130 the physician may use database analysis techniques to search the resulting database for records that meet the desired characteristics.

[0041] In option 110 another healthcare entity such as a clinic, hospital or nursing home may call the system and create a request for the medical history for a patient. In step 112 the system allows the caller to make additional medical history requests for different patients. In step 114 the physician reviews the request and electronically attaches a patient's medical history to the request. In step 116 the request and medical history are faxed or e-mailed to the requesting organization. In step 118 additional medical history requests are processed. In step 130 the physician may use database analysis techniques to search the resulting database for records that meet the desired characteristics.

[0042] In option 102 a physician or healthcare professional requests immediate information concerning a patient's prescription history. In step 104 the physician may request the same information for additional patients. In step 106 the system either faxes or e-mails the requested prescription history information to the desired fax number or e-mail address. In step 130 the physician may use database analysis techniques to search the resulting database for records that meet the desired characteristics.

[0043] FIG. 2 refers to the opening menu that the caller hears when his call is answered by the system. In step 132 the caller hears a general greeting. In step 134 the caller is prompted to select the type of organization he represents, a pharmacy, a doctor's office or an internal medicine physician. The system then presents options to meet that type of organization's informational needs.

[0044] FIG. 3A and FIG. 3B illustrate the process the pharmacy goes through to enter a prescription refill request. In order for a complete prescription refill request to be created and a confirmation number to be generated, the system must positively establish the pharmacy's identity, the patients' identity, the drug identity, the prescribing physician and the date of the last refill. The caller must confirm each piece of information by taking an action such as depressing a key on the telephone keypad. This is necessary to ensure that prescription requests are only issued for the correct medications to the correct patients.

[0045] In step 140 the system compares the identification information provided by a caller to a database of stored pharmacy names and telephone numbers. If the telephone number is recognized, the system bypasses the general greeting in step 132 (FIG. 2) and asks the caller to confirm their identity in step 144. If the caller identification information is not recognized, the caller is transferred to the general greeting in step 132 (FIG. 2). Once the caller depresses the “1” key to indicate they are a pharmacy in step 134 (FIG. 2), they are transferred into the Pharmacy service and asked to enter their phone number in step 142. The system compares the entered phone number to a database of all pharmacy phone numbers. The system speaks the pharmacy name to the caller in step 144 and asks the caller to confirm their identity. If the caller depresses the “2” button to deny his spoken identity, he then has to re-enter his telephone number in step 152. If the caller denies his spoken identity for a second time, the system tells the pharmacy that they are not listed in the pharmacy database and terminates the call.

[0046] If the caller confirms their identity by depressing the “1” key in step 154 or in step 144, then he moves onto step 146 where the system asks the caller to begin to identify the patient by typing in the first three letters of the patient's last name. Next, in step 148, the system asks the caller to type in the patient's date of birth. This information is unique to every patient and can be used by the system to positively establish a patient's identity. In step 150, the system compares this information to a database of all patients and speaks the patient's name to the caller. The caller presses “1” to confirm the patient's identity or “2” to deny the patient's spoken identity. If the caller denies the patients spoken identity, the caller is asked to enter the patient's social security number in step 158. The social security number is unique to every patient and can be used by the system to establish identity. The caller presses “1” to confirm the patients identity or “2” to deny the patient's spoken identity. If the caller denies the patient's spoken identity for a second time (step 160), the system tells the caller that the patient is not listed in the patient database and terminates the call (step 162).

[0047] If the caller accepts the patient identity in step 150, he is asked to enter the 13 digit NDC number of the medication for which he requires a prescription (step 164). In step 166 the caller is asked to confirm the drug's spoken identity. If the caller denies the drug's spoken identity by pressing the “2” key in step 166, he is asked to reenter the drugs 13 digit NDC number in step 168. In step 170 the caller is again asked to confirm the spoken name of the drug. If the caller denies the spoken identity of the drug for a second time, the system tells the caller that the drug cannot be identified and terminates the call (step 172).

[0048] If the drug's identity was confirmed in step 166 or in step 170, the system asks the caller to enter the date the prescription was last filled in step 174. In step 176 the system asks the caller to confirm the spoken date of the last refill date. If the caller denies the date spoken by depressing the “2” key, the caller is then asked to enter the last refill date again in step 182. The caller is then prompted to confirm the spoken date of the last refill. If the caller denies the spoken date of the last refill, he is placed in a “do-loop” where he is continually asked to enter and confirm the last refill date until he confirms the data. If the caller presses “1” in step 176 or in step 184 and confirms the date of the last refill, he is asked to enter the initials of the prescribing physician in step 178. In step 180 the caller is asked to confirm the spoken identity of the prescribing physician. If the caller denies the spoken name of the prescribing physician and depresses the “2” key, he is asked to enter the prescribing physician's initials again in step 190. If the caller again denies the spoken identity of the prescribing physician for the second time in step 192, the system tells the caller that the prescribing physician will try to be identified in step 194. The caller is then transferred to step 186.

[0049] If the caller had depressed the “1” key and confirmed the identity of the prescribing physician in steps 180 or 192, the caller progresses to step 186 where the caller is asked to enter the quantity of medication desired. In step 188, the system then asks the caller to confirm the spoken quantity of medication desired. If the caller denies the spoken quantity of medication desired by depressing the “2” key, the caller is asked to enter the desired quantity again in step 200. If the caller again denies the spoken quantity in step 202, the caller is placed in a “do-loop” until the correct quantity is entered and confirmed in steps 200 and 202. If the caller confirms the spoken quantity of medication desired in step 188 or 202, the caller is asked to confirm the spoken name of the patient, the spoken name of the medication and the quantity desired in step 196. If the caller denies the spoken patient, medication or quantity, the call will be terminated in step 204. If the spoken identity of the drug and the spoken quantity of medication is confirmed, the system issues an unique confirmation number signaling a successful request and asks the pharmacy if there are anymore requests to enter. If there are no more requests, the call is terminated.

[0050] FIG. 4 refers to the option defined in step 110 (FIG. 1) that allows a healthcare entity to call the system and generate a request for a patient's medical history. In order to complete a request, the system must positively establish the correct identity of the healthcare entity, the identity of the patient whose medical records are being requested and the delivery address, fax number or e-mail address where the information will be sent. The caller must confirm each piece of information by taking an action such as depressing a key on the telephone keypad.

[0051] In step 132 of FIG. 2, the caller is greeted with the opening menu of the system. In step 134 of FIG. 2 he is asked to identify the type of entity he is calling from. If the caller selects Doctors office by depressing the “2” key (FIG. 4), the system asks the caller to enter his telephone number in step 210. The system matches the entered telephone number to a pre-existing database and speaks the doctor's office name to the caller in step 212. The caller accepts the spoken identity of the doctor's office by pressing “1” or denies the spoken identity of the doctor's office by pressing “2”. If the caller denies the spoken identity, he is asked to re-enter his telephone number in step 216. The caller is again asked to confirm the doctor's office spoken identity in step 218. If the caller denies the doctor's office spoken identity for the second time by pressing “2”, the system indicates that the doctor's office is not in the system's database and terminates the call.

[0052] If the caller confirms the doctor's office spoken identity in step 218 or in step 212 the system moves forward to identify the patient. In step 214 the caller is asked to enter the patient's date of birth. Next, in step 222 the caller is asked to enter the first three letters of the patients last name. The system then speaks the patient's name to the caller in step 224. The caller confirms the patient's identity by pressing the “1” key or denies the patient's spoken identity by pressing the “2” key. If the caller denies the patient's spoken identity by pressing the “2” key, the caller is asked to enter the patient's social security number in step 228. The system then speaks the patient's name in step 230. The caller confirms the patient's identity by pressing the “1” key or denies the patient's spoken identity by pressing the “2” key. If the “2” key is selected for the second time, the system indicates that the patient is not in the database and disconnects the call.

[0053] If the caller accepts the patient's spoken identity in either step 230 or step 224, the system indicates that the requested information will be faxed to the caller's fax number and speaks that fax number in step 226. In step 226 the system also allows the caller to request a different number to fax the requested information to by depressing the “9” key. The system disconnects the call if the “9” is not depressed in step 234. If the “9” key was depressed in step 226, the system asks the caller to enter a new fax number in step 236. The system then speaks the new fax number back to the caller in step 240. If the caller confirms the new fax number by depressing the “1” key. The call is then terminated. However, if the caller denies the new spoken fax number, the caller is asked to enter the new fax number again. The caller remains in this loop until he accepts a spoken fax number.

[0054] FIG. 5A and FIG. 5B refer to the process an affiliated physician goes through to have a patient's prescription drug history immediately sent to him. Unlike the services detailed in FIGS. 3A and 3B and FIG. 4, the service described in FIGS. 5A and 5B is automatic. This service is designed to meet the needs of emergency room physician's for accurate prescription drug history information. The emergency room physician calls the system and identifies the patient and the fax number or e-mail address where he wants the information sent. Assuming the physician enters a valid username and password, the system will fax or email the requested information immediately.

[0055] The caller indicates that he desires a patient's prescription drug history by depressing the “3” key at the main menu in step 134 of FIG. 2. The system then prompts the physician to enter his user identification in step 242 (FIG. 5A). The system asks the physician to enter his security password in step 244. The system compares the information to a pre-existing database of authorized users to determine the identity of the caller. If no match is found, the physician is asked to enter his user identification again in step 246 followed by his security password in step 248. If no match is found the second time the call is terminated.

[0056] If a match was found in step 244 or in step 248 the system speaks the physician's name in step 252. In step 254 the system asks the physician whether he wants to identify the patient using last name and date of birth or by social security number. If the physician selects social security number by depressing the “2” key, he is asked to enter the patient's social security number in step 264. If the physician selects last name and date of birth by depressing the “1” key, the system asks him to enter the patient's 4 digit year of birth in step 256. Next, the system asks the physician to enter the patients two digit month of birth in step 258, followed by the patients two digit date of birth in step 260. The physician is prompted to enter the first three letters of the patient's last name in step 262. The system then speaks the patient's identity in step 266. The physician confirms the patient's spoken identity by depressing the “1” key or denies the patient's spoken identity by depressing the “2” key. If the “2” key is depressed, the system determines if this is the first denial of the patient's spoken identity in step 268. If it is the second denial, the system denies access and terminates the call in step 272. If it is the first denial, the system asks the caller if he would like to identify the patient using social security number or using last name and date of birth in step 270. If the physician chooses last name and date of birth by depressing the “1” key, he is transferred back to step 256 and he enters the patient information as before. If the physician chooses to identify the patient using social security number by depressing the “2” key, then he is transferred back to step 264 and he enters the patient information as before.

[0057] If the physician confirms the patient's spoken identity in step 266, the system prompts the physician to enter the number of months of the patient's prescription history in step 274 (FIG. 5B). The system speaks the number of months entered and asks the physician to confirm that this is correct. If the physician denies the spoken number of months then the system prompts him to enter a number of months again in step 278. In step 280 the physician is asked to confirm the number of months entered. If the physician denies the spoken number of months for the second time, then the system defaults to 6 months in step 282. If the physician confirms the number of months then the system speaks in either step 280 or in step 276, the system tells the physician that the information will be faxed to him in step 282.

[0058] The fax system is a default setting that can be substituted with an e-mail address generated from a database. In step 286 the system asks the physician to enter the fax number that he wants the information sent to. The system then speaks the fax number in step 288. The physician confirms the spoken fax number by depressing the “1” key. The system then tells him that X number of months will be faxed to the number he entered. If the physician denies the spoken fax number, he is asked to re-enter it in step 290. The system speaks the re-entered number in step 292. The physician confirms the spoken fax number by depressing the “1” key. The system then tells him that X number of months will be faxed to the number he entered. If the physician denies the fax number by depressing the “2” key, he is transferred back to step 288. The physician remains in this loop until he confirms the fax number.

[0059] The above Figures referred to the Interactive Voice Response system that enabled callers to create requests using the present invention, the following Figures detail the user interfaces that allow the hosting physician to process requests and create new prescriptions. FIG. 6 refers to the user interface for the system, known as the Triage Administrator and visually depicted in FIG. 10. In step 300, the physician enter the Triage Administrator and select the Prescription Refills button. All prescription refills are displayed. The user then selects unprocessed requests in step 302. The physician views the information contained in the refill request, visually depicted in FIG. 11, and approves or disapproves the request for refill in step 304. The physician then determines if there are anymore requests in step 306 and processes them accordingly. Completed prescription requests are transmitted automatically in step 308 using fax or internet protocols.

[0060] In step 310 the physician selects the new prescription service from the Triage Administrator. The Physician uses this service in the exam rooms to generate new prescriptions in step 312 or to add prescriptions generated by other physicians to the database in step 314. The invention is capable of running from a networked computer or using a handheld device like a Palm VII, Motorola Timeport, or RIM's Interactive Pager 850. The physician determines if there are anymore prescription requests in step 316. If there are, he selects the type and continues in a do-loop until all prescriptions have been generated or entered.

[0061] In step 318 the physician selects active and historical medications to add to the current prescription in order to ensure that all medication is dispensed for a uniform time period. This consolidated prescription is known as a “Super Prescription” and it ensures that the patient stays on the regime until the next scheduled visit. The “Super Prescription” prevents the patient from running around after single prescriptions. Next, the physician asks the patient if they would like their “Super Prescription” bid out to pharmacies. In the bid process, the physician sends the “Super Prescription” to selected affiliated pharmacies. The pharmacies provide a broken down and cumulative price for the entire “Super Prescription,” including the shipping cost and the delivery date. These bids are submitted to the patient as they exit the physician's office. The winning pharmacy, the pharmacy of the patients choosing, will automatically receive the completed “Super Prescription” using fax or internet protocols in step 308.

[0062] In step 324 the physician selects the Patient Reports service from the Triage Administrator to process requests for a patient's medical history from other health care entities. Once selected, the Patient Reports screen brings up all patient report requests. In step 326 the user selects the view unprocessed requests only button to view open requests. The user then selects individual requests in step 328. The visual representation of these requests can be viewed in FIG. 12. In step 330 the user attaches the requested document or medical history summary to the request and faxes the report to the requesting party in step 308. Alternatively, the request and attached information may be sent using internet protocols.

[0063] FIG. 7 illustrates the actions taken when the user desires to process unfilled prescription refill requests. In step 300, the user selects the Prescription Refills button on the Triage Administrator (see FIG. 10). The user then types in his user name and Personal Identification Number (PIN) in step 332. In step 334 all unfilled prescription requests that the user has authorization to process are displayed on the screen. The user then selects the first uncompleted request and selects the detail button in step 336. The prescription refill request screen appears, illustrated in FIG. 11, displaying the request information in step 338. The user decides if additional information is required to process this request in step 340. If additional information is required, then the chart number is captured from the Prescription Refill Request screen and the chart is reviewed in step 342. If no additional information is required, the user determines if the refill request is appropriate for the patient in step 344. If the prescription refill request is not appropriate for the patient, the user selects the appropriate negative button on the Prescription Refill Request screen, illustrated in FIG. 11, in step 346. If the refill request is appropriate, the user selects the approved button and fills in any comments in step 348. The completed request is added to the outbound fax queue or to the outbound e-mail in step 350. The user checks to ensure that the request was sent in step 352.

[0064] FIGS. 8A and 8B refer to the actions taken when the physician desires to generate a new prescription or enter a prescription generated by another physician. In step 310 the physician selects the New Prescription button on the Triage Administrator (see FIG. 10). The physician logs onto the system using a username and personal identification number (PIN) in step 360. The physician's name and title are automatically completed in the Medical Practitioner field of the Prescription Generator screen (see FIG. 13). In step 362, the physician selects the patient from the daily schedule or types either the Patient Unique Identifier number or the patient's Social Security Number. Once the patient is identified, all demographic information is populated in the patient section of the Prescription Generator (see FIG. 13).

[0065] The system identifies the drug using a pre-programmed database. In step 364 the physician types a drug name or portion of the drug name and a scroll down menu appears with close matches. The physician can continue to type with the scroll down menu eliminating incorrect choices and narrowing the list, or the user can scroll down and select the desired drug name. Next, the physician types or selects a dosage with the choices in solid or liquid form displayed on the screen in a pull down menu from a database table in step 366. In step 368 the physician types or selects the number of months the prescription is valid for, again from a drop down menu tied to a database table. In step 370 the physician may type an expiration date. The physician may also select and populate the DISP, SIG and REFILL boxes in step 372 to indicate specific instructions to the pharmacy. In step 374 the physician may also select buttons signifying certain instructions for the prescription. For example, the physician may select the following buttons: Discontinue, Allergic to, Intolerant to, Generic Substitution Permitted, Dispense as Written or May Substitute Formulary Equivalent with notification. In step 376 the physician populates the ICD9 disease state Code. The physician may or may not fill out the billing modifier in step 378. In step 380 the physician may type special comments in the comments field for the prescribed drug.

[0066] In step 382 the physician may select prescription history to view historical medication information. In step 384 (FIG. 8B), the physician may review some historical prescriptions, such as those that the patient is intolerant or allergic to, and select those prescriptions in step 386 to transmit to the pharmacy for informational purposes. In step 388 the physician decides if there are any historical prescriptions that should be added to the day's prescription to ensure that the patient has their full medication regime through their next visit. These prescriptions are selected in step 390 and placed, by the system, into the current days prescriptions with a record being produced in the system database. For these modified prescriptions, the physician selects the type of prescription in step 392 and the dosage in step 394. The physician selects the number of pills or units for the modified prescription in step 396. The physician may also select the Discontinue, Allergic to, Intolerant to, Generic Substitution Permitted, Dispense as Written, May Substitute Formulary Equivalent with Notification radio buttons in step 398 to specify filling information to the pharmacy. The physician may also complete the ICD9 disease state code in step 400 and the billing modifier in step 410. In step 412 the physician types any comments concerning this medication into the comments field.

[0067] The physician has now created a “Super Prescription” which is a prescription containing all current medications and any relevant historical medications. The physician selects hand or electronic signature in step 414 depending on whether the prescription will be printed, faxed or e-mailed. In step 416 the physician selects the pharmacy by typing it's name or selecting it using a drop down menu. In step 418 the physician selects the output method of fax, e-mail, print or for record. In step 420 the physician reviews the full “Super Prescription” for conflicts between drugs. The physician may use a preprogrammed database tied to the present system to screen for such conflicts. The physician then executes the prescription.

[0068] FIG. 9 refers to the bid process for the “Super Prescription”. The “Super Prescription” is a prescription issued by the physician that day including that day's medications as well as authorization for all current and relevant medications. After reviewing the “Super Prescription” for drug conflicts in step 420, the physician decides to bid out the prescription in step 320. When the bid out “Super Prescription” service is selected, the Fax and For Record boxes are grayed out and inactive (see FIG. 13). In step 422 the physician types special notes to the bidding parties. In step 424 the physician selects the type of subscribing pharmacies based on the patients request. For example, some choices are “local pharmacies only,” “US pharmacies only,” or “pharmacies with free delivery only.” Once the type of pharmacy is selected, the physician selects the execute button in step 426. The “Super Prescription” is communicated to all appropriate pharmacies that meet the patient's criteria. The bidding pharmacies return the bid with key fields completed, a unique tracking number and contact information. The system compiles the bid results and the physician's staff prints the report for the patient.

[0069] FIG. 10 illustrates the Triage Administrator, the graphical user interface for the program. There are two parts to the Triage Administrator, the Data Administrator and the Requests Administrator. The Data Administrator, located on the top portion of the Administrator application, links to MS Access databases that store the Doctors Office, Nursing Home, Pharmacy, Physician, Patients and Medication NDC Information. From the Data Administrator users can search and update the databases. Simply click on the database you would like to open and an interface menu will appear. Using this menu you can add and delete records, search for a particular record or create voice tags for entries if you do not like the current computer generated speech. The bottom half of the Triage Administrator, the Request Administrator, handles all executable functions. The Request Administrator allows users to fill prescription requests, listen to voice mail from nursing homes, print all prescription refill requests to the default printer, fill patient report requests and check the status of outgoing faxes.

[0070] FIG. 11 illustrates the Prescription Refill Request screen that displays all captured information for a refill request. The user uses one of the 5 buttons to approve the request or take another action. The system administrator can customize the text of these buttons. The user also has the option of typing a free text message in the comments box. Once the user completes the refill request the user can select the Fax Reply button to send the fax to the Pharmacy that called in the prescription refill request. The fax will be sent to the telephone number listed on the right hand side of the request labeled “Fax Number.” Alternatively, the user can select the print button and the prescription refill request will be printed to the default printer. Also, internet protocols have been added to this service which make it possible to e-mail the request.

[0071] FIG. 12 refers to the Patient Reports Request that displays all the captured information for a Patient Reports request. This form is used as the response cover sheet with the required records attached to the outgoing e-mail or fax.

[0072] FIG. 13 refers to the user interface for the New Prescription service of the Triage Administrator. The physician completes the required fields in order to generate a new prescription or “Super Prescription.” The specific steps for completing this form are detailed in the explanation of FIGS. 8A and 8B.

[0073] FIG. 14 is a block diagram of the system of the present invention. A physician's office 300 includes a server 302 and a database 304 which provides the patient's records. A PC 306 in the physician's office is connected via a link 304 to the server 302 and includes a link 306 to a printer 308 as well as a link 310 to a PDA 312. The link 310 to the PDA 312 maybe a hard wire connection or a wireless connection. The server 302 includes an internet interface 314 and a telephone company interface 316. A third party site 318, such as a pharmacy, hospital, emergency room or other physician site, is shown to include a personal computer 320 and a phone 322. The personal computer 320 includes an internet interface 324 for connection to the internet 326. The phone 322 includes a telephone company interface 328 for connection to telephone lines 330, as is known in the art. In this matter, the third party may gain access to the interactive voice response system resident in the server 302 in the physician's office 300. A report may be sent by the physician's office via the internet to the third party PC 320. The third party PC 320 may include a fax and/or email server.

[0074] In the alternative, the physician's office may omit the server 302 and database 304. Rather, the physician's office may obtain patients' record on the server 332 and database 334 of the database provider 336. The physician's office may gain access to the database 334 via the internet interface 338. The third parties may obtain records from the database provider 336 via telephone company interface 340.

In the embodiment wherein the physician's office does not include a server and database, the office PC 306 may include the internet and telephone company interfaces 314, 316.

[0075] In the embodiment wherein the server 302 and database 304 are resident at the physician's office, it will be apparent that the link 304 may be a network for coupling to multiple pc's located throughout the physician's office.

[0076] While the preferred embodiment of this invention has been shown and described, it will be apparent to those skilled in the art that changes and modifications may be made therein without departing from the spirit of the invention, the scope of which is defined by the appended claims.