WO2001045774A1

WO2001045774A1 - Adverse drug event monitoring

Info

Publication number: WO2001045774A1
Application number: PCT/US2000/030197
Authority: WO
Inventors: M. Elizabeth Mroz; Robert J. Kennelly
Original assignee: Catharsis Medical Technology, Inc.
Priority date: 1999-12-22
Filing date: 2000-11-01
Publication date: 2001-06-28
Also published as: AU1453901A

Abstract

Systems and methods for monitoring the administration of substances to patients generally utilize at least one input device for forwarding information about the substances being administered by at least one infusion pump. At least one communications device packages and sends data received from the infusion pumps and information from the input devices to a central computer system. The central computer system determines if the substances being administered could potentially harm the patient.

Description

ADVERSE DRUG EVENT MONITORING

Cross-Reference to Related Cases

This claims priority to and the benefit of provisional U.S. patent application serial number 60/171,537, filed on December 22, 1999, the entire disclosure of which is hereby incorporated by reference herein.

Technical Field This invention relates to drag administration and, more particularly, to monitoring drug administration to help prevent adverse drug events.

Background Information Adverse drag events can lead to the paralysis or even death of a patient in the care of a health care facility. In general, adverse drug events include drag over and under dosages, drag disease interactions, known drag allergies, and drag food interactions. The prevention of adverse drug events is of interest to health care facilities that aim to provide high quality service to their patients. Adverse drag events have led to the development of various drag interaction databases. These databases are typically used to catch problems with ordered medications. In general, the cost of medical care is affected by adverse drag events. Studies have shown the direct cost of preventable adverse drug events in a 700-bed tertiary care hospital can be as great as $2.8 million dollars annually.

Summary ofthe Invention The invention relates to monitoring the administration of substances to patients to provide real-time checking ofthe administration. The invention generally allows health care facilities to use existing capital resources and infrastructure to provide adverse drag event monitoring. This invention thus addresses the economic and installation issues faced by health care facilities that attempt to remedy the adverse drag event problem.

The invention relates to allowing health care facilities to reduce a number of adverse drag events by providing real-time monitoring of substance administrations to patients. Generally, the patient's known allergies and medical condition will be used in conjunction with an adverse drag event database to provide alerts, at the time of administration, to health care professionals notifying them that the delivery ofthe substance could potentially harm the patient.

In one aspect, the invention involves a system for monitoring the administration of substances to patients. The system comprises one or more input devices, one or more communication devices, and a central computer system. The input device forwards information about the substance being administered. Also, the input device forwards information regarding the identity ofthe infusion pump administering the substance and information about the patient. The communications device receives information from the input device. The communications device also receives data from the infusion pumps through a standard communications interface. The central computer system is typically networked with each ofthe communications devices. The central computer systems receives packaged data and information from the communications devices. Some ofthe packaged data and information is stored at the central computer system. A database, containing patient information, resides at the central computer system. A second database containing information regarding adverse drag events can reside at the central computer system or elsewhere on the computer network. The central computer system provides alerts if possible harm is detected.

Embodiments according to this aspect ofthe invention can including the following features. The input device can be a bar code reader. The communications device can include electronics for packaging and forwarding, over the network, the information received from the input device, and the data received from the infusion pump to a central computer system. The standard communications interface can be a standard communications interface for medical devices such as the IEEE 1073 standard or the RS-232 standard. The central computer system can store some or all ofthe information and data received over the network in an event log and also provide alerts, if possible harm is detected, over the computer network. In another aspect, the invention involves a method for monitoring the administration of substances to patients. The method comprises a step of providing at least one infusion pump that is connectable to a communications device. A step that allows for the input of information such as the substance to be administered, information about the patient, and the infusion pump being used to administer the substance. A step where the information is passed, through a standard communications interface, to a communications device. A step where the communications device receives the information. A step where the communications device packages the information into one or more data packages. The step of transmitting the data packages to a central computer system. A step where the central computer system receives the data packages. A step of processing the data packages at the central computer system to determine if administering the substance could potentially harm the patient.

Embodiments according to this aspect ofthe invention can include the following features. The information in the inputting step is entered by scanning a bar code with a bar code reader. The standard communications interface can be a standard interface for medical device communications such as the IEEE 1073 standard or the RS-232 standard. A step for broadcasting alerts if possible harm is detected in the processing step. A step that enables a user to choose whether or not to receive the same alert again for the same patient. A step where some or all ofthe information contained in the data packages is stored in an event log at the central computer system.

Brief Description ofthe Drawings In the drawings, like reference characters generally refer to the same parts throughout the ι different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles ofthe invention.

Figure 1 A is a block diagram of an embodiment of a substance administration system according the present invention.

Figure IB is a block diagram of an embodiment of a substance administration system with an adverse drag event computer residing on a computer network according the present invention.

Figure 2 A is a block diagram of an embodiment of a central computer system for use in the substance administration system of Figure 1A.

Figure 2B is a block diagram of an embodiment of an adverse drag event computer for use in the substance administration system of Figure IB. Figure 3 shows an embodiment of an infusion pump.

Figure 4 shows an embodiment of a communications device for use in the substance administration system of Figures 1A and IB.

Figure 5 shows an embodiment of a typical health care facility room in which at least some ofthe components ofthe substance administration system typically are located. Figure 6 is a flow chart of an embodiment of an adverse drag event monitoring procedure. Figure 7 shows a screen shot from the substance administration system of Figures 1 A and IB in which patient information and an alert is displayed..

Figure 8 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a first-time login dialog box. Figure 9 shows a screen shot from the substance administration system of Figures 1 A and

IB depicting an embodiment of an administration tool login dialog box.

Figure 10 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a create a new room dialog box.

Figure 11 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a delete a room dialog box.

Figure 12 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a duplicate room number error message.

Figure 13 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a create a new patient dialog box. Figure 14 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a duplicate admissions ID number error message.

Figure 15 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a delete a patient dialog box.

Figure 16 shows a screen shot from the substance administration system of Figures 1A and 1 B depicting an embodiment of a restore a patient dialog box.

Figure 17 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a forgot room number to restore to error message.

Figure 18 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a confirming patient restoration message box. Figure 19 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a patient information editing dialog box.

Figure 20 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of an add physician medication orders dialog box.

Figure 21 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a patient information display screen. Figure 22 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a tab of an administration tool for selecting adverse drag event database servers.

Figure 23 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a tab of an administration tool for mapping substances.

Figure 24 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of an substance importation dialog box.

Figure 25 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a substance exportation dialog box. Figure 26 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a tab of an administration tool for managing users ofthe substance administration system.

Figure 27 A shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a tab of an administration tool for configuring adverse drug event options.

Figure 27B shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a tab of an administration tool for alert logging selection. Figure 28 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a tab of an administration tool for selecting which reports to create.

Figure 29 A shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of a tab of an administration tool for excluding alerts system wide.

Figure 29B shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a tab of an administration tool for displaying alerts that have been excluded system wide.

Figure 30 shows a screen shot from the substance administration system of Figures 1A and IB depicting an embodiment of a tab of an administration tool for mapping infusion pump IDs to hospital IDs. Figure 31 shows a screen shot from the substance administration system of Figures 1 A and IB depicting an embodiment of an alert display screen. Figure 32 shows a screen shot from the substance administration system of Figures 1A and IB depicting an alert acknowledgement dialog box.

Figure 33 shows a screen shot from the substance administration system of Figures 1 A and IB of depicting an embodiment of an event log.

Description

Referring to Figure 1 A, one embodiment according to the invention includes a central computer system 100. The central computer system 100 is connected to a network 500. The network 500 can be a standard Ethernet network, although other types of networks are possible. The network 500 connects the central computer system 100 to one or more communications devices 200. Each ofthe communication devices 200 is also connected to at least one input device 300 and at least one infusion pump 400.

Referring to Figure IB, one embodiment according to the invention includes a central computer system 100. The central computer system 100 is connected to a network 500. The network 500 can be a standard Ethernet network, although other types of networks are possible. The network 500 connects the central computer system 100 to one or more communications devices 200 and to an adverse drag event computer 50. Each ofthe communication devices 200 is also connected to at least one input device 300 and at least one infusion pump 400.

Referring to Figure 6, in one embodiment ofthe invention, one ofthe infusion pumps 400 is connected to one ofthe communications devices 200. This connection is established through a standard communications interface 402 such as the IEEE 1073 standard or the RS-232 standard on the infusion pump 400, and an opto-isolated RS-232 port 202 on the communications device 200. In one disclosed embodiment, once the communications device 200 and the infusion pump 400 are connected, a health care professional (e.g., a nurse) will identify the patient 450 with the input device 300. After the patient 450 has been identified, the health care professional uses the input device 300 to identify the substance 408 to be administered to the patient 450. Subsequent to identifying the substance 408, the health care professional will identify the infusion pump 400 being used to deliver the substance 408 to the patient 450. In another embodiment ofthe invention, if a substance 408 is to be administered without the use of an infusion pump 400 (e.g., orally or through a syringe), the infusion pump 400 identity can be omitted. Once the infusion pump 400 has been identified, if one is being used to administer the substance 408, the health care professional uses the input device 300 to identify the patient 450 again. All the information provided by the input device 300 is forwarded to the communications device 200.

The communications device 200 receives the information from the input device 300 and data from the infusion pump 400. For example, the communications device 200 receives data about the rate and dosage ofthe substance 408 to be administered to the patient 450 from the infusion pump 400, and information regarding the patient's 450, the substance's 408, and the infusion pump's 400 identity from the input device 300. The communications device 200 takes the data received from the infusion pump 400 and the information from the input device 300, and packages all the information and data into one or more data packages. The data packages are then transmitted to the central computer system 100. The central computer system 100 uses the patient's 450 identity received in the data packages to match the patient's 450 identity with the patient's demographics. In another embodiment, the central computer system 100 uses the patient's identity to retrieve the patient's demographics, by sending an HL7 formatted query to another database resident on the health care facility's network 500. The central computer system 100 provides at least some of the information and data from the data packages, along with the patient demographics to an adverse drag event database 102. The adverse drag event database 102 takes the information and data provided by the central computer system 100 and performs a query to determine if any ofthe substances 408 being administered could possibly harm the patient 450 based on the patient's 450 specific information or a set of generic information if patient 450 specific information is not available. If the adverse drug event database 102 determines the substance 408 being administered could possibly result in harm to the patient 450, the central computer system 100 is notified. Upon notification, the central computer system 100 will display an alert on the display unit 110 and broadcast the alert across the network 500. The alert is recorded by the central computer system 100 in an event log 114 along with other pieces of the data packages .

Referring to Figure 5, in one embodiment ofthe invention, a room in a typical health care facility (such as a patient's room in a hospital) includes one ofthe communications devices 200, at least one ofthe input devices 300, and at least one ofthe infusion pumps 400. The communications device 200 is connected to the central computer system 100 through a network 500. The input device 300 is connected to the communications device 200 through the on-board serial port 208, the communications device 200 is also connected to the infusion pump 400 through the standard communications interface 402. In one particular embodiment, the infusion pump 400 is connected to the standard communications interface 402 with the Intelligent Device Connector for RS-232 sold by Advanced Medical Information Technologies, Inc of 1891 N. Gaffey St., Suite 230, San Pedro, CA 90731. The infusion pump 400 is used to administer substances 408 to the patient 450. The patient 450 is wearing a bar coded label 406 for identification purposes. A bar code label 406 is also attached to the infusion pump 400. In one embodiment, when the bar code label 406 on the infusion pump 400 is scanned by the input device 300 certain information regarding the infusion pump 400 is stored in the event log 114, for example, the location ofthe infusion pump 400.

In one embodiment, the central computer system 100 uses the information in the event log 114 to display information (at the display unit 110) about each infusion pump 400 being used by the system. For example, the central computer system 100 can display an image representation of infusion pump 400 associated with each patient 450. Also displayed is the infusion pump 400 status (e.g. off, standby, or infusing), the infusion pump 400 identification number, a channel number for each channel infusing a substance 408, the hospital identification number for that channel, the substance 408 name being infused, the total infusion volume, and the infusion rate. In another embodiment, an asset management program running on the health care facility's network 500, can access the information in the event log 114 to provide health care professionals with real-time information regarding a specific infusion pump 400.

Referring to Figure 2 A, in one embodiment ofthe invention, the central computer system 100 comprises a central processing unit (CPU) 106, a keyboard 112, a display unit 110, a mouse 122, a network communications interface 108, an external data storage and receiving device 120, a storage media 118, memory 116, the event log 114, a patient information database 104, and a local adverse drug event database 102. In one embodiment, the central computer system 100 is an IBM or IBM compatible computer system running the Windows NT ® operating system. The external data storage and receiving device 120 can be, but is not limited to, any one ofthe following: a CD-ROM, a DVD-ROM, a tape drive, a standard disk drive, or any combination of the before mentioned. The storage media 118 can be, but is not limited to, a hard disk drive, and the memory 116 can be, but is not limited to, RAM, ROM, or a combination ofthe two.

The patient information database 104 is stored in the memory 116 and/or the storage media 118 ofthe central computer system 100. Information such as the patient number, name, room, height, weight, date of birth, gender, whether or not the patient 450 has liver disease, whether or not the patient 450 is under going dialysis, whether or not the patient 450 is pregnant or lactating, a list of medication taken by the patient 450 before being monitored by the system, a list of medication taken by the patient 450 since being monitored by the system, known allergies ofthe patient 450, any past medical history information for the patient 450, and the present diagnosis ofthe patient 450 is stored in the patient information database 104. If no specific patient 450 demographic information is available at the time of administration, the patient 450 can be stored as a generic patient. All the before mentioned information is also stored in the event log 114.

In one embodiment ofthe invention, the patient 450 information is retrieved from an existing health care facility database or record system over the network 500 through the network communications interface 108, and imported into the patient information database 104. The patient's 450 bar code label 406 is scanned by a health care professional with the input device 300. The bar code information (e.g. the patient's identification number) is forwarded to the communications device 200. The central computer system 100, processes the data packages received from the communications device 200, and uses the patient's identification number to a database or record system resident on the healthcare facility's network 500. The query can be performed, but is not limited to, using an HL7 formatted message. The information is then copied into the patient information database 104.

In another embodiment, the patient 450 information is manually entered by a health care professional through the use ofthe keyboard 11, drop down menus, and the mouse 122. The central computer system 100 maintains a list of allergies, past medical histories, and current diagnosis of patients 450 all of which are capable of being expanded by a health care professional. If the patient has any allergies, the health care professional can add them to the patient's 450 information by selecting the allergy from the list resident at the central computer system 100. If the patient 450 has an allergy not in the list, the health care professional can add it to the list by using the keyboard 112. The new allergy addition is recorded in the event log 114, and is shown in the list for future patients. The same holds true for past medical history information and present diagnosis information stored at the central computer system 100. In another embodiment, if no specific patient information is available at the time of administration, the health care professional can choose to designate the patient as a generic patient. In another embodiment, the information stored in the patient information database 104 can be accessed by other applications running on the health care facility's network 500. In one embodiment, the adverse drug event database 102 is stored in the storage media 118 and/or the memory 116 ofthe central computer system 100. In another embodiment, the adverse drug event database 102 may reside somewhere else on the network 500, such as the adverse drug event computer 50. The adverse drag event database 102 provides a real-time check to determine if the substance 408 being administered to the patient 450 could potentially harm the patient 450 based on the patient's information from the patient information database 104. The adverse drag event database 102 accepts data and information provided by the central computer system 100 from the data packages received from the communications device 200, and the patient 450 information from the patient information database 104. Referring to Figure 2B, in one particular embodiment ofthe invention, the adverse drag event computer 50 comprises a central processing unit (CPU) 56, a keyboard 53, a mouse 52, a display unit 51, a network communications interface 55, an external data storage and receiving device 54, a storage media 58, memory 57, and an adverse drug event database 102. In one embodiment, the adverse drug event computer is an IBM or IBM compatible computer running the Windows NT ® operating system. The external data storage and receiving device 54 can be, but is not limited to, any one ofthe following: a CD-ROM, a DVD-ROM, a tape drive, a standard disk drive, or a combination ofthe before mentioned. The storage media 58 can be, but is not limited to, a hard disk drive, and the memory 57 can be, but is not limited to, RAM, ROM, or a combination ofthe two. In one embodiment, the adverse drug event database 102 is the Ultimedex database. The Ultimedex database is a commercially available database sold by Micromedex of 6200 South Syracuse Way, Suite 300, Englewood, Colorado 80111-4740. The Ultimedex database is loaded into the storage media 58 and/or the memory 57 as it is read off the CD-ROM by the external storage and reading device 54. Other commercially available databases can be purchased from First Databank of 1111 Bayhill Drive, San Bruno, CA 94066 and Multum of 3200 Cherry Creek South Drive, Suite 300, Denver, CO 80209.

In one particular embodiment, the central computer system 100 provides the adverse drag event computer 50 with available patient information from the patient information database 104, and the data and information received from the communications device 200. The adverse drug event computer 50 passes all the data, information, and patient information to the adverse drug event database 102 to determine if the substance 408 could possibly harm the patient 450 if the substance 408 is administered to the patient 450. In the event harm is possible, the adverse drag event computer 50 returns a notice to the central computer system 100. Each time the data package or patient information changes for a patient 450, the central computer system 100 forwards the new data and information along with patient information from the patient information database 104 to the adverse drag event computer 50 to have the adverse drag event database 102 perform a new check. Examples of changes that result in a new check by the adverse drug event database 102 can include an increase or decrease in the rate of administration or the volume of an administration, an addition of an allergy, a change in the present diagnosis of the patient 450, or an addition to the past medical history of a patient 450. If the change results in the adverse drug event database 102 generating an alert, the central computer system 100 is notified. After receiving the alert notification, the central computer system 100 displays the alert, at the display unit 110, and broadcasts the alert over the network 500.

In one embodiment, a warning level is assigned to each alert received. The central computer system 100 provides an audible indicator and displays the alert on the display unit 110. The displayed alert provides information such as how long the alert has been active, the warning level ofthe alert, what patient 450 the alert is associated with, and a text message stating an alert is present. Figure 7 shows an example of a typical screen shot with an active alert displayed at the display unit 110.

In one embodiment, the user can mark an alert for system wide exclusion. When the alert has been cleared for exclusion, by the proper health care professionals, it will no longer be displayed at the display unit 110. This exclusion will keep the alert from being generated for any patient. Also, the central computer system 100 allows a health care professional to choose to ignore an alert for a specific patient 450 in the future. Although the alerts will not be displayed on the display unit 110 or be broadcast over the network 500, the alerts may still be stored in the event log 114.

The central computer system 100 also maintains an event log 114. In one embodiment, the event log contains information regarding events, administrations, patients 450, and alerts generated by the adverse drag event database 102. For example, each time the central computer system 100 is started or stopped the time ofthe action is stored in the event log 114. All the information for a patient 450 stored in the patient information database 104 is also stored in the event log 114. If a patient 450 is removed from or added to the system, the event is recorded in the event log 114. If a patient 450 is moved from one room to another, the move is recorded in the event log 114. The event log 114 records certain information about the substances 408 administered to the patients 450. The information includes: what patient 450 the substance 408 is for, the time the substance 408 is delivered, the name ofthe substance 408, the dosage ofthe substance 408, the units ofthe dosage, the rate time, the rate time units, the dose rate, the dose rate units, whether or not a physician order exists for the substance 408 to be administered, and the route of delivery. Additionally, the identification ofthe health care professional administering the substance 408 can also be recorded in the event log 114.

The event log 114 also tracks who logs into and out ofthe central computer system 100. The event log 114 stores what allergies are added to and removed from the central computer system 100. When an alert is generated, certain parameters about the alert are stored in the event log 114. These parameters include: time ofthe alert, the type ofthe alert, the warning level of the alert, the alert text, what patient 450 the alert is associated with, the acknowledgement state ofthe alert, and if applicable, the time the alert was acknowledged, the acknowledgement description, the user who acknowledged the alert, if the alert was designated to be ignored for the specific patient 450, if the alert was designated to be ignored system wide, and if the alert is marked for system wide exclusion in the future, once approved by the proper health care professionals. The information stored in the event log 114 can be used to generate different reports for use by health care professionals.

The central computer system 100 can generate different reports from the information stored in the event log 114. For example, a health care professional can request a report that displays all the events for a specific patient 450. The central computer system 100 can also generate a report showing all the system wide events such as startups and shutdowns. All the actions tied to a specific user can be shown in a report. A report showing all the alerts for a specific patient 450 can be generated. The central computer system 100 can also generate a report showing all the substances 408 given to a specific patient 450, and a report showing the time the substances 408 were delivered. A report showing all active patients 450 in the system can be created, as well as a report showing all the patients 450 that were deleted from the system. Also, the central computer system 100 can generate a report showing all patients 450 active or deleted from the system. Another report available to health care professionals includes all the alerts, by type, that occurred. Also, the central computer system 100 can generate a report showing all alerts that have occurred by severity, as well as a report showing all the alerts in the event log 114. The user is also able to generate custom reports.

The central computer system^'lOO is connected to a health care facility's network 500 via the network communications interface 108. The network communications interfaces 108 allows the central computer system 100 to receive data packages from a plurality of communications devices 200, thus providing a central location for monitoring patients 450. The network communications interface 108 allows the central computer system 100 to access other network resources. For example, patient information can be retrieved from an existing health care facility database or record system and copied into the patient information database 104. In one embodiment, the central computer system 100, in addition to sending information and data to the adverse drag event database 102, sends information and data out on the network 500 to a health care facility's pharmacy. In the pharmacy, a check is performed to see if the substance 408 to be administered to the patient 450 was ordered by a health care professional through the pharmacy. If an order for the substance 408 does not exist in the pharmacy, an alert is sent back to the central computer system 100. The alert is displayed at the display unit 110, broadcast on the network 500, and recorded in the event log 114.

Also, the network communications interface 108 allows other applications on the health care facility's network 500 to access information stored at the central computer system 100. In one embodiment, the information stored in the patient information database 104 and the event log 114 can be accessed by a hospital records system. This information can be copied from the central computer system 100 into the health care facilities electronic records system. This will allow health care facilities to maintain detailed records of all patients 450 cared for in their facility. In another embodiment, the information and data stored in the event log 114 can be accessed or sent to a pharmacy record system on the network 500. The information and data stored in the event log 114 can be used to help maintain accurate inventory records, and track the usage of substances 408 prescribed by health care professionals.

Referring to Figure 3, in one embodiment, an infusion pump 400 is used to administer substances 408 to a patient 450. The infusion pump 400 is connected to the communications device 200 through the standard communications interface 402. In one embodiment, the standard communications interface is the RS-232 standard. In another embodiment, the standard communications interface is the IEEE 1073 standard. Through this interface, the infusion pump 400 forwards data to the communications device 200. The bar code label 406 is used to associate the infusion pump 400 with the patient 450, and the substance 408 being administered. The input device 300 scans the bar code label 406 and forwards the information to the communications device 200. In one embodiment, the substance 408 to be administered also contains a bar code label 406. The input device 300 scans the bar code label 406 ofthe substance 408 and forwards the information to the communications device 200.

Referring to Figure 4, in one embodiment, the communications device 200 packages the information from the input device 300, and the data from the infusion pump 400. The communications device 200 comprises a driver library 206, a plurality of opto-isolated RS-232 ports 202, a high speed Plug and Play Ethernet interface 204, and an on-board serial port 208 compliant with the RS-232 standard. In one particular embodiment, the communications device 200 is the commercially available Universal Data Acquisition System sold by Advanced Medical Information Technologies, Inc of 1891 N. Gaffey St., Suite 230, San Pedro, CA 90731. The infusion pump 400 is connected via the standard communication interface 402 to an opto-isolated RS-232 port 202 on the communications device 200 by the Intelligent Device Connector for RS- 232 also sold by Advanced Medical Information Technologies. When an infusion pump 400 is attached to an opto-isolated RS-232 port 202 the communications device 200 will determine what driver is necessary to communicate with the infusion pump 400. The driver library 206 houses the drivers necessary to communicate with the infusion pump 400. The input device 300 is connected to the on-board serial port 208.

In another embodiment, devices in addition to the one or more infusion pumps 400 are connected to the communications device 200. For example, devices such as ventilators, patient monitors, and electrocardiogram machines are connected to the communication device 200 through the opto-isolated RS-232 port 202. These devices communicate data about the patient 450 to the communications device 200. The drivers needed for communicating with the communications device 200 are stored in the driver library 206. In one embodiment, the driver library 206 also includes the driver necessary to communicate with the devices listed above using the IEEE 1073 standard. The data provided by these devices combined with the data from the infusion pump 400 allows health care professionals to evaluate the effectiveness ofthe substance 408 administrations. This data can be used by health care professionals to assist in developing clinical pathways, in determining allergic reaction profiles, and for determining the effectiveness ofthe substances 408 being administered.

Figures 8-35 disclose a particular embodiment ofthe invention and more particularly show screen shots from a software system resident and executing at the central computer system 100. The screen shots are visible to the user (e.g., a nurse and/or a computer system administrator depending on the type of screen) on the display unit 110. The software system comprises a monitoring portion and an administration portion that combined are capable of performing all ofthe functionality described herein. The software system is available from Catharsis Medical Technologies, Inc. of P.O. Box 622, Moultonboro, NH 03254 as PatientGuard™. The software system is coded in the C++ programming language, although other programming languages can be used to code the system and perform the functions described herein. Generally, Figures 10-21, 31, and 32 relate to the monitoring portion ofthe software system, and Figures 9 and 21-30 relate to the administration portion ofthe software system. Figures 8 and 33 relate to both the administration and monitoring portions ofthe software system. The software system can be stored, for example, on the media 118, the memory 116, or split between the two pieces ofthe central computer system 100, and executed by the CPU 106. The software system can be delivered to the central computer system 100 through the external storage and reading device 120, or over the network 500 through the network communications interface 108.

Figure 8 depicts a screen shot ofthe interface used to create the first user account ofthe software system executing at the central computer system 100. The first user attempting to login to either the monitoring or administration portion ofthe software system will be shown the "first- time login" screen 800. The user, preferably the health care facility's computer system administrator, will chose a username and enter the username into the "username" box 802. The user must then choose a password to be associated with the username. The password is entered into the "password" box 804. The password is required to be at least 4 characters long. Once the password as been entered into the "password" box 804, the password is confirmed by re-entering the password in the "password confirmation" box 806.

Figure 21 shows a "patient information" screen 2100. The information stored in the patient information database 104 is shown to the user ofthe monitoring portion ofthe software system. Upon the first login, it is possible that no room numbers 2118 or patient display names 2120 will be available. In that case, the user will need to create a new room. From the Room menu 2148, the user will select the "create a new room" option. The user will then be shown Figure 10.

Figure 10 is the "create a new room" dialog box. The user must select a room number and input the number into the "room number" box 1002. The user must also enter their username in the "username" box 1004, and their password in the "password" box 1006. If the user does not have the appropriate privileges associated with their user account to create a new room, the user will be informed so when the user submits the request. If the user does have permission to create the new room, but the room number the user chose has already been assigned, the monitoring portion ofthe software system will display Figure 12, an error message stating the room number 1002 is already in use. The user can also remove rooms from the "patient information" screen 2100. The user must have the appropriate privileges associated with their user account to remove a room from the software system. The user should select "delete a room" from the Room menu 2148. The user will be shown Figure 11. The "delete a room" dialog box 1100 requires the user to select the room number to be deleted from the "room number" drop down list 1102. The user must also enter their username in the "username" box 1104, and their password in the "password" box

1106. The room will not be deleted unless the user has the appropriate privileges associated with their user account.

Once the user has created a room, the user can create a patient 450 to reside in that room. From the "patient information" screen 2100, the user selects the Patient menu 2146. From the Patient menu 2146, the user selects the "create a new patient" option. The monitoring portion of the software system displays Figure 13 to the user.

The "create a new patient" dialog box 1300 is used to create a new patient 450. The user inputs a patient ID number in the "patient number" box 1302, and the patient's name in the "patient name" box 1304. The user selects which room the patient 450 resides in from the "room" drop down list 1306, and the patient's 450 gender, if known, from the "gender" drop down list 1308. The user must enter their username in the "username" box 1310 and password in the "password box" 1312. The new patient will only be created if the user has the appropriate privileges associated with their user account. If the user tries to assign the patient 450 a patient number already assigned to an existing patient, the user will be shown Figure 14, an error message stating that the admissions ID already exists for a currently admitted patient 450.

The user can remove a patient 450 from the monitoring portion ofthe software system by using the "delete a patient" dialog box 1500 shown in Figure 15. This option is available under the Patient menu 2146 of Figure 21. The user selects the patient number to be deleted from the "patient number" drop down box 1502. In order to remove the patient 450, the user must input their username in the "username" box 1504, and their password in the "password" box 1506. If the user does not have the appropriate permission associated with their user account the request for patient 450 removal will not be completed. When the patient 450 is removed from the monitoring portion ofthe software system, the removal is logged in the event log 114 at the central computer system 100. This allows the patient 450 to be restored at a later date if necessary.

Figure 16 shows the results of selecting the "restore a patient" option from the Patient menu 2146 of Figure 21. The user is shown a list of all patient numbers and names deleted from the monitoring portion ofthe software system, and the time the patient 450 was deleted from the monitoring portion ofthe software system, in the "deleted patients" list 1602. The user selects the patient 450 the user wishes to restore. The user must also input their username in the "username" box 1606 and their password in the "password" box 1608. The user must also select a room to restore the patient 450 to from the "room to restore to" drop down box 1604. If the user does not have the appropriate permission associated with their user account the user will not be able to restore the patient 450. If the user forgets to select a room to restore the patient 450 to, the user will be shown Figure 17, an error message asking the user to enter the room the patient 450 is being restored to. If the user has the appropriate privileges to restore a patient 450 and the user has entered a room number for the patient 450 to be restored to, when the request is submitted the user will be shown Figure 18. Figure 18 gives the user one last chance to abort the restoration process if the user so chooses. By selecting the "yes" button 1802 from the "are you sure you want to restore" dialog box 1800 the patient 450, and all previous information for that patient 450 is restored to the room number chosen. Once a patient 450 has been created or restored, the health care professional will need to add or updated the patient's 450 known information.

Referring to Figure 21, if the user wishes to edit or update the information of a patient currently being monitored by the monitoring portion ofthe software system, the user selects a patient display name 2120 from the "actively monitoring patients" tab 2116. The user then needs to select the "edit" button 2114. Upon selecting the "edit" button 2214, the user is shown Figure 19.

Figure 19 shows the "edit patient information" dialog box 1900. Information regarding the identity ofthe patient 450 is found in the identification section 1980. The patient's identification number is displayed in the "patient number" box 1982, and the patient's 450 name is displayed in the "patient name" box 1984. Information regarding the patient's 450 known allergies can be found in the "known allergies" section 1910. A list of allergies already associated with patient 450 is shown in the "allergies" list box 1918. If a user wishes to add an allergy to the list the user can select the allergy from the "known allergies" drop down menu 1916, and select the "add an allergy" button 1914. If the substance is not in the "known allergies" drop down menu 1916, the user can type the name ofthe substance 408 the patient 450 is allergic to in the "known allergies" drop down menu 1916, and select the "add a new allergy" button 1914. The allergy is added to the "known allergies" drop down menu 1916 and to "allergies" list box 1918. The user may also remove an allergy from the patient's 450 information by selecting the allergy from the "allergies" list box 1918, and selecting the "remove an allergy" button 1912. All allergies added and removed from the patient's 450 information are logged in the event log 114. Information regarding the past medical history of the patient 450 can be found in the

"past medical history" section 1920. A list of information already describing the past medical history ofthe patient 450 is shown in the "past medical history" list box 1928. If a user wishes to add some information regarding the past medical history to the list, the user can select the description ofthe past medical history from the "known past medical history" drop down menu 1926, and select the "add past medical history" button 1924. If the past medical history description is not in the past medical history drop down menu 1926, the user can type the description ofthe past medical history, in the "past medical history" drop down menu 1926, and select the "add past medical history" button 1924. The past medical history is added to the "past medical history" drop down menu 1926 and to "past medical history" list box 1928. The user may also remove any past medical history from the patient's 450 information by selecting the past medical history from the "past medical history" list box 1928, and selecting the "remove past medical history" button 1922. Any past medical history information added and removed from the patient's 450 information is logged in the event log 114.

Information regarding the present diagnosis ofthe patient 450 can be found in the "present diagnosis" section 1930. A list of information already describing the present diagnosis ofthe patient 450 is shown in the "present diagnosis" list box 1938. If a user wishes to add some information regarding the present diagnosis to the list, the user can select the description ofthe present diagnosis from the "present diagnosis" drop down menu 1936, and select the "add present diagnosis" button 1934. If the present diagnosis description is not in the "present diagnosis" drop down menu 1936, the user can type the name ofthe present diagnosis, in the "present diagnosis" drop down menu 1936, and select the "add present diagnosis" button 1934. The present diagnosis is added to the "present diagnosis" drop down menu 1936 and to "present diagnosis" list box 1938. The user may also remove any present diagnosis from the patient's 450 information by selecting the present diagnosis from the "present diagnosis" list box 1938, and selecting the "remove present diagnosis" button 1932. Any present diagnosis information added and removed from the patient's 450 information is stored in the event log 114. A history of substances 408 received by the patient 450 prior to being monitored by the software system can be found in the "patient medications" section 1940. A list of substances 408 already administered to the patient 450 is shown in the "medications" list box 1946. If the user wishes to add a substance 408 the patient 450 received prior to being monitored by the software system, the user may do so by selecting the "add a patient medication" button 1942. If the user wishes to remove a substance 408 from the "medications" list box 1946, the user may do so by selecting the substance 408 from the "medications" list box 1946 and selecting the "remove a medication" button 1944. All additions and removals of substance 408 information are recorded in the event log 114.

A history ofthe substances prescribed to the patient 450 since being monitored by the software system is displayed in the "physician medication orders" section 1950. A list of substances 408 already prescribed to the patient 450 since being monitored by the system is shown in the "ordered" list box 1956. If the user wishes to remove a substances 408 from the "ordered" list 1956, the user selects the ordered substance 408 from the "ordered" list box 1956, and selects the "remove" button 1954. If the user wishes to add a substance 408 to the "ordered" list 1956, the user selects the "add" button 1952. The user is shown Figure 20, once the "add" button 1952 has been selected.

Referring to Figure 20, the "add physician medication order" dialog box 2000 allows the user to input the set of administration parameters for a substance 408 ordered by a health care professional to be administered. The user can select the name ofthe substance from the "medication" drop down menu 2004. If the user does not know the full name ofthe substance 408, the user may type in a part ofthe name and select the "search" button 2002. The results of the search are shown in the "search results" box 2006. The user then selects the proper substance 408 name from the returned results. The user also selects a route for the delivery ofthe substance 408 from the "route" drop down menu 2008. The user also defines the dosage by typing the dosage in the "dosage" box 2010, and selecting the units from the "dosage units" drop down menu 2012. If the substance is to be administered by an infusion pump 400, the user also must define the dose rate by typing the dose rate in the "dose rate" box 2016 and selecting the units from the "dose rate" units drop down menu 2016, and the rate time by typing the rate time in the "rate time" box 2018 and the selecting the units from the "rate time units" drop down menu 2020.

Referring back to Figure 19, general information regarding the patient can be found in the "general information" section 1960. If no specific information is available for the patient 450, the user has the option of designating the patient 450 as a generic patient by selecting the "generic patient" check-box 1961. When the adverse drug event database 102 performs a check on the substance 408 being administered and the "generic patient" check-box 1961 is selected, the adverse drug event database 102 will typically generate more alerts than when specific patient information is present. Specific information regarding the patient 450 can be added as it becomes available to the user. If the user does not specify specific patient information or select the "generic patient" check-box 1961, the adverse drag event database 102 will typically generate the most alerts, because the adverse drag event database will assume the patient is zero years old and weighs zero pounds. A new check is performed each time specific patient information is added or changed in the "general information" section 1960.

Referring to Figure 31, to view the alerts generated by the adverse drag event database 102 or by the software system itself, the user selects the "enunciations" tab 3102 from the "patient information" screen 2100. In addition to the adverse drag event database 102 generating alerts for harmful drug interactions, or an unknown drag being administered, the software system can generate alerts when it detects the failure of an infusion pump 400, the communications device 200, the input device 300, or the network 500 causing communications with the adverse drug event computer 50 to cease. If there are active alerts, the "warning box" 3118 is displayed to the user. A list of all unacknowledged alerts is displayed in the "alert list" 3104. If the user selects an alert from the "alert list" 3104, specific information regarding the alert is displayed in the "alert information" box 3112. The monitoring portion ofthe software system also displays the patient number in the "patient number" box 3106, the patient's name in the "name" box 3108, the room number where the alert was generated in the "room number" box 3110 and the total time the alert has been active in the "time box" 3114. If the user wishes to acknowledge the alert, the user selects the "acknowledge" button 3116. When the user selects the "acknowledge" button 3116, the monitoring portion ofthe software system displays Figure 32.

Figure 32 allows the user to remove the alert from the "active alert" list 3104. The user types in a reason for acknowledging the alert in the "reason" box 3202. If the user wishes to ignore this alert in the future for this patient only, the user checks the "ignore for this patient only" check-box 3204. If the user wants to nominate this alert to be excluded in the future for all patients, the user checks the "system wide ignore" check-box 3206. In order for the alert to be removed from the active alerts list 3104, the user must enter their username in the "username" box 3208 and their password in the "password" box 3210. If the user does not have the appropriate permission associated with their user account to remove active alerts, the alert will remain in the "active alerts" list 3104.

The administration portion ofthe software system allows the user to configure certain parameters that control the behavior ofthe software system. The configuration is accomplished through the use ofthe administration tool. The administration tool allows the user to configure items such as the adverse drag event database 102 to be used, it provides the ability to import and export standard drag names and create custom ID's for drags, it allows for other user accounts to be created and privileges for the user accounts to be set, it allows the user to deteπnine what types of adverse drag interactions will be checked for, it allows the user to generate different reports from information contained in the event log, it allows for the configuration of alerts to be ignored system wide, and it allows for infusion pump IDs to be mapped to hospital pump IDs. Access to the administration portion ofthe software system is controlled by a separate login procedure.

Referring to Figure 9, when a user wishes to change the way a portion ofthe software system is configured the user must login into the administration portion ofthe software system. In order to login to the administration portion ofthe software system, the user must provide the "administration tool login" screen 900 with a username in the "username" box 902, and a password in the "password" box 904. If the user does not have the appropriate permission associated with their user account to access the administration portion ofthe software system, the user will not be allowed to login. If the user has permission to access the administration portion ofthe software system, the user will be granted access and shown Figure 22.

Referring to Figure 22, the user has the ability to choose an adverse drug event database 102 by selecting the "ADE-DB servers" tab 2202 from the "administration tool" dialog box 2200. The user is able to select from one or more server types using the "server type" drop down menu 2204. The user should also provide the server's name in the "server name" box 2206. Referring to Figure 23, the administration tool provides the user with an interface to import NDC drug names for use by the monitoring portion ofthe software system, and also to export NDC drag names for use by other applications running on the health care facility's network 500. This interface also provides the user with the ability to map the NDC name to a custom name within the monitoring portion ofthe software system. The user selects the "map drags" tab 2302 from the administration tool dialog box 2200. If no drags names are present in the "drug names" section 2310, the user should choose the "import NDC/drag names list" button 2330. Upon choosing the "import NDC/drag names list" button 2330, the user will be shown Figure 24.

Figure 24 depicts the "import drag names" dialog box 2400. If the user knows the path to where the drag names are located on the central computer system 100, the user may type the path into the "path" box 2402. If the user does not know the specific location ofthe drag names, the user may select the "browse" button 2408. When the user has located the file containing the drag names the user must next select whether the file is a comma separated file or a tab delimited file. This is done by selecting either the "comma separated" radio button 2204 or the "tab delimited" radio button 2206. Once all the proper selections have been made, the user should select the "start" button 2210 to begin the importation process. Once the process is complete the user should be returned to Figure 23.

If the user wishes to export the NDC/drug name list from the central computer system 100, the user may due so by selecting the "export NDC/drag names list" button 2340 from the "administration tool" dialog box 2200. If the user knows the path to where the drag are to be exported to, the user may type the location into the "path" box 2502. If the user does not know the specific path to where the drug names are being exported to, the user may select the "browse" button 2508. When the user has located the place to export the drug names the user must next select whether the file is to be comma separated file or a tab delimited file. This is done by selecting either the "comma separated" radio button 2204 or the "tab delimited" radio button 2206. Once the proper selections have been made, the user should select the "start" button 2210 to begin the exportation process. Once the process is complete the user should be returned to Figure 23.

Referring to Figure 26, if the user wishes to add another user to the software system, or edit an existing user's privileges, the user should select the "users" tab 2602 from the "administration tool" dialog box 2200. A current list of all users assigned privileges to use the software system are shown in the "user" list 2652, in the "system users" section 2650. To add a new user to the software system, the current user selects the "new" button 2654. The current user then inputs a username in the "username" box 2612, the user's real name in the "real name" box 2610, a password for the new user account in the "password" box 2616, the same password in the "password confirmation" box 2618, and selects a user type from the "user type" drop down menu 2620. When all the information has been added, the current user selects the "save" button 2624, and the new user is created. If the current user wishes to edit information for an existing user, the current user selects the username from the "user" list 2652, and then selects the "edit" button 2656. The current user then edits the information in the "user information" section 2610. When the current user has finished changing the information, the user selects the "save" button 2624. If the current user wishes to delete a user from the software system, the user selects the username from the "user" list 2652, and selects the "delete" button 2656.

Referring to Figure 27A, the user has the ability to control what types of adverse drag interactions the adverse drug event database 102 checks for. Selecting the "configuration" tab 2702, ofthe "administration tool" dialog box 2200, brings the user to the "adverse drμg event configuration" interface 2700. The user then selects the "ADE options" tab 2704. The user can select which checks will be performed on the data and information provided to the adverse drug event database 102 by selecting the check-boxes 2710. The user can also determine what level of alerts will be reported back to the central computer system 100 from the adverse drag event database 102 by selecting the level from the "warning level drop" down boxes 2720. The user also has the option of turning off the alert logging feature ofthe monitoring portion ofthe software system. Referring to Figure 27B, by selecting the "logging options" tab 2706 the user can turn off the logging feature by selecting the check-box 2710.

Referring to Figure 28, the administration portion ofthe software system contains the ability to generate reports based on a number of specific topics, as well as customized reports. From the "administration tool" dialog box 2200, the user selects the "reports" tab 2802. The user has the choice of selecting the "event log" tab 2810, the "patient" tab 2812, the "enunciation" tab 2814, or the "medication" tab 2816. When the user has selected the appropriate tab, the user can select a report to be generated from the "report type" drop down menu 2820. Once the user has made their choice, the user should select the "generate report" button 2830 to begin the report generation process. Referring to Figure 29 A, the monitoring portion ofthe software system can be configured to ignore certain alerts generated by the adverse drag event database 102. A list of alerts nominated for system wide exclusion can be seen by selecting the "administer enunciations" tab 2902 from the "administration tool" dialog box 2200. The alerts nominated for system wide exclusion are displayed in the "nominated enunciations" list 2810 located on the "nominated enunciations" tab 2904. If the user wishes to exclude the alert system wide the user selects the alert in the "nominated enunciations" list 2810 and selects the "ignore" button 2814. If the user does not wish to exclude the alert system wide the user selects the "veto" button 2812. If the user wishes to see a list of alerts that are presently excluded system wide, the user selects the "ignored enunciations" tab 2906. A list of ignored alerts is displayed in the "ignored alerts" list 2820. The user can remove an alert from system wide exclusion by selecting the alert in the "ignored alerts" list 2820 and then selecting the "remove" button 2822. The administration portion ofthe software system allows the user to map an infusion pump ID to hospital pump ID by selecting the "pump mapping" tab 3002 from the "administration tool" dialog box 2200. The infusion pumps 400 mapped in the system are shown in the "pump" list 3004. If the user wishes to delete an existing mapping, the user selects the infusion pump 400 from the "pump" list 3004 and then selects the "delete" button 3016. If the user wishes to edit an existing mapping, the user selects the infusion pump 400 from the "pump" list, and then selects the "edit" button 3020. The user can then change the channel number by using the "channel selection" buttons 3022 or change the hospital ID by typing the new hospital ID in the "hospital pump ID" box 3008. The user can create new mappings by selecting the "new" button 3018. The user can then enter the infusion pump ID in the "pump ID" box 3006, the hospital ID in the "hospital pump ID" box 3008, select the proper channel number, and select the "save" button 3010.

Both the administration and monitoring portions ofthe software system record events in the event log 114. Both the administration and monitoring portions ofthe software system can view the event log 114. Figure 33 depicts an instance ofthe event log 114. The event log 114 shows the time the event occurred in the "time" column 3302, the event type in the "type" column 3304, the user who caused the event in the "user" column 3306, and a brief description ofthe event in the "event" column 3308. If the user is viewing the event log 114 and wishes to see if any events have taken place since the user began viewing the event log 114, the user can select the "refresh" button 3310 and the event log will display all events that have occurred up until the time the refresh button 3310 was selected. Variations, modifications, and other implementations of what is described herein will occur to those of ordinary skill in the art without departing from the spirit ofthe invention. Accordingly, the invention is not to be defined solely by the preceding illustrative description.

What is claimed is:

Claims

CLAIMS 1. A system for monitoring the administration of substances to patients, comprising: at least one input device, each ofthe input devices for forwarding information about at least one substance for administration to a particular patient by at least one infusion pump; at least one communication device, each ofthe communication devices coupled to at least one ofthe input devices for receiving the information forwarded by the at least one input device, each ofthe communication devices also coupled to at least one ofthe infusion pumps to receive data about the administration ofthe at least one substance to the particular patient through a standard communications interface; and a central computer system coupled to each ofthe communication devices by a computer network, the central computer system for receiving the information and data from the communication devices, the central computer system storing at least some ofthe received information and data and accessing at least a first local database and a second database to identify and provide alerts about possible harm to the patients due to the administration ofthe substances, the first local database including information about at least one ofthe patients, and the second database including information about adverse drug events.

2. The system of claim 1 wherein at least one ofthe input devices comprises a bar code reader.

3. The system of claim 1 wherein at least one ofthe communications devices comprises electronics for packaging the information and data and then forwarding the packaged information and data to the central computer system over the computer network.

4. The system of claim 1 wherein the standard communications interface comprises a standard interface for medical device communications.

5. The system of claim 4 wherein the standard interface for medical device communications comprises the IEEE 1073 communication standard.

6. The system of claim 4 wherein the standard communications interface comprises the RS- 232 standard.

7. The system of claim 1 wherein at least some ofthe received information and data is written into an event log by the central computer system.

8. The system of claim 7 wherein the central computer system uses the event log to maintain a history of at least the at least one substances administered to the patient.

9. The system of claim 1 wherein the central computer system provides at least one alert if an adverse drug event is detected.

10. The system of claim 9 wherein the central computer system provides the at least one alert by broadcasting the at least one alert over the computer network.

11. The system of claim 10 wherein the central computer system comprises a user interface for allowing a user to choose not to broadcast the at least one alert.

12. A method for monitoring the administration of substances to patients, comprising: providing at least one infusion pump for connection to a communication device, the at least one infusion pump for delivering at least one substance to a patient; allowing the input of information about the patient, the at least one substances to be delivered, and the at least one infusion pump; passing the information to the communication device through a standard communications interface; receiving the information at the communication device; packaging the information into data packages at the communication device; transmitting the data packages to a central computer system; receiving the data packages at the central computer system; and processing the data packages at the central computer system to identify possible harm to the patient due to the delivery ofthe at least one substance.

13. The method of claim 12 further comprising the step of broadcasting at least one alert if the processing step identifies harm to the patient due to the delivery ofthe at least one substance.

14. The method of claim 13 further comprising the step of providing the ability to choose not to display the alert on subsequent administrations ofthe same at least one substance.

15. The method of claim 13 further comprising the step of recording at least some of the information contained in the data packages in an event log at the central computer system including the dosage ofthe at least one substance and the time and date of administration ofthe at least one substance.

16. The method of claim 12 wherein the inputting step comprises scanning a bar code by a bar code reader.

17. The method of claim 12 wherein the standard communications interface comprises a standard interface for medical device communications.

18. The method of claim 17 wherein the standard interface for medical device communications comprises the IEEE 1073 communications standard.

19. The method of claim 17 wherein the standard communications interface comprises the RS-232 standard.