JP7126396B2 - Method and apparatus for electronic drug order transfer and processing - Google Patents

Description

(reference)
This application is incorporated by reference into: U.S. Patent Application Serial No. 10/040,887 (filed January 7, 2002); U.S. Patent Application Serial No. 10/040,908 (filed January 7, 2002; -2003-0130624-A1 (published July 10, 2003); U.S. Patent Application Serial No. 10/059,929 (filed January 29, 2002, publication number U.S. Patent Application Serial No. 10/135,180 (filed April 30, 2002); U.S. Patent Application Serial No. 10/424,553 (filed April 28, 2003); No. 10/659,760 (filed Sep. 10, 2003); U.S. patent application Ser. No. 10/749,101 (filed Dec. 30, 2003); U.S. patent application Ser. No. 10/748,762 (filed Dec. 30, 2003); U.S. patent application Ser. No. 10/748,749 (filed Dec. 30, 2003); U.S. patent application Ser. No. 10/749,099 (filed Dec. 30, 2003); US patent application Ser. No. 10/748,589 (filed Dec. 30, 2003); US provisional patent application Ser. Application No. 60/376,625 (filed April 30, 2002); U.S. Provisional Application No. 60/376,655 (filed April 30, 2002); U.S. Provisional Application No. 60/444,350 (filed February 1, 2003); U.S. Provisional Application No. 60/488,273 (filed July 18, 2003); U.S. Provisional Application No. 60/528,106 (filed December 8, 2003) ); and U.S. Pat. No. 5,842,841, which is expressly incorporated and made a part hereof.

(Technical field)
The present invention relates generally to wireless medical data communication systems and methods. More particularly, the present invention relates to systems and methods for reporting on the integrity of wireless communication links.

(Background of the invention)
A patient care system generally includes a computer network, medical equipment for treating a patient, and controls for the medical equipment. Although patient care systems have improved through the use of computer-controlled automated systems and methods, patient care systems still rely heavily on manual data management processes for medical devices and their control. For example, in modern hospitals, nursing stations are commonly connected to a computer network, but it is unusual for the computer network to extend into patient rooms. Computer networks offer opportunities for automated data management processes, including point-of-care operation and monitoring of medical devices and control of medical devices. Despite progress in this area, automated data management technology has been underutilized for point-of-care applications due to the lack of more efficient systems and methods. As our reliance on automated technology increases, so does the need to provide users with the ability to determine the operating state of a system or subsystem.

(Outline of invention)
The present invention provides systems and methods for reporting on the integrity of wireless communication links within a healthcare facility.

Generally, the present invention includes a system having a medication management module and a wireless remote device located within a healthcare facility. A medication management module is associated with a medication application device, such as an infusion pump. The wireless remote device includes message display means, such as a visual display or an audible alarm, responsive to status information output generated by the medication administration module and transmitted over the wireless communication link. The wireless remote device also includes a module or application that generates timeouts when the wireless communication link is lost.

Other systems, methods, features and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included herein within the scope of the present invention and protected by the accompanying claims.

(Brief description of the drawing)
The invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed on clearly illustrating the principles of the invention. In the drawings, the same reference numbers indicate corresponding parts throughout the several figures.
1 is a schematic representation of a patient care system; Patient care systems include pharmacy computers, central systems, and digital assistants at points of care. 2 is a block diagram of a computer system representing the pharmacy computer, central system, and/or digital assistant of FIG. 1; FIG. The system includes an injection system or portion thereof. 2 is a schematic diagrammatic representation of portions of the patient care system of FIG. 1; 2 is a block diagram showing functional components of the patient care system of FIG. 1; FIG. 2 is an exemplary computer screen for performing various functions of the patient care system of FIG. 1; 3 is a block diagram showing functional elements of the injection system of FIG. 2; FIG. Functional elements include blocks for infusion system parameter setting, infusion order creation, infusion order preparation, drug administration, infusion order modification, and messaging, among others. FIG. 7 is a block diagram showing functional elements for setting infusion system parameters of FIG. 6; FIG. 7 is a block diagram showing functional elements for infusion order generation of FIG. 6; FIG. 7 is a block diagram showing functional components for infusion order preparation of FIG. 6; FIG. 7 is a block diagram showing functional elements for drug delivery of FIG. 6; FIG. 7 is a block diagram showing functional elements for infusion order documentation, infusion order modification, and messaging of FIG. 6; 1 is a diagram of an emergency notification system showing communications; FIG. FIG. 2 is a diagram of an emergency notification interface from the notifying party's perspective, showing the preferred notification options provided to the notifying party by the emergency notification system; FIG. 4 is a diagram of an emergency notification interface from the target party's perspective, showing preferred emergency information received by the target party; Figure 10 is one embodiment of a flowchart of an alarm/alert escalation process; FIG. 10 is a diagram of an alarm/alert interface screen; FIG. 11 is another view of an alarm/alert interface screen; FIG. 11 is another view of an alarm/alert interface screen; FIG. 12 is a view of the interface screen as seen from the clinician's handheld device; FIG. 10 is a diagram of an interface screen of the login process; FIG. 20 is a diagram of another interface screen for the login process of FIG. 19; FIG. 11 is a diagram of a department selection interface screen; FIG. 11 is a diagram of a shift selection interface screen; FIG. 12 is a view of a patient view interface screen; FIG. 11 is a view of a patient selection interface screen; FIG. 11 is a diagram of a patient information menu interface screen; FIG. 12 is a view of an allergy-height/weight interface screen; FIG. 12 is a view of a medication history interface screen; FIG. 12 is a diagram of a test results interface screen; FIG. 11 is a view of a medication delivery schedule interface screen; FIG. 27 is another view of the interface screen of the Schedule Medication Delivery step of FIG. 26 ; FIG. 13 is a diagram of a stop workflow injection interface screen. FIG. 12B is another view of the interface screen of the stop workflow infusion. FIG. 10 is a diagram of an interface screen of a workflow for resuming an infusion. FIG. 10 is a diagram of an interface screen of a workflow for resuming an infusion . FIG. 27 is another view of the interface screen of the Schedule Medication Delivery step of FIG. 26; FIG. 11 is a view of a medication failure interface screen; FIG. 30 is another view of the interface screen of FIG. 29; FIG. 30 is another view of the interface screen of FIG. 29; FIG. 11 is a diagram of a schedule interface screen; FIG. 11 is a diagram of a medication interface screen; Fig. 10 is a view of a scan interface screen; FIG. 12 is a diagram of another scan interface screen; FIG. 11 is a view of a medication administration interface screen; Fig. 10 is a view of a route confirmation interface screen; FIG. 12 is a diagram of a pump channel scan interface screen; FIG. 12 is a diagram of another pump channel scan interface screen; FIG. 10 is a diagram of a comparison interface screen; FIG. 11 is another view of a comparison interface screen; FIG. 11 is another view of a comparison interface screen; FIG. 11 is another view of a comparison interface screen; FIG. 11 is another view of a comparison interface screen; FIG. 11 is a diagram of a pump status interface screen; FIG. 11 is a view of a flow rate history interface screen; FIG. 11 is a view of a communication loss interface screen; FIG. 11 is a view of a communication loss interface screen; FIG. 11 is a view of a low battery interface screen; Fig. 3 is a diagram of a hub; FIG. 3 is a diagram of various icons used in interface screens; FIG. 11 is a view of an implementation result recording interface screen; FIG. 10 is a diagram of a medication order with monitoring parameters link; FIG. 10 is a view of a monitoring parameter input interface screen; FIG. 11 is a diagram of a cycle count interface screen; 10 is a flow chart of an order comparison process; 1 is a schematic diagram of a flow control system with micro-electro-mechanical system (MEMS) elements connected to a circuit set; FIG. Figure 4 is a schematic block diagram of software components loaded on the first central computer of Figure 3; 4 is a flow chart of an exemplary injection implementation process; 4 is a flow chart of an exemplary injection implementation process; 4 is a flow chart of an exemplary injection implementation process; Fig. 4 is a flow chart of an exemplary channel scanning process; 4 is a flow chart of an exemplary pump channel change process; 4 is a flow chart of an exemplary pump channel change process; FIG. 4 is a flowchart of another exemplary channel scanning process; FIG. FIG. 5 is a flow chart of yet another exemplary channel scanning process; FIG. 4 is a flow chart of an exemplary infusion stop/stop process; 4 is a flow chart of an exemplary reinfusion process; 4 is a flow chart of an exemplary pump removal process; 4 is a flowchart of an exemplary authentication process; 4 is a flowchart of an exemplary authentication process; 4 is a flowchart of an exemplary authentication process; 4 is a flowchart of an exemplary authentication process; 4 is a flowchart of an exemplary authentication process; 4 is a flowchart of an exemplary authentication process; 4 is a flowchart of an exemplary authentication process;

(detailed explanation)
While the invention is capable of embodiment in many different forms, preferred embodiments of the invention are shown in the drawings and will be described in detail herein. This disclosure should be considered as an exemplification of the principles of the invention and is not intended to limit the broad aspects of the invention to the illustrated embodiments.

FIG. 1 is a diagrammatic representation of a patient care system. In one embodiment, patient care system 100 includes pharmacy computer 104 , central system 108 , and treatment location 106 linked by network 102 . As shown in FIG. 2, patient care system 100 also includes infusion system 210, also referred to as a medical system. The infusion system 210 is preferably a computer program, particularly a module or application (i.e., a program or group of programs designed for the end user) residing on one or more electronic computing devices within the patient care system 100. A dosing system implemented as As described in further detail herein, infusion system 210 links clinicians, such as physicians, pharmacists, and nurses, in a multidisciplinary approach to patient care.

(general system)
Turning to FIG. 3 to illustrate this, patient care system 100 may include multiple medical devices 120 . In one embodiment, the medical device is an infusion pump 120 . Additionally, in another embodiment, the medical device is a controller for an infusion pump. For ease of reference, this disclosure generally identifies the medical device of the system as an infusion pump, but the overall system 100 may incorporate any one or more of a variety of medical devices. is understood. Thus, as shown in FIG. 3, multiple infusion pumps 120 are connected to hub or interface 107 . As described in further detail herein, infusion pumps 120 may be of conventional design, with each infusion pump 120 being associated with a single patient. However, as those skilled in the art will appreciate, the infusion pumps 120 shown in FIG. 3 need not be associated with the same patient or treatment site even though they are connected to the same hub 107 . Additionally, each infusion pump 120 may be a single channel pump or a multi-channel pump, such as a three-channel pump . In general, pumps periodically transmit messages containing pump status information to hub 107 . To centralize communications cost-effectively and/or allow for redesign of existing medical devices not currently communicating with the central computer system 108 so that each such medical device communicates with the central computer system 108. A separate hub 107 can be used remotely from the medical device 120 so that it can communicate.

(Communication hub for the entire system)
In one embodiment, a serial port or other I/O port of infusion pump 120 is connected to hub 107 using a conventional non-wireless transmission medium 105 such as twisted wire pair, coaxial cable, fiber optic cable, or the like. Hub 107 can preferably be connected to multiple infusion pumps 120 or only one pump via one-way serial communication link 105 . Hub 107 receives signals from connected pumps and regenerates received signals. Specifically, the received signal from pump 120 is converted by hub 107 into a form suitable for transmission to system network 102 over wireless channel or link 128 and wired communication system 110 . In general, hub 107 transmits pump data to system network 102 . Hub 107 may also filter information received from pumps 120 to prevent duplicate messages. Further, hub 107 allows remote viewing of pump status information on digital assistant 118 of clinician 116 . In general, hub 107 transmits pump data whenever hub 107 is connected to pump 120 and both hub 107 and pump 120 are powered on. As will be described in detail herein, hub 107 also allows comparison of pharmacy-entered orders with pump settings. In a preferred embodiment, hub 107 is connected to an IV pole that supports pump 120, or hub 107 is incorporated within infusion pump 120 to create the integrated medical/communication device identified above. .

One embodiment of hub 107 is shown in FIG. In this embodiment, hub 107 includes pump port indicator 411, wireless signal loss indicator 413, low battery indicator 415, alert mute key 417, on/off key indicator 419, and charging indicator 421 for up to four pumps. Pump port indicator 411 provides a status indicator for each of the pump ports of hub 107 . The indicator light indicates that the corresponding pump port is successfully communicating with network 102 . However, if the indicator light is not illuminated, this indicates that the corresponding pump port is not connected to pump 120 or the port is not communicating from pump 120 to network 102 . Wireless signal loss indicator 413 indicates that hub 107 is unable to communicate with network 102 over a wireless link. If a wireless signal loss occurs, each of pump port indicators 411 will also turn off, indicating that hub 107 is not communicating with network 102 . In the event of wireless signal loss, hub 107 communicates this event to system network 102 and central computer system 108 and server 109 and ultimately to clinician 116 . Alert mute key 417 allows clinician 116 to temporarily mute all audible alerts from hub 107 . Alternative embodiments of the communication hub include a single dedicated wireless module physically within the pump, or separate modules to reach both the pump and the server using wireless communication.

Further, in alternate embodiments, hub 107 may optionally be incorporated within infusion pump 120 to create an integrated medical/communications device. The combination hub/medical device will continue to function exactly like each other.

(access point for the entire system)
As shown in FIG. 3, multiple access points 114 within the medical facility provide an interface between the wireless communication path and the wired communication system. Preferably, hub 107 stores the signal received from pump 120 when system network 102 is unavailable, and then transmits the converted signal to system network 102 once the system network becomes available. In the preferred embodiment, communication between hub 107 and access points 114 is unidirectional from hub 107 to access points 114 and ultimately to network 102 . Thus, in this embodiment, infusion pump 120 can transmit data to network 102 , but network 102 cannot transmit data to infusion pump 120 . However, it will be appreciated that in an alternative embodiment also disclosed herein, communication between hub 107 and access point 114 is bi-directional. Thus, in these embodiments, data and other information can be transmitted from network 102 to infusion pump 120 . In either case, information transmitted between network 102 and hub 107 is encoded for security purposes.

(Central system server/system-wide computer)
1 and 3, central system 108 may include one or more servers or computers. Although this disclosure generally refers to servers 109, 108a, it is understood that these components may be non-server computers. Central system 108 may preferably, but not necessarily, include a first central server or computer 109 and a second central server or computer 108a. In one embodiment, a separate communication system 103 may be provided for communication between the first central server 109 and the second central server 108a. In a preferred embodiment, separate communication system 103 is an isolated point-to-point wired communication Ethernet network. Because this communication system 103 is an isolated point-to-point system connection, data communicated between the two servers 109, 108a is typically not encrypted. Typically, a communication system between the two servers 109 and 108a allows two-way communication.

As described in detail herein, the first central server or computer 109 includes a first database and a first set of functional features associated with data and functions related to medical devices and user interfaces. have Medical device 120 and user interface 118 typically communicate directly with first central computer 109 . Additionally, as will be described in detail herein, a second central server or computer 108a has a second database and a second set of functional features. The first central computer 109 is securely connected to the second computer 108a, and the medical device 120 and user interface 118 do not communicate directly with the second central computer 108a. User interface 118 can receive data, via first central computer 109, from a second database associated with a second set of functional features of second central computer 108a.

A second central server 108a and its software subsystems typically interface with the pharmacy's systems to provide information about drugs, patients, and provide standard workflows for nurses and other clinicians. A second central server 108a also interfaces with the first central server 109 to provide information regarding patients, nurses, clinicians, orders, and relationships between digital assistants 118 and clinicians. Some of the other functions of the second central server 108a may include patient management, item management, facility management, messaging, reporting/graphing, and various interfaces to other systems.

Specifically, patient management refers to general information about each patient entering a hospital or facility. This information is maintained with information specific to each visit and typically includes demographic data, allergies, admission date, discharge date, initial diagnosis, room, bed, and the like. Additionally, information regarding each of the prescriptions, plans, and medications administered is maintained by the second central server 108a. The functionality of the patient management function also includes pre-rejection testing, drug interaction testing, duplicate treatment testing, dosage testing and drug/disease contraindications.

Item Management refers to information about each drug available within the facility. This information is managed and maintained within the second central server 108a. Such information includes drug name, strength, therapeutic class, manufacturer, and the like. In addition, the second central server 108a maintains an ongoing inventory of drug inventory and other smart warehouse item content in real time. The second central server 108a assists in updating when the warehouse is replenished and doses are dispensed or disposed of.

Facility management refers to information describing the entire facility. This information is managed and maintained within the second central server 108 a of system 210 . This information includes physical breakdowns into facility buildings, floors, departments, rooms and beds, lists of programs and services offered and where they are offered, storage departments where drugs and supplies are stored and including identification of the location where they are intended to be supplied.

Messaging refers to the ability of the second central server 108a to provide a communication link between pharmacists and clinicians. A second central server 108a enables standardization of doses and special dosing instructions and automatically sends notifications of dose shortages. Reporting and graphing refers to the availability of several business and management reports that can be run on demand or on schedule by authorized users of system 210 .

The second central server 108a also has various interfaces such as an ADT interface, a billing interface, an individual results interface, a document results interface, a formulary interface, a pharmacy orders interface, a point of care medication management interface and an inventory interface. . These interfaces are described in more detail later, but a brief description is provided immediately below. The ADT interface refers to the Institutional Admittance, Transfer and Discharge System (ADT). This system also typically handles pre-admission and outpatient registration. Individual result interface refers to the interface with test results. Typically, lab results and accompanying orders are entered into an external lab information system, and an individual results interface or lab interface within the HL7 engine forwards this data to the second central server 108a. Once the test results are stored in the second central server 108a, the user can view them from the handheld device 118, the Computerized Physician's Order Entry (CPOE) system, and main applications of the second central computer 108a. be able to. A laboratory interface is available for at least four interfaces: a radiology laboratory interface, a microbiology laboratory interface, a biochemistry laboratory interface, and a pathology laboratory interface. These interfaces can be configured to operate on four different ports or on the same port. The document results interface typically references a second central server 108a to receive radiology and pathology reports. The formulary interface typically references a second central server 108a to receive notification of the master file so that external system drug files can be synchronized. A formulary change will trigger a send transaction from the server 108a to an external third party system. The pharmacy order interface allows for sending medication orders to external third party systems. The inventory interface accepts pharmacy inventory changes from external third party systems. Additionally, a cart depot interface may be utilized with the system 100 . A second central server 108a stores the order and drug file changes in a server database and then transmits this information to any third party cart interface. A third party cart interface within the HL7 engine processes this information into HL7 MFN and RDE messages. The MFN message contains drug file information and the RDE contains patient order information. The HL7 engine then transmits these messages to the third party cart server. The HL7 engine also receives HL7 formatted DFT messages from third party cart servers. The DFT message contains billing information for medication administration. The HL7 engine processes this information and then sends it to the second central server 108a, which can then pass this information to the billing application. The billing application can then calculate the patient charge and send a billing statement to the patient. The billing interface refers to the interface with patient copayment software. The billing interface supports optional use of a billing algorithm to calculate the contribution amount. The billing interface handles internal transactions as well as external inbound transactions from third party systems. The billing interface is an HL7 interface between the second central server 108a and the hospital's third party financial system. The amount to be billed can be sent directly or the patient charge can be calculated by the billing interface and sent to the hospital's third party financial system. Information is sent in real time via HL7 messages. The point-of-care interface consists of web service communications that integrate information regarding point-of-care medication administration to non-infusion related data. These data are communicated in real-time so that the user interface can integrate medication administration for infusion-related and non-infusion-related drugs.

Conversely, a first central server 109 has software loaded and configured to shuttle between hubs 107, digital assistants or user interfaces 118, and to send and receive data with a second central server 108a. . The first central server 109 includes, but is not limited to, the ability to compare prescription parameters received from the server 108a with the appropriate programmed pump settings received from the hub 107 system, as will be described in detail below; The ability to relay notifications and messages to digital assistants 118; the ability to relay alarm and alert information received from hub 107 systems to appropriate digital assistants 118; and the ability to relay pharmacy and patient information communicated from server 108a to appropriate digital assistants. 118, and aggregating pump status data and alarm monitoring data and periodically relaying this data to server 108a. If requested, the work performed by server 109 complies with the Health Insurance Portability Act of 1996 (August 21), Public Law 104-191. Typically, the data residing on the first central computer or server 109 is an intersection of the data residing on the second central computer or server 108a. Server 109 contains a subset of the data contained within server 108a that is required to perform its functionality. Server 109 also contains data relating to system network 102, hub 107 and infusion pump 120 required to perform its functionality. As explained above, such data is typically data required for the functioning or performance of digital assistant 118 and medical device 120 .

In one embodiment, the cost-effective integration of the medical device 120 or other devices and functionality with the hospital information system at the first and second central computers 109, 108a is provided for all of the above-described patient safety related information such as patient safety related information. It comes from isolating subsets of the data and putting such information and functionality into the validated/verified part of the system. In this context, the context of FDA regulations, verified means providing objective evidence that all requirements have been tested, and validated means that the product meets the customer's needs. It means to provide objective evidence that In this embodiment, the validated portion of the system resides within the first central computer 109 . In one embodiment, the subset may include alarms and/or alerts generated by the infusion pump and/or medical device 120/infusion pump 120/controller 120 programming or operating parameter information. This subset is isolated and placed in the validated portion of the system in the first central computer 109, and the rest of the total data is the validation of the system in the second central computer 108a. are retained in the database of unconfirmed portions. The validated database located on the first central computer 109 and the non-validated database located on the second central computer 108a are well understood by those skilled in the art from the details set forth below. are kept in sync using web service replication. An alternative embodiment is to have both validated and non-validated portions of the system reside on a single computer and functionality separated by a software firewall (e.g., operating system mechanisms or other OTS software). can include As described below, "synchronization" is performed periodically based on time intervals, other predetermined times, and/or on an as-needed basis when changes to critical data such as patient enrollment status are made. be able to. At intervals, fresh new copies of the replicated data are sent to the other central computers, and the validated first central computer 109 replaces its local copy with the new copy. If the critical information changes, the change is immediately propagated to the validated first central computer 109 and treated as a change rather than a replacement of existing information. Thus, as will be appreciated from the details provided herein, some or all of the subsets placed in the database of first central computer 109 also reside in second central computer 108a. This process is better understood with reference to the details provided below. Therefore, by localizing a subset of the database, such as patient safety-related data, on the first central computer, at least the cost of system development is further optimized and non-third party validated systems and Integration with respective data and information within the system is more time effective and cost effective.

In one embodiment, the first central computer 109 is a validated server, such as a Compaq DLG-380 with a Windows 2003 Server OS running Active Directory for user and device authentication. It may comprise a Certificate Authority for issuing certificates and client certificates, SQL Server 2000 for temporary data storage, Internet Information Server (IIS) for application hosting (web services and web pages). A second central computer 108a has external hospital information connected via a dedicated Ethernet TCP/IP connection 103 that accesses a data replication web service exposed by a validated server at the other end of the dedicated connection. A non-validated server, such as a system (HIS) server, can be provided. Alternatively, the second central computer 108a may comprise software that performs one or more of the various functions described generally herein, such as pharmacy systems and other systems. can be done. Thus, a second central computer can provide these types of functions and can have interfaces with other systems, such as external hospital information system (HIS) servers. A first central computer (ie, server 109) includes a database, or first database, containing data storage packages. In one embodiment, the first database, which may be external or internal to the first central computer 109, is loaded onto the first central computer 109, as shown in FIG. is preferably accessible only to The data tables in the first database are used within use cases described further herein. The data tables preferably include tables relating to medical devices, digital assistants, hubs, patients, clinicians, prescriptions, titrations, comparison information, alarms, and escalations. Additionally, the medical device table may include tables associated with pumps, pump channels, and pump sub-channels. Alarm tables may also include tables for hub alarms, pump alarms, channel alarms, alarm history logs, and the like.

In one embodiment, each table may contain a key and the data in the table is responsive to the key. For example, a key to a table relating to pump channel information logs can prove the identity of the pump channel log, and in response to the key, the channel identification, pump speed, dosing regimen, dose, remaining amount, etc. , primary injection volume, etc. are provided. Additionally, tables can be linked. For example, a patient table with patient information can be linked to a clinician table, which can be linked to a digital assistant table.

The patient care system 100 of FIG. 3 includes a hub subsystem, a first central computer subsystem or first central server subsystem, a medical device subsystem or pump subsystem, a second central computer subsystem or a second central It can be divided into a server subsystem and a personal digital assistant (PDA) subsystem. The hub subsystem and first central computer subsystem are discussed in further detail herein. With respect to the medical device subsystem, this subsystem includes one or more medical devices 120, such as infusion devices that enable delivery of medication to a patient, and status and infusion information about each infusion device is It is preferably transmitted periodically from a communication port associated with the device.

The second central computer subsystem is typically a server 108a having computer hardware and computer software for interfacing with the pharmacy's systems and providing information about drugs, patients and standard nurse workflow. Server 108a may also have various other applications previously discussed herein, such as interfaces to hospital information systems (HIS). A second central computer interfaces with the first central computer subsystem and provides the first central computer with information regarding patients, nurses, orders, and associations between personal digital assistants and nurses or clinicians. is preferably provided.

In one embodiment, the central computer has at least two environments, a validated environment and a non-validated environment. The validated environment can have a first operating system with a set of applications and a first database. A first database can have a first set of functional characteristics associated with particular data therein. In one embodiment, this set of functional features comprises functionality associated with a medical device and a user interface for the medical device. The medical device and user interface communicate directly and securely with a validated environment. The non-validated environment has a second operating system with a set of applications and a second database. A second database can have a second set of functional features associated with particular data therein. There is usually a logical separation between validated and non-validated environments. The user interface can receive data from the non-validated portion of the database associated with the second functional feature via the validation portion of the system. In one embodiment, the validation portion is separated from the non-validation portion by a logical separation or firewall that can be implemented in software. Various software such as VMware and Virtual PC are examples of emulation software that emulates multiple environments on the same server. In another embodiment, the validation portion may reside on the first central computer 109 and the non-validation portion may reside on the second central computer 108a. In another embodiment, the central computer comprises a first server and a second separate server. The first and second servers are separated by a firewall, a central validation portion of the central computer resides within the first server, and a second non-validation portion of the central computer resides within the second resides on the server of

Preferably, as described in detail elsewhere herein, the personal digital assistant subsystem relays to clinicians and nurses 116 (FIG. 1) their patients, alarm information, and infusion information including alert information. It includes one or more small portable devices 118 that provide remote information regarding the status of, and infusion comparison results. As discussed herein, the first central computer is operably connected to one or more personal digital assistants 118 within the PDA subsystem. In one embodiment, the personal digital assistant is WINDOWS CE. NET-based and used as a terminal device for clinicians. Specifically, as described in more detail herein, the personal digital assistant can be operably connected to a first central computer via an encrypted PKI authenticated wireless LAN (802.1x) connection. can.

The hub subsystem receives data from medical devices 120, transmits pump data to the first central computer subsystem 109, and detects conditions under which data communication can be established with one or more hubs. It preferably includes components such as one or more hubs 107 for

As previously mentioned, in one embodiment, the hub 107 within the hub subsystem interfaces with up to four infusion devices 120 via a one-way serial communication link 105, and the infusion devices communicate pump status information. periodically to the hub. Alternatively, packets may be transmitted based on user-defined criteria such as regular time intervals, event occurrences, combinations of intervals and event occurrences, and the like.

Each hub 107 in the hub subsystem filters received information to reject duplicate messages, stores received information, and then, in one embodiment, uses a built-in wireless network transceiver to pump information to a second 1 central computer subsystem. In one embodiment, pump information is not transferred unless the data received from the medical device has changed.

A transceiver incorporated in hub 107 routes the outgoing information to wireless access point 114, which then uses wired Ethernet subsystem 110 to transfer the outgoing information to a first central computer. 109. This outgoing information preferably includes XML-encoded data formatted as a SOAP message specifically designed to be received by a web services type software interface.

As those skilled in the art will appreciate, the term "XML" refers to a system for organizing and tagging elements of web documents; with respect to XML, custom tags can be generated, inter-application and inter-system or It can allow definition, transmission, validation and interpretation of data between subsystems. Further, as used herein, the term "web service" refers to the integration of web-based services using XML with SOAP, and the term "SOAP" refers to the Refers to a messaging protocol used to encode information before sending it over a network or channel.

A first central computer subsystem is loaded and configured to send and receive data to and from a second central computer subsystem comprising a plurality of hubs 107, a plurality of digital assistants 118, and a server 108a. Preferably, it comprises a server 109 having software applications installed thereon.

Turning to FIG. 54, the server 109 is preferably a COMPAQ DLG-380 with a MICROSOFT WINDOWS® 2003 server operating system 5414 . In one embodiment, the software components loaded into the storage of the first central computer 109 are . NET Framework 5416 for a first central computer or server application 5412, an Active Directory Domain Service 5418 for user and device authentication, a SQL Server 5420 for temporary data storage (shown as a database), and an Internet Information Server 5422 (IIS) for application hosting. including. . NET Framework 5416 is Microsoft. NET Framework 1.1 or above, preferably . NET Framework connects the first central computer's applications 5412 to the operating system, Internet Information Server 5422, SQL database 5420, and Active Directory Domain Service 5418 components. As will be appreciated by those skilled in the art, the Active Directory Domain Service 5418 provides services utilized by the Windows server operating system 5414 and the first central computer application 5412 and is a genuine and authorized hub subsystem. , to ensure that only users of the second central computer subsystem and the personal digital assistant subsystem can access the first central computer and thus the applications 5412 of the first central computer.

In one embodiment, a first central computer (i.e., server 109 in FIG. 3) is configured to: 1) prescribe parameters received from a second central computer subsystem, and corresponding programmed pump settings received from the hub subsystem; 2) relay alarm and alert information received from the hub subsystem to the appropriate personal digital assistant 118 (FIG. 3); 3) the appropriate personal digital assistant. 4) relaying pharmacy and patient information communicated from the second central computer 108a (FIG. 3) to appropriate personal digital assistants 118; ) Performs several functions including compiling pump monitoring data and alarm monitoring data and periodically relaying this data to the second central computer 108a.

The first central computer preferably includes a plurality of external software component interfaces. In one embodiment, three of these interfaces can be classified as "receiving interfaces" that receive incoming HTTP request messages and then issue outgoing HTTP response messages. The remaining two interfaces can be classified as "outgoing interfaces" that send HTTP request messages or XML formatted response messages, as described below. The five software interfaces used herein are referred to as the DatabaseRefreshListener receive interface and DatabaseRefreshListener send interface, the RoutePDA receive interface and RoutePDA send interface, and the PumpDataListener receive interface.

In one embodiment, four of the external software component interfaces are grouped into pairs of two to provide two distinct two-way interfaces between the first central computer 109 and the second central computer 108a of FIG. Create a communication channel. The first channel includes both a DatabaseRefreshListener receive interface and a DatabaseRefreshListener send interface paired together. Accordingly, the first channel, referred to herein as the "DatabaseRefreshListener", is utilized by the second central computer 108a, the data in its database tables being placed in the database tables of the first central computer. regularly synchronized with the data

Using the DatabaseRefreshListener channel, the second central computer 108a refreshes the first central computer's database tables by sending XML encoded data formatted as SOAP messages to the first central computer's web service type interface. update. Similarly, the second central computer 108a updates its own database tables by sending XML-encoded requests for data to the first central computer's web service-type interface, which then sends the first 1 central computer 109 to respond with XML encoded data.

As noted above, the receiving interface portion of the DatabaseRefreshListener channel is utilized by the second central computer for updating database tables located within the first central computer with data from the database tables of the second central computer. be done. Additionally, the outgoing portion of the DatabaseRefreshListener channel is utilized by the second central computer for updating its own database with data from the database tables of the first central computer.

The DatabaseRefreshListener receiving interface preferably contains several web service methods named "RefreshXXX" where "XXX" corresponds to the type of data being transferred. In one embodiment, these methods receive incoming HTTP request messages containing XML-encoded data formatted according to the SOAP protocol. XML-encoded data is a structure in the form of rows in a database table. For example, the method "RefreshUsers" receives a data structure consisting of username and user password pairs corresponding to rows in a database table containing username and user password columns.

As shown in Figure 54, the received message is sent to Internet Information Server and . NET Framework components to application 5412 loaded on the first central computer (ie server 109 in FIG. 3). The application 5412 on the first central computer utilizes the Active Directory Domain Service 5418 to verify the authenticity of the messages on the second central computer, process the content, and then convert the resulting data into SQL Stored in server database component 5420 .

The application 5412 loaded on the first central computer then uses the . NET Framework component 5416 and internet information server component 5422 by issuing an HTTP response method that is routed to the second central computer. This response message indicates the success or failure of data transfer and processing.

The DatabaseRefreshListener receiving interface is asynchronous in nature, so it is preferable to separate the second central computer from the first central computer as much as possible. This separation allows the second central computer to be programmed to continuously process data while waiting for a response and to respond to loss of communication under program control. Additionally, the DatabaseRefreshListener receive interface may also include a web method utilized by the second central computer to periodically send a signal to the first central computer that the second central computer is functioning. .

In contrast to the DatabaseRefreshListener incoming interface, the DatabaseRefreshListener outgoing interface is utilized by the second central computer to update its own database with data from the first central computer's database tables. To ensure that the data has been captured by the second central computer before being permanently removed from the first central computer, the DatabaseRefreshListener outbound interface uses a multi-step approach for data transfer as follows: . 1) the second central computer checks the availability of data, 2) the second central computer requests that the first central computer send the data, 3) the second central computer asks if the data 4) A second central computer confirms that the data was successfully stored in the database table.

To check the availability of data, the second central computer first sends that the corresponding web method of the DatabaseRefreshListener outbound interface is an XML-encoded request message formatted according to the SOAP protocol. The particular web method used preferably has the form "BeginGetXXXToArchive", where "XXX" corresponds to the type of data requested. For example, the method "BeginGetChannelDataToArchive" requests the availability of the timestamped pump channel record received from the pump by the first central computer via the hub subsystem.

Request messages are sent to Internet Information Server components 5422 and . NET Framework component 5416 to the application loaded in the first central computer. Application 5412 loaded into the first central computer parses the XML contained within the request message to determine what data is being requested by the second central computer.

Application 5412 loaded in the first central computer checks the availability of the requested data in SQL Server database 5420 . If data is available, the application prepares an XML-encoded response message indicating that data is available. If the data cannot be obtained, application 5412 prepares an XML-encoded response message indicating that the data is not available.

If the data is not available, the second central computer can retry or continue with a different transfer method that conforms to its processing rules.

If the data is available, the second central computer initiates data transfer by sending a second XML-encoded request message to the appropriate web method of the DatabaseRefreshListener outbound interface. The particular web method used preferably has the form "EndGetXXXToAcrchive", where "XXX" is the same as used above.

Application 5412 in the first central computer decodes the XML contained within the request message, determines what data to return to the second central computer, and passes the data through the corresponding receiving interface. Place in an appropriate XML-encoded response message structured in a format corresponding to a row in a database table compatible with the technique used.

In one embodiment, the data is . NET Framework component 5416 and Internet Information Server component 5422 to the second central computer. If the data was not received correctly, the second central computer can retry or continue with a different transfer method that complies with its processing rules.

If the data was received correctly, the second central computer then sends a third request message to the appropriate web method of this interface. The particular web method used preferably has the form "BeginDeleteArchivedXXX", where "XXX" is the same as used above.

Upon receiving this message, the application 5412 loaded in the first central computer marks the relevant data in the database component of SQL Server as to be sent to the second central computer for archiving, Issue a response message notifying that the data has been marked.

To signal the success or failure of data storage in the second central computer database, the second central computer sends a fourth request message to the appropriate web method of this interface. The particular web method used has the form "EndDeleteArchivedXXX", where "XXX" is the same as used above.

If the second central computer indicates that the transfer was unsuccessful or sufficient time has passed, the first central computer determines that a loss of communication has occurred and then the second central computer The relevant data is maintained in a database of the first central computer in preparation for further transfers requested by.

If the second central computer indicates that the transfer was successful, then the archived data is erased from the first central computer's database and the application 5412 loaded into the first central computer Issue a response message confirming the completion of this final stage of transfer.

The DatabaseRefreshListener outgoing interface is asynchronous in nature, so it is preferable to separate the database of the second central computer from the first central computer as much as possible.

A second two-way channel between the first central computer 109 and the second central computer 108a, referred to herein as "RoutePDA", includes both a RoutePDA inbound interface and a RoutePDA outbound interface paired together. including. The RoutePDA channel is used by the first central computer 109 to route HTTP request messages originating from the PDA subsystem to the second central computer 108a and then receive corresponding HTTP response messages from the second central computer. , if applicable, and then route back to the originating personal digital assistant 118 .

On the second channel (i.e., RoutePDA), messages received from or sent to personal digital assistant 118 are transmitted to the hospital or medical facility's wired Ethernet system 110, wireless access point 114, each personal It is preferably transmitted to and from the first central computer 109 via a radio transceiver incorporated in the digital assistant 118 .

The HTTP request message is preferably forwarded to the second central computer 108a without being processed through the first central computer 109a. The second central computer 108a then issues an HTTP response message containing information in XML or HTML format. The response message in HTML format is routed through first central computer 109 to personal digital assistant 118 without further processing.

The response message in XML format signals to the first central computer 109 that the user 116 (FIG. 1) has requested a web page generated by the first central computer 109, such as a prescription comparison results page or a pump monitoring page. It is used by the second central computer 108a to do so. The first central computer 109 examines the XML response, processes it appropriately, and issues an HTML formatted response message or an XML formatted response message to the sender personal digital assistant 118 .

As previously described, the RoutePDA channel routes HTTP request messages received from the PDA 118 to the second central computer, and then receives and, if applicable, processes the corresponding HTTP responses returned by the second central computer. and then used by the first central computer to route back to the sending PDA.

Thus, the RoutePDA receiving interface is used to communicate with a web browser located within PDA 118 . This interface receives incoming HTTP request messages containing data encoded as name-value pairs consistent with the HTTP "GET" and HTTP "POST" protocols. Incoming messages are sent to Internet Information Servers and . NET Framework components to the application 5412 loaded on the first central computer. Application 5412 loaded on the first central computer, as discussed below, uses the . NET Framework 5416 and the RoutePDA outgoing interface is used to route incoming messages to a second central computer.

When an HTTP response is received at the RoutePDA origination interface, application 5412 loaded on the first central computer determines whether the response uses HTML or XML format. The response in HTML format is processed by the first central computer as a . NET Framework component 5416 and Internet Information Server component 5422 to the PDA.

However, the response in XML format is used by the second central computer to signal to the first central computer that the user has requested a web page generated by the first central computer, such as a prescription comparison results page or a pump monitoring page. is used by the central computer 108a of the The first central computer examines the XML response from the second central computer and processes it appropriately, . NET Framework and Internet Information Server components to publish HTML or XML formatted responses to the appropriate PDA. The RoutePDA interface is preferably synchronous in nature due to the inherent synchronous behavior of the web browsers contained within the PDA.

In contrast to the RoutePDA inbound interface, the RoutePDA outbound interface forwards HTTP request messages received from the personal digital assistant subsystem by the application 5412 loaded on the first central computer to the second central computer for processing. It is used to route and then receive in return the corresponding HTTP response sent by the second central computer.

In both the DatabaseRefreshListener channel and the RoutePDA channel, the first central computer 109 sends and receives information from the second central computer 108a, preferably through an isolated point-to-point Ethernet subsystem 103 dedicated for this purpose.

As described above, in utilizing the DatabaseRefreshListener channel, the first central computer exposes a dedicated web service on dedicated link 103, which is utilized by the second central computer to receive new updates. Database information (such as patient information, clinician information, pharmacy information, etc.) is replicated to the first central computer on a regular and as-needed basis. Also, data is provided from the second central computer to the first central computer.

Additionally, in utilizing the RoutePDA channel at the clinician's terminal end, the first central computer 109 uses NET IIS to serve HTTP-style web pages and maintain an authenticated web session with the PDA device 118. Expose the Server interface. In other words, the clinician's terminal (ie personal digital assistant 118 ) receives the authenticated web page from the first central computer 109 .

At the first central computer end of the dedicated connection 103 to the second central computer, the first central computer sets up a virtual HTTP session for each PDA device 118 connected to the first central computer; It relays HTTP requests from the PDA as they are being received by one central computer, mimicking a web browser to a second central computer. In other words, the first central computer relays requests requiring unvalidation to the second central computer through the dedicated connection 103 to the second central computer.

Therefore, as information flows between the PDA 118 and the server system, there must be information or combined information originating from the second central computer side, which sends XML SOAP packets to the Web services published on dedicated link 103 by one central computer, which uses XML data to perform combined operations with information originating from the first central computer side of the system. , converts the resulting results to HTML, and then sends the HTML back to the clinician's PDA device 118 .

A fifth external software component interface, called PumpDataListener, is the receiving interface for communication with the hub subsystem, described in more detail herein. In one embodiment, the PumpDataListener interface does not have a corresponding outgoing interface because pump data transfer is one-way only, except for communication verification. However, in alternative embodiments, an outgoing interface may be provided for transfer of pump commands and control data to medical device 120 .

The PumpDataListener receive interface is used for receiving data from the hub subsystem. This interface preferably contains a single web service method called "SendPumpData". This method receives an incoming HTTP request message containing XML-encoded data formatted according to the SOAP protocol. The XML encoded data is organized in a hierarchical fashion so that data from several pumps and several channels at several different times can be combined into a single large message structure. be.

Incoming messages are sent to Internet Information Servers and . NET Framework components to the application 5412 loaded in the application of the first central computer. An application on the first central computer uses the Active Directory Domain Service component to verify the authenticity of the hub subsystem message. A first central computer then processes the content and stores the resulting data in a SQL Server Database component. Finally, the application on the first central computer is . NET Framework and Internet Information Server components to issue an HTTP response message to the sending hub device. This response message indicated the success or failure of data transfer and processing.

Data packets received from hub 107 by the first central computer (ie server 109) are preferably stored in a first central database of the first central computer. Preferably, if an alarm or alert event is included in the packet, the first central computer may immediately distribute the event to the appropriate clinician via the clinician's digital assistant 118. Optionally, or alternatively, a first central computer enters the event into a first central computer database and later distributes the information when requested by the appropriate clinician via his or her digital assistant. You may As previously mentioned, the first central computer 109 maintains a log of all clinicians logged on to their digital assistants 118 who are authenticated each time they log on to the system.

The PumpDataListener receive interface is asynchronous in nature, so it is preferable to separate the hub subsystem from the first central computer subsystem as much as possible. The isolation allows the hub 107 in the hub subsystem to be programmed under program control to continuously process data while waiting for a response and to respond to loss of communication. Nevertheless, the PumpDataListener maintains a "heartbeat" and monitors the continuity (lack) of communication between all wireless modules and/or remote pump devices and the central computer.

(communications with the clinician's handheld device)
Pump status, alerts, alarms, patient information, chart information, comparison information, to-do lists and other data/information are displayed on display 118a and, if desired, as described in further detail herein. For example, it is provided to the clinician via a personal digital assistant or user interface 118 having an audible tone or sound generator (not shown). Digital assistant 118 communicates with central system 108 via central network 102 , in particular, wireless communication path or link 126 and wired communication system 110 . As previously mentioned, one or more wireless access points 114 provide an interface between the wireless communication path and the wired communication system in a conventional manner. Digital assistant 118 can receive messages from both servers 109 and 108a.

Communication between central system 108 and digital assistant 118 is preferably bi-directional. In addition, digital assistant 118 has sufficient memory to store and execute modules or applications (not shown) for testing the integrity of communication links between the digital assistant and central system 108 or wireless access point 114. as well as processing power.

Modules or applications installed on the digital assistant 118, although not necessarily so, can be run with or without clinician intervention using high-level Java-like software. is preferably a script or other computer instructions (ie, software code) written in any programming language. Scripts can be automatically downloaded from the server 108a or 109 to the digital assistant 118 or medical device 120 as receiver functions of the system. In one example, one type of script that can be automatically downloaded from a server to a digital assistant periodically polls or monitors communications, including notifications and messaging, from central system 108 or access point 114. It is a script that tests the integrity of a communication link by In a preferred embodiment, a script running on the digital assistant polls the system 108 approximately every 3 seconds. If no response is received from the central system 108 or access point 114, a module or application installed on the digital assistant 118 generates a timeout, indicating that communication with the central system 108 has been lost. An audible tone and/or notification to the display 118a is provided. The notification on the display device 118a can be, for example, the activation of an informational pop-up window announcing that the communication link has been lost, or a change in the active icon display on the display device 118a. A timeout, as used herein and understood by those skilled in the art, is an output generated by a module or application that indicates that the module or application has waited some amount of time for input but has not received it. is. Another type of script can poll to determine if an alarm or alert has been triggered. Numerous other scripts can be run concurrently. One advantage of running scripts downloaded from the system to digital assistants is that there is no need to install custom code on each digital assistant 118 . If there is any event (ie, message, notification, alarm, alert, etc.), the digital assistant 118 automatically retrieves the event from the server and displays it on the digital assistant's 118 interface screen. Other additional advantages of this scripting approach are that 1) the script code can be easily updated at a central server without requiring each digital assistant to update it, 2) the functionality is hardware dependent. script can be verified/validated relatively independently of the digital assistant's hardware platform, since changes or upgrades to the digital assistant have negligible impact on the script's behavior. It is a point.

As noted above, each clinician preferably has an associated digital assistant 118 that, in one embodiment, provides the clinician with a view of a page consisting of an HTML frameset with dedicated frames for displaying events. . The dedicated frame can insert JAVA scripts for the display of events, which are sent to the first central computer regarding new events such as pump alarms and pump alerts directed to the digital assistant 118. Contact 119. If any new event has occurred, then the first central computer provides this information to the digital assistant 118, which is displayed in a frame dedicated to displaying such events.

One type of notification provided on the digital assistant 118 notifies the clinician that the data presented by the digital assistant 118 is out of date and access to alerts and alarms is not available. Conversely, digital assistant 118 can also be notified to provide real-time access to alerts or alarms when digital assistant 118 is linked to central system 108 .

Other notifications typically communicated via scripts include, but are not limited to, pump "silent shutdown", pump infusion limit change, end of infusion, occlusion tendency information, low battery, pre-occlusion indicator, Bolus overuse, keep veins open alert, rapid medication notification, order modification, lab results, radiology results, updates, changes in telemetry data and/or vital sign information, attempt to contact nurse doctors or pharmacies on call, patients seeking nurses, loss of communication, messages from other devices, new rates for critically informed medical devices, subsequent purge rates, and the like.

As previously mentioned, a clinician within a healthcare facility can access a remote wireless device 118 (ie, also called a personal digital assistant (PDA) 118), or a tablet computer with an operably attached bar code reader, or an IV. injection alerts via other computing devices connected to the network 108, either wirelessly or by wire, such as a pole-mounted laptop computer with a bar code reader operably attached to the computer; Access alarms and messages.

The infusion system 210 preferably provides clinicians and other users with the option to automate alert event-driven messages. Additionally, healthcare facility managers and other users can customize the types of automated messaging that appears via remote wireless devices by message type or classification, severity of anomalies, and time-based alerts. Additionally, the infusion system provides clinicians and other users with the ability to set audible messages, visual messages, or both.

The messaging provided by the infusion system 210 preferably includes a user-configurable rules engine, a scheduler, and an interface for connecting to an infusion pump system. Additionally, outcome-driven messaging is desirable to provide real-time decision support at the point of care to clinicians via workstations, electronic tablets, wireless personal digital assistants, and the like.

Typically, communication between the infusion pump 120 and the network 102, as well as between the network 102 and the clinician's digital device 118, involves, among other things, the clinician's 116 inputting pharmacy-entered orders compared by electronic means to programmed pump settings. and/or program the pump, use the system as a method to remotely monitor pump alerts and alarms, remotely monitor pump status, view notifications, and view history of changes to infusion setpoints make it possible.

(Patient medical system)
Referring back to FIG. 1, patient care system 100 preferably includes a computerized physician's order entry module (CPOE), a ward pharmacy module, a wireless nurse clinical record system, and an electronic patient chart module. In one embodiment, such systems and modules are applications on a second central server or second central computer 108a. The patient care system 100 desirably provides a comprehensive patient safety solution for drug delivery. Within patient care system 100 are software modules that link together existing patient care systems using interfaces such as the HL7 interface known to those skilled in the art. The patient care system 100 preferably operates on various computers and personal digital assistant products to transmit orders, update patient charts, and access alerts, alarms and messages.

A computerized physician order entry module allows physicians to enter medication orders and access alerts, alarms, messages, reminders, vital signs and results. The pharmacy module checks prescribed drugs against documented patient allergies and for compatibility with other drugs and foods. The pharmacy module also provides real-time data for inventory management. The nurse medication record module provides clinical information that is readily available at the patient's bedside, thus ensuring drug and dose verification at the point of care.

The patient care system 100 integrates drug delivery products with the information necessary to help ensure safe and effective delivery of drugs. The clinical decision support and accompanying alerts, alarms, warnings, and messaging of patient care system 100 provide a safety net of support for clinicians as they manage patients under increasing time and cost pressures. This information is preferably provided over a wireless network that provides the data in a manner that improves the clinician's workflow and makes treatment administration easier.

(Overview of injection system)
The infusion system 210, or medical system 210, in the patient care system 100 provides, among other things, computerized prescribing and electronic medical records (eMAR). Infusion system 210 makes clinical recording, medication history management, inventory tracking, and messaging easy for clinicians. The patient care system 100 combines barcoding and real-time technology to help ensure that the right patient receives the right medication and the right amount, at the right time, and via the right route. The infusion system 210 provides alerts, alarms, messages, and reminders such as, but not limited to, lab values, out of range, and dose errors. As part of the correct dosing verification function, the system can also verify infusion pump settings.

As described in further detail herein, the infusion system 210 is at least partially one or more devices such as a wireless remote personal digital assistant, workstation, physician order entry module, electronic tablet, processor-controlled infusion pump, or the like. It resides on a further electronic computing device. The infusion system 210 can be configured to display numerous hospital-configurable alerts and alarms in a variety of formats via one or more electronic computing devices. In one embodiment, time-based alerts are provided to remind clinicians to perform patient management functions such as, but not necessarily limited to, changing infusion rates. Additionally, it provides emergency alarms such as, but not necessarily limited to, interruption of infusion. It also provides, but is not necessarily limited to, less urgent messages such as infusion completion or line closure. Additionally, infusion status can be viewed from anywhere within the medical facility via one or more wireless remote personal digital assistants or other electronic computing devices.

As will be disclosed in more detail below, system 210 escalates an alarm or alert that does not indicate that it has been corrected for a predetermined amount of time. Conditions that can trigger escalation of alarms or alerts are preferably defined by the medical facility. Similarly, the amount of time before an alarm or alert escalates can also be defined by the medical facility. Accordingly, a predefined alarm or alert that is not corrected by the clinician within a predetermined time will result in escalation of the associated alarm or alert. Accordingly, the frequency with which the clinician is notified by the system of a rising alarm or alert, which may be the volume of the associated audible tone, is preferably increased.

As will be appreciated by those skilled in the art, the infusion system 210 helps ensure patient safety by checking the infusions being administered per the patient's order. A barcoding scheme is used in which the infusion bag and patient ID are scanned, as described in further detail herein. Infusion information is displayed on both the electronic computing device and the pump to help ensure that the correct infusion is being administered at the correct time, on the correct route, at the correct rate, and to the correct patient. In one embodiment, audible and visual alerts appear on the electronic device when the above-described dosing "rights" are not met. Additionally, if the clinician is setting the infusion pump speed, if the programmed setting does not match the patient's infusion order, an audible alert and A visual alert appears. Additionally, at any time, the clinician, via the electronic device, can check the settings of the infusion pump to see if the settings match the infusion orders contained within the central database 108b.

In one embodiment, the infusion system 210 issues alerts and alarms with various tones or phrases, such as via one or more electronic computing devices, for quick identification of message severity or urgency. offer. Display conventional infusion pump alerts and alarms on an electronic computing device such as, but not necessarily limited to, a personal digital assistant to maintain clinician reporting of infusion status for all assigned patients, thereby It is desirable to be able to save time in resolving problems and improving workflow safety.

Among other things, it is preferable that all alarms and alerts can be retrieved from a central system database for reporting purposes. Retrievable data can help medical facilities investigate and analyze the number of times medication errors have been avoided by alarms, alerts and warnings.

Audible alerts and alarms are preferably set to emit different sounds depending on the severity or urgency associated with the message or issue. Alarms that require first aid sound different than less urgent alerts. Visual text describing the problem is preferably displayed by one or more electronic computing devices. In one embodiment, an alert sounds on the personal digital assistant when the infusion is nearing completion or has completed. The personal digital assistant also displays the patient, location, type of infusion, and time remaining until the infusion bag is empty. The clinician has access to the infusion status at all times via the personal digital assistant and can therefore respond accordingly. In one embodiment, prior to visiting the hospital room, the clinician can view the infusion status on the personal digital assistant and determine if another bag will be needed in the near future. If another infusion bag is needed, the clinician saves time by bringing a new bag during the first visit rather than recognizing that a new bag is needed after arriving at the room. be able to. Similarly, the pharmacy can monitor the status, including time remaining, to plan the mixing and delivery of the next infusion bag.

If desired, and as will be appreciated by those skilled in the art, other alarms and alerts associated with the infusion pump can be made available on an electronic computing device remotely located from the infusion pump. Patient information can be displayed on an electronic computing device, thus saving nursing time and problem-solving steps. As described above, if the pump is in an alarm or alert state, the clinician can view patient information, medication orders, You can browse the alarm or alert messages and collect the items you need.

In one embodiment, the infusion system 210 provides configurable time-based alerts to signal the clinician about a planned infusion order. Thus, with a tapered order to run the NS at 200 ml/hr for 2 hours, then reduced to 50 ml/hr, the infusion system 210 will notify the nurse to reduce the rate 2 hours after the infusion begins. Additionally, it provides a post-alert to notify the clinician when a scheduled infusion exceeds the time tolerance set by the institution. In addition, it generates time-based protocols such as alerts for assessing pain, such as after starting an epidural morphine infusion.

Configurable aspects of infusion system 210 also include audible alerts emitted by an electronic computing device such as a personal digital assistant. Audible alerts are preferably configurable within specific departments of a healthcare facility by the healthcare facility to meet unique circumstances within the healthcare facility.

As previously mentioned, multiple visual alerts and messages can be displayed by an electronic computing device, such as a personal digital assistant, to indicate the importance and urgency of the message. Color, blink, and bold text are preferred display messaging options. Additionally, hyperlinks can be provided when the message is generated. Icons can also be used on the display and emergency messages can be set to interrupt a handheld electronic device or the like and notify the clinician immediately. Additionally, alarm/alert escalation is provided by system 210 . Alarms/alerts and their escalation are discussed in more detail below.

As also previously mentioned, the infusion system 210 allows the clinician to view all infusions or assigned patients on an electronic computing device such as a personal digital assistant, and so travel to and from the patient room. to reduce the time spent on In addition, prescribing information is displayed on the electronic computing device for verification of drug amount, diluent, dose, and infusion rate. In addition, it is possible to view the real-time status of the infusion, and display the duration of the infusion, volume infused, time remaining, and uninfused volume, such as milliliters per hour. As previously mentioned, infusion status and flow rate history can be viewed from anywhere within the medical facility via electronic computing equipment.

As described in further detail herein, the infusion system 210 can calculate the dose to be ordered based on the patient's weight and display the appropriate rate to perform the infusion. A message is generated if the infusion is set to run at a dose other than the ordered dose. Additionally, pediatric dosing is available and set up in the pediatric department within the medical facility.

In one embodiment, the status of primary and secondary injections, such as piggybacks, is displayed by injection system 210 on an electronic computing device, such as a personal digital assistant. The clinician can constantly check the amount of infusion remaining in the piggyback and will receive a message when the piggyback is complete and the primary infusion has resumed. In addition, messages are sent to pharmacies to replenish inventory and infusion orders.

If desired, the infusion system 210 allows the medical facility to define system infusion limits to warn the clinician programming the infusion to run outside the set range. Alerts can be set by the clinician to override the alert or prohibit overriding. As will be appreciated by those skilled in the art, prohibiting redirection to a particular infusion can prevent a patient from inadvertently overdosing.

The infusion system 210 may also provide for the display of reference information related to the needs of each specialty within the medical facility. In addition to departmental policies and procedures, drug information can be viewed on electronic devices such as personal digital assistants. Protocols and standard orders can be configured to provide messages based on patient status. For example, in one embodiment, the heparin infusion protocol is set to notify the clinician of new blood glucose test results and titrate the insulin infusion volume by the number of milliliters determined based on the sliding scale protocol.

Additionally, through established rules, messages or notifications regarding specific infusions are sent to nurses as they relate to the patient's condition. For example, in one embodiment, a message is generated if BUN and creatinine in a patient receiving a nephrotoxic infusion increase. Additionally, the protocol can be set to generate a message when a particular infusion volume is being titrated. For example, in one embodiment, a clinician can set up a message to record blood pressure as the dopamine dose is titrated. Additionally, hemodynamic monitoring parameters can be linked to infusions to generate messages.

As previously mentioned, a new infusion order can be set up to provide a message notifying the clinician of the new order. Messages can be audible and visual, such as text, color alerts, blinking hyperlinks, icons, and the like. Expedited orders and aborted orders can be set as high priority messages to distinguish them from non-urgent messages.

Educational messages are preferably generated and set by the medical facility. For example, in one embodiment, an infusion that requires a particular tubing set (eg, non-PVC) will display an informative message to the clinician. In yet another embodiment, for example, an infusion requiring central venous administration will display a warning not to infuse into a peripheral vein.

In one embodiment, a scheduling message is generated and displayed on one or more electronic computing devices to remind the user to complete the next task. For example, in the case of a tapering infusion, an alert is sent to the electronic computing device to change the infusion rate at the scheduled time. Additionally, protocols with time-based alerts can be set, such as transfusion protocols.

Turning again to FIG. 1, and as described above, the patient care system 100 enables medication orders, dispensing, and administration at the patient's bedside. Physicians can use the wireless handheld device to order simple and complex prescriptions, intravenous therapy and total parenteral nutrition (TPN). The infusion system 210 checks for correct dosage as well as drug-drug interactions and other possible errors. The infusion system 210 then transmits this data in real-time to the patient care facility or local pharmacy, hospital nursing department, home care department, and/or clinic.

A clinician can access the medical chart database using a handheld device. In one embodiment, the clinician scans the barcoded medication and the patient's barcoded bracelet to confirm the correct medication, dose, and time to administer any medication. The infusion system 210 updates medical charts and administration records, thereby eliminating, if not all, time-consuming paperwork. Thus, injection system 210 may save costs and improve efficiency while maximally saving lives. The patient care system 100 may include access-controlled ambulatory and stationary medications and warehouses, including providing electronic patient charts and prescriptions, complete point-of-care to pharmacy dispensing, and inventory management. can.

As previously mentioned, FIG. 1 is a diagrammatic representation of patient care system 100 . Patient care system 100 includes pharmacy computer 104 , central system 108 , and point of care 106 linked by network 102 . In one embodiment, pharmacy computer 104 includes processor 104a, keyboard 104b, video display 104c, printer 104d, barcode reader 104e, and mouse 104f. Although not shown in FIG. 1, patient care system 100 includes hospital administration, nursing room subsystems, clinical information subsystems, hospital information subsystems, hospital admissions and transfer (ADT) subsystems, billing subsystems, and /or Other subsystems typically included in conventional patient care systems may also be included. Such systems typically interface with a second central server 108a.

In one embodiment, central system 108 includes central service computer 108a, database 108b, video display 108c, input/output components, and other conventional hardware components known to those skilled in the art. Network 102 preferably includes a wired communication system 110 portion and a wireless communication system portion. Wired communication system 110 can be, but is not limited to, Ethernet wiring systems and thin net systems.

In one embodiment, treatment location 106 may include treatment bed 106 a , infusion pump 120 , medical cart 132 . In FIG. 1, clinician 116 and patient 112 are shown within treatment location 106 . Medication 124 can be of a type that is administered using infusion pump 120 or other medical device. Medication 124 can also be of a type that is administered without a medical device. Medications may be stored in medication storage area 132 a of medical cart 132 . Clinician 116 uses digital assistant 118 in the process of administering drug 124 to patient 112 .

In one embodiment, clinician 116 uses digital assistant 118 to communicate with wired communication system 110 of network 102 via first wireless communication path 126 during treatment of patient 112 . Infusion pump 120 is capable of communicating with wired communication system 110 via a second wireless communication path 128 . Medication cart 132 also has the ability to communicate via a wireless communication path (not shown in FIG. 1). Wireless transceiver 114 interfaces with wired communication system 110 . The wireless communication system portion of the network includes, but is not limited to IEEE 802.11b "Wireless Ethernet", local area networks, wireless local area networks, networks with tree topography, ring topography ( Technologies well known to those skilled in the art can be used, such as networks with ring topography, wireless Internet access point systems, Ethernet, Internet, wireless communications, infrared, fiber optics, and telephony. Although shown in FIG. 1 as a wireless communication system, the communication paths may alternatively be wired communication paths.

In patient care system 100 , a physician may order medication 124 for patient 112 . In one embodiment, the order may originate with the clinician 116 at the point of care 106 . Physicians and/or clinicians 116 may order medications 124 for patients 112 using a computerized physician's order entry system (CPOE), medication cart 132, or similar device. Those skilled in the art are familiar with conventional computerized physician order entry systems. Despite its name, the clinician 116 can use the computerized physician's order entry system. The infusion order includes information for generating operating parameters for the infusion pump 120 if it is efficient to administer the drug 124 through the infusion pump 120 . An operating parameter is a set of information and/or instructions necessary to program infusion pump 120 to operate according to an infusion order.

Infusion orders can be entered at various locations including pharmacies, nursing centers, point of care, and point of care locations 106 . When an order is entered at the pharmacy, it may be entered into pharmacy computer 104 via input/output devices such as keyboard 104b, mouse 104f, touch screen display, CPOE system and/or medical cart 132. The processor 104a can convert manually entered orders into computer readable data. A device such as a CPOE can convert the order into computer readable data prior to introduction into the processor 104a. The operating parameters are then printed in barcode format on the medication label 124a by the printer 104d. A drug label 124a is then applied to the drug 124 container. The drug 124 container is then transported to the point of care 106 . Drug 124 can then be administered to patient 112 in a variety of ways known in the art, including orally and through infusion pump 120 . If medication 124 is administered orally, clinician 116 may communicate via digital assistant 118 and/or medical cart 132 . The medical cart 132 is computerized and typically has a keyboard (not shown), a display 132b and other input/output devices such as a bar code scanner (not shown).

As will be appreciated by those skilled in the art, the infusion bag can also be premixed and a non-patient specific bar code identifying the drug 124 applied to the bag. Additionally, the infusion bag can be mixed at the pharmacy or on-site, and the drug 124 and, if desired, a patient-specific barcode identifying when the drug should be administered to the patient is applied to the bag.

At the point of care, medication 124 may be loaded onto infusion pump 120 with an intravenous (IV) line 130 running from infusion pump 120 to patient 112 . Infusion pump 120 may include pumping unit 120a, keypad 120b, display 120c, infusion pump ID 120d, and antenna 120e. Prior art infusion pumps can be equipped with a wireless adapter (not shown) to fully implement the present system 100 . The wireless adapter can have its own battery if desired to avoid the draining battery life of prior art infusion pumps. The wireless adapter may also employ intelligent data management techniques such as, but not limited to, store-and-forward data management and data compression to minimize power consumption and network traffic. The wireless adapter may also include the ability to communicate with digital assistant 118 even when network 102 is not functioning.

In one embodiment, patient care system 100 may include various identifiers such as, but not limited to, personnel identifiers, equipment identifiers, and medication identifiers. In FIG. 1, the clinician 116 may have a clinician badge 116a identifier, the patient 112 may have a wristband 112a identifier, the infusion pump 120 may have an infusion pump ID 120d identifier, and the drug 124 can have a medication label 124a identifier. Clinician badge 116a, wristband 112a, infusion pump ID 120d and medication label 124a contain information identifying the personnel, equipment, or medication associated with them. The identifier can also contain additional information. For example, drug label 124a may include information regarding the intended recipient of drug 124, operating parameters for infusion pump 120, and information regarding the lot number and expiration date of drug 124. FIG. The information contained in the identifier may be printed, but is not limited to, device readable formats such as formats for optically readable devices such as barcodes, RFID, iButton, smart cards, etc. Device readable formats, such as radio frequency (RF) device readable formats and laser readable formats are preferred. The digital assistant 118 can include a display 118a and can have the ability to read identifiers including biometric information such as fingerprints.

Wristband 112a is typically placed on patient 112 when patient 112 is admitted to a medical facility. Wristband 112a includes a patient identifier. The patient identifier may include printed information to identify the patient and additional information such as the name of the treating physician. A patient identifier for a patient 112 may include information such as, but not limited to, the patient's name, age, social security number, patient's blood type, address, allergies, hospital ID number, and the names of the patient's relatives. can. In one embodiment, the patient identifier may comprise a unique patient-to-patient reference code or password stored in a central database for cross-referencing if also needed or desired.

(System hardware/software architecture of this system)
FIG. 2 may be included within any number of other subsystems communicating via network 102, such as pharmacy computer 104, central system 108, CPOE, digital assistant 118, and/or medication cart 132 of FIG. 2 is a block diagram of computer 200, which represents a computer with an integrated circuit. As previously mentioned, computer 200 includes infusion system 210 , or a portion of infusion system 210 , for use within patient care system 100 . The injection system described with reference to Figure 2 is preferably a computer program. However, the injection system may be implemented, in whole or in part, in methods and systems other than computer programs.

A significant concern in the art is that the correct drug is administered to the correct patient. Accordingly, infusion system 210 includes features to help ensure that the correct medication is administered to the correct patient in an efficient manner. Infusion system 210 can be implemented in software, firmware, hardware, or a combination thereof. In one mode, the infusion system 210 is implemented in software as an executable program and can be used on a personal computer (PC; IBM-compatible PC, Apple-compatible PC, etc.), personal digital assistant, workstation, minicomputer, or mainframe. It is executed by one or more special purpose or general purpose digital computers such as computers. An example of a general purpose computer on which infusion system 210 can be implemented is shown in FIG. The infusion system 210 can reside within or reside within any computer, including, but not limited to, pharmacy computer 104, central system 108, medication cart 132, and digital assistant 118. It can have various parts that reside there. Accordingly, computer 200 of FIG. 2 is representative of any computer in which infusion system 210 resides or partially resides.

As shown in FIG. 2, generally in terms of hardware architecture, computer 200 includes a processor 202, storage device 204, and one or more input/output (I/ O) includes devices 206 (peripherals). Local interface 208 may be, for example, without limitation, one or more buses or other wired or wireless connections known in the art. Local interface 208 may have additional elements to enable communication, such as controllers, buffers (caches), drivers, repeaters, and receivers, which have been omitted for brevity. Additionally, the local interface may include address, control, and/or data connections to enable appropriate communication between other computer components.

Processor 202 is a hardware device for executing software, particularly software stored in storage device 204 . Processor 202 may be any custom or commercially available processor, central processing unit (CPU), auxiliary processor among several processors associated with computer 200, semiconductor-based microprocessor (in the form of a microchip or chipset). , a microprocessor, or any conventional device for executing software instructions. Examples of suitable commercially available microprocessors are as follows. The PA-RISC series of microprocessors from Hewlett-Packard Company, the 80x86 or Pentium series of microprocessors from Intel Corporation, the PowerPC microprocessors from IBM, Sun Microsystems , Inc. or the 68xxx series of microprocessors available from Motorola Corporation. Processor 202 can also represent distributed processing architectures such as, but not limited to, SQL, Smalltalk, APL, KLisp, Snobol, Developer 200, MUMPS/Magic.

Storage device 204 may include any of volatile memory elements (eg, random access memory (RAM such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (eg, ROM, hard drives, tape, CDROM, etc.). or combinations thereof. Additionally, storage device 204 may incorporate electronic, magnetic, optical and/or other types of storage media. Storage device 204 may have a distributed architecture in which various components are remote from each other but still accessed by processor 202 .

The software in storage device 204 may include one or more separate programs. A separate program comprises an ordered list of executable instructions for performing logical functions. In FIG. 2, the software in storage device 204 includes an injection system 210 and a suitable operating system (O/S) 212 according to the invention. A non-exhaustive list of suitable commercially available operating systems 212 follows. (a) Windows® operating system available from Microsoft Corporation; (b) Novell, Inc.; (c) Apple Computer, Inc.; (d) the Hewlett-Packard Company, Sun Microsystems, Inc.; and AT&T Corporation; (e) a freeware LINUX operating system readily available on the Internet; (f) WindRiver Systems, Inc.; or (g) an appliance-based operating system, such as that implemented on handheld computers or personal digital assistants (PDAs) (e.g. PalmOS, available from Palm Computing, Inc.; and Windows CE available from Microsoft Corporation). Operating system 212 essentially controls the execution of other computer programs, such as injection system 210, and provides scheduling, input/output control, file and data management, memory management, and communication control and related services.

Injection system 210 can be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be executed. In the case of source programs, the programs are translated through a compiler, assembler, interpreter, etc., which may or may not be contained within storage device 204, so as to operate properly in conjunction with O/S 212. be. Further, injection system 210 may be implemented in (a) an object-oriented programming language with classes of data and methods, or (b) a procedural programming language with routines, subroutines, and/or functions, such as, but not limited to, It can be written as C, C++, Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada. In one embodiment, system program 210 is written in C++. In another embodiment, injection system 210 is built using Power Builder. I/O devices 206 may include input devices such as, but not limited to, keyboards, mice, scanners, microphones, touch screens, interfaces to various medical devices, bar code readers, styluses, laser readers, radio frequency device readers, and the like. can include Additionally, I/O devices 206 may also include output devices such as, but not limited to, printers, bar code printers, displays, and the like. I/O device 206 is a device that communicates as both an input device and an output device, such as, but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network). ), radio frequency (RF) transceivers or other transceivers, telephone interfaces, bridges, routers, and the like.

If computer 200 is a PC, workstation, personal digital assistant, etc., the software in storage device 204 may further include a basic input/output system (BIOS) (not shown in FIG. 2). BIOS is a set of basic software routines that initialize and test hardware at boot time, start O/S 212, and help transfer data between hardware devices. The BIOS is stored in ROM so that the BIOS can be executed when the computer 200 is started.

When the computer 200 is operating, the processor 202 executes software stored within the storage device 204, communicates data to and from the storage device 204, and generally controls the operation of the computer 200 in accordance with the software. set to control. Infusion system 210 and O/S 212, in whole or in part, typically the latter, are read by processor 202, possibly buffered within processor 202, and then executed.

As shown in FIG. 2, when the infusion system 210 is implemented in software, the infusion system 210 program may be placed on any computer-readable medium for use by or in connection with any computer-related system or method. can be stored on the Computer-readable medium, as used herein, refers to any electronic, magnetic, optical, or other medium that can contain or store a computer program for use by or in connection with a computer-related system or method. A physical device or means. The injection system 210 is an instruction execution system, such as a computer-based system, a system containing a processor, or other system capable of retrieving instructions from an instruction execution system, instruction execution unit, or instruction execution device and executing the instructions. It may be embodied in any computer-readable medium for use by or in connection with a system, instruction execution apparatus, or instruction execution device. In the context of this document, "computer-readable medium" means storing, communicating, propagating, or transporting a program for use by or in connection with an instruction execution system, instruction execution apparatus, or instruction execution device. can be any means possible. A computer readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (non-exhaustive list) of computer-readable media include the following. Electrical connections with one or more wires (electronic), portable computer diskettes (magnetic), random access memory (RAM) (electronic), read only memory (ROM) (electronic), erasable program ROM (EPROM, EEPROM, or flash memory) (electronic), fiber optic (optical), and portable compact disc read-only memory (CDROM) (optical). The program may be captured by electronic means, for example via optical scanning of paper or other medium, and if necessary then compiled, translated or otherwise processed in a suitable manner, and then stored in computer memory. Note that the computer-readable medium may even be paper or another suitable medium upon which the program is printed, as it can be.

In another embodiment where injection system 210 is implemented in hardware, injection system 210 may be implemented with any or a combination of the following techniques, each known in the art. Discrete logic circuits with logic gates for performing logic functions on data signals, Application Specific Integrated Circuits (ASICs) with appropriate combinatorial logic gates, Programmable Gate Arrays (PGA), Field Programmable Gate Arrays (FPGA), etc. .

As will be appreciated by those skilled in the art, any process description or process block in a diagram such as FIGS. Represents a module, segment, or portion of hardware, software, etc., that may contain possible instructions, either substantially in parallel or in reverse order, depending on the functionality involved, as shown in the figure. Alternatively, alternative implementations that can perform the functions in an order that deviates from that discussed are within the scope of embodiments of the invention.

(Components of Patient Care System)
FIG. 4 is a first block diagram illustrating functional components of the patient care system 100 of FIG. As shown in FIG. 4, patient care system 100 may be implemented as a modular system in which modules represent various functions of patient care system 100, including infusion system 210 (FIG. 2). The flexibility of the patient care system 100 and infusion system may be enhanced when the system is implemented as a modular system. The modules of infusion system 210 ( FIG. 2 ) can be included in various portions of patient care system 100 . In one embodiment, the functional components of the patient care system 100 can include a medication management module 302, a prescription generation module 304, a prescription activation module 306, and a prescription authentication module 308, among others.

Medication management module 302 may coordinate the functionality of other modules of patient care system 100 involved in managing medical therapy. Medication management module 302 coordinates with the rest of patient care system 100 as a whole. Medication management module 302 operates with and/or interfaces with the CPOE, operates with and/or communicates with the point-of-care module, and operates with and/or communicates with the medical therapy comparison module. It can contain submodules. In FIG. 4, admissions and transfers (ADT) interface 310, billing interface 312, laboratory interface 314, and pharmacy interface 316 are shown. The ADT interface 310 is used to capture information such as patient demographics, size, weight, and allergies. In a preferred embodiment, the ADT system uses an HL7-type interface to forward events entered into the hospital's ADT system into the second central computer 108a. HL7 is a protocol for formatting, transmitting and receiving data in a healthcare environment. It provides interoperability between medical information systems through a messaging standard that allows disparate medical applications, such as a variety of different third party applications, to exchange key sets of clinical and administrative data. Generally, in the system 100 of the present invention, the HL7 ADT interface consists of three applications: HL7 ADT Server, HL7 ADT Client, and HL7 ADT Viewer. A pharmacy interface 316 imports orders from pharmacies. The pharmacy interface 316 may be an HL7-type interface that interfaces with other systems to enter orders, such as CPOE. This feature reduces the need to enter data into the patient care system 100 more than once. The pharmacy interface 316 can be configured to communicate with commercially available third party systems such as, but not limited to, Cerner, HBOC, Pyxis, Meditech, SMS, Phamous, and the like. A web service interface can provide near real-time coordination between point-of-care medication management systems that support oral medication administration, such as McKesson AdminRx, Pyxis, Verif5, etc., and infusion pump-related medication management. Various other interfaces are known to those skilled in the art and are not shown in FIG.

The medication management module 302 provides additional features such as checking for adverse reactions due to drug incompatibilities, double drug administration, drug allergies, drug dose limits, drug dose frequency limits, drug dose duration limits, and contraindications due to drug-induced diseases. can have Food and alcohol interactions can also be noted. Drug restrictions can include, but are not limited to, restrictions such as restrictions related to adult, pediatric, infant, neonatal, preterm, geriatric, age, weight, height, and body surface area. can. In one embodiment, medication management module 302 prevents entry of the same prescription for the same patient from two different prescription sources within patient care system 100 .

Medication administration module 302 may also include functionality to generate reports. Reports include, but are not limited to, end of shift, titration information, patient event list, infusion history, pump operation history, pump location history, and pump maintenance history. The end of shift report can include pump channel, start time, end time, primary infusion, piggyback infusion, drug, dose, speed, pump status, infusion volume, volume remaining, time remaining, and final completion time. . The infusion history report contains drugs and infusion volumes.

Medication management module 302 may include a medical device status database. The medical device status database contains data indicative of the location of the medical device 332 within the patient care system 100 . The medical device status database may also include data indicative of past operation of medical device 332 . The medical device status database may also include data indicative of maintenance schedules and/or histories of medical devices 332 .

The infusion prescription or order is entered in prescription entry 324 . Such orders can include formulations such as, but not limited to, single dose, intermittent, continuous, sequential, titration, and alternating dose types. Infusion regimens can include total parenteral nutrition admixtures (TPNs), chemotherapy continuous infusions, piggybacks, bolus parenteral drugs, and other infusion regimens. The patient care system 100 can function without end dates for orders. Patient care system 100 employs a continuous schedule generator that predicts a predetermined time and generates an admixture fill schedule for that time. Predetermined times can be defined at the patient care system 100 level, or at the subsystem level, such as the clinical area level and the organizational level. The predetermined time can be adjustable by the clinician 116 entering the order. The schedule can be automatically extended as long as the order is active within patient care system 100 .

A prescription generation module 304 generates hard prescriptions and electronic (E-copy) prescriptions. Hard prescriptions are typically made in triplicate at medical facilities. A first hard copy 318 is typically sent to the pharmacy, a second hard copy 320 is typically kept for patient records, and a third hard copy 322 is sent to the treatment location 106 . The electronic prescription is sent to medication management module 302 .

Prescription module 304 may include functionality to verify operating parameters. Operating parameters may be based on information from prescription entry module 324 . Prescription generation 304 may occur anywhere within patient care system 100 such as, but not limited to, pharmacies, treatment locations 106, and nursing centers.

A Computerized Physician's Order Entry (CPOE) system or the like can be used to perform some or all functions of the prescription generation module 304 . Clinician 116 may enter data in a variety of ways including, but not limited to, tablet wireless computers, personal digital assistants, therapy carts 132, and workstations. Medication management module 302 can interface with more than one prescription generation module 304 . The medication management module can receive orders from anywhere within patient care system 100 .

The pharmacy computer 104 can access the electronic copy from the medication administration module 302 . The prescription activation module 306 is a computer-assisted system that coordinates the filling and labeling of prescriptions. Filling prescriptions and generating or placing medications 124 from inventory is handled by prescription activation module 306 . In one embodiment, the filling process results in the creation of the medication label 124a, as opposed to the prescription activation process.

Patient care system 100 may bypass prescription activation module 306 . This can be done if the ordering clinician 116, such as the patient's attending physician, has the authority to activate the order immediately. If the order is to be activated immediately, the medication administration module 302 can go straight to the filling and hence prescription labeling module 326 .

At block 326, the patient care system 100 prints the medication label 124a. Prescriptions can be printed remotely and are often printed by the pharmacy's printer 104d. After block 326 , the patient care system 100 goes to block 328 . At block 328 , medication label 124 a is applied to medication 124 . Typically, the pharmacist visually verifies 334 that the drug label 124a matches the first hard copy 318 of the prescription. FIG. 4 shows that visual verification 334 is also associated with prescription authorization module 308 . Medication 124 can then be transported from the pharmacy to the point of care 106 . A portable medical cart 132 may be used for part of the route from the pharmacy to the treatment location 106 .

Medication label 124a may include information for preparing an infusion bag. If not created within patient care system 100, medication label 124a may be provided by a bulk medication supplier. If provided by the bulk drug supplier, patient care system 100 collects information from medication label 124a. Additionally, the patient care system 100 can add information, such as a patient identifier, to the medication label 124a.

Medication labeling module 328 places medication label 124 a on medication 124 . This can be achieved manually. This can also be accomplished using an automated prescription filling and packaging system (not shown). If an automated prescription filling and packaging system is used, the drug labeling module 328 provides data for coordinating the labeling of the drug 124 with the filling and packaging system.

At treatment location 106 , clinician 116 uses digital assistant 118 and/or wireless device 330 , such as medical cart 132 , to identify and administer medication 124 to patient 112 . Wireless device 330 communicates with medication administration module 302 via a communication path, such as first communication path 126 .

Clinician 116 identifies himself by scanning badge 116a, identifies patient 112 by scanning wristband 112a, identifies medication 124 by scanning medication label 124a, and scans label 120d. to identify a medical device 332 such as an infusion pump 120; Clinician 116 may also identify himself/herself by providing a fingerprint and/or password as described above and shown in login screen 1903 of FIG. Medical device 332 may be a medical device capable of two-way communication with medication administration module 302 . Alternatively, medical device 332 may only be capable of providing information to medication management module 302 . Infusion system 210 assists clinician 116 in administering and verifying medical therapy. In an alternative embodiment, the infusion system 210 may include the ability to download operating parameters to the medical device 332 . Clinician 116 may perform visual verification to confirm that third copy 322 and/or MAR matches labeled medication 124 . Scanner 338 may be used to input machine-readable information from third copy 322 to wireless device 330 and medical device 332 .

The patient care system 100 can make adjustments and changes to infusion orders. A prescription entry module 324, a prescription activation module 306, a prescription authorization module 308, and a prescription modification module 336 are among other modules that may include functionality to make infusion adjustments. The clinician 116 accesses the prescription modification module 336 to adjust the order. Clinician 116 can access prescription modification module 336 from anywhere in patient care system 100 . However, one very useful location for the clinician 116 to access the prescription modification module 336 is at the treatment location 106 .

In the prescription authorization module 308, the patient care system 100 determines whether the clinician 116 has authority to unilaterally modify the infusion order. Clinician 116 may be recognized by patient care system 100 as having the authority to independently modify certain portions of an order. If the clinician 116 does not have sole authority to modify the order, a pharmacist or physician may be requested to approve the modifications entered by the clinician 116 .

In one embodiment of patient care system 100 , orders are entered into pharmacy computer 104 . This order includes a first patient identifier and operating parameters. The pharmacy computer 104 creates a drug label 124a to be applied to the drug bag or container. Medication 124 is delivered to treatment location 106 . At the point of care 106, the clinician 116 reads the clinician's 116 badge 116a, the patient's wristband 112a, and the medication label 124a with the digital assistant 118. Digital assistant 118 reports whether medication label 124a and wristband 112a correspond to the same patient 112 based on determinations made by central system 108 . The system 100 then sends the drug identifier to the pharmacy's computer 104 . The pharmacy computer 104 verifies the drug label 124a, identifies the same patient as the order, and sends operating parameters to the infusion pump. Operating parameters can be sent directly to infusion pump 120 . The operating parameters are then used to program the infusion pump to administer drug 124 to patient 112 .

FIG. 5 is an exemplary block diagram of a computer screen 400 that helps perform various functions of infusion system 210 (FIG. 2). In addition to other functions, computer screen 400 can be used to enter new infusion orders, modify existing infusion orders, and stop infusion orders. Computer screen 400 preferably includes processing area 402 , search area 404 , medication information area 406 , titration/tapering criteria area 408 , instructions/notes area 410 , and predicted solution area 412 . Infusion drug order types include single dose, intermittent dose, continuous dose, sequential dose, and alternating dose. Computer screen 400 can be used with digital assistant 118 , pharmacy computer 104 , infusion pump 120 , CPOE system, and medical cart 132 . Computer screen 400 is generally designed to have a clinician-accessible computer screen look and feel throughout patient care system 100 of FIG. Some of the functionality of computer screen 400 is accomplished through database linkage techniques such as, but not limited to, hyperlinks, definition boxes, and drop-down menus, which are familiar to those skilled in the art.

Processing area 402 includes functions to trigger infusion order creation, infusion order storage, infusion order modification, and infusion order cancellation. Clinician 116 can customize computer screen 400 to provide clinician 116 with a preferred order entry procedure. Processing area 402 includes status indicators for orders. Processing area 402 also includes an area for indicating whether PRN orders (“on demand” or “on demand” orders) can be placed by clinician 116 . Processing area 402 includes medical device 332 operating parameters, infusion order route, infusion line, infusion delivery site, infusion order release time, infusion drug order type, infusion flow rate tolerance, infusion flow rate, infusion duration and dispensing location (pharmacy or remote). position, etc.). Processing area 402 is also an area for linking medical orders to other medical orders or related clinical monitoring, such as linking a physician's infusion order to another medical order entered by another clinician 116 . can also include Processing area 402 may include, but is not limited to, triggers for displaying data in other areas of computer screen 400 such as predicted solution area 412 .

A search area 404 allows searching for drugs, solutions and/or additives for an infusion order. A default diluent can be defined for the order. If a default dose has been defined for a drug within the patient care system 100, the default dose will automatically appear with search results containing the drug. As a result of the search from the search area 404, the drug name, administration route, cost, package size, dosage form, generic name, presence or absence of anesthetic properties of the drug, presence or absence of drug management, whether it is a drug list, and drug manufacturing location can be displayed.

Medication information area 406 can be used to determine additives and solutions for an infusion order. Medication information area 406 can include separate additive and solution areas. The solution area can include a label, "solution/diluent." The patient care system 100 can populate the drug information area 406 with data regarding drugs 124, solutions, and additives using the drug 124 database, the solution database, and the additive database. Substances identified in one database can also be identified in other databases. Each database can be linked to provide default values for drug 124 and solution combinations.

The titration/tapering criteria area 408 generally applies to continuous infusion orders. Titration defines specific parameters of the order, such as dosage and/or flow rate. Dose and flow rate can be entered as absolute. Information may also be entered into the titration/tapering criteria area 408 using single mathematical symbols such as, but not limited to, ">" greater than, "<" less than, and "=" equal to. Or it can be used in combination. A calendar can also be used to enter data into the titration/tapering criteria area 408 . Dose and flow rate can also be entered as tolerances. The titration/tapering criteria area 408 can be hidden when entering and/or modifying a non-continuous infusion order. Titration criteria may include, but are not limited to, the values of various parameters related to the patient's health status, such as, but not limited to, various laboratory results, vital signs, ability to orally ingest fluid, fluid inflow and outflow, and the like. can contain.

Instructions/notes area 410 includes the ability to store information such as physician notes regarding patient 112 and/or infusion orders. The instructions and notes area 410 may include a display and reference area for identifying the clinician 116 responsible for the patient 112, such as the patient's attending physician.

The expected solution area 412 displays the solution schedule and related factors based on the current status of the orders being processed for the patient 112 . The estimated time can be the patient care system 100 default. The time can also be adjusted by the clinician 116. Predicted solution area 412 may include an adjustable display showing the time predicted by patient care system 100 . The data displayed in the predicted solutions area 412 is typically saved when order storage is triggered in the processing area 402 . The predicted solutions area 412 may include the ability to look back over a period of time while revising previously entered orders. This allows the clinician 116 to consider solutions that may have already been ready according to the unmodified infusion order.

(components of the injection system)
FIG. 6 is a block diagram showing functional elements of injection system 210 of FIG. Functional elements include block 502 for setting system parameters, block 504 for creating infusion orders, block 506 for preparing infusion orders, block 512 for administering drugs, block 514 for modifying infusion orders, and block 520 for messaging. FIG. 6 also includes pharmacy authorization block 508 , physician authorization block 510 , order stop block 516 , and inventory and billing block 518 . FIG. 6 provides one illustration of an injection system. However, FIG. 6 does not define the sequence of steps required to carry out the injection system. One advantage of the present infusion system is that it allows clinicians 116 to access and enter information from multiple physical and functional locations within patient care system 100 . For example, an infusion order can be generated by a physician using CPOE, a pharmacist using pharmacy computer 106, a clinician 116 using digital assistant 118, and a clinician using medical cart 132. is. Additionally, patient vitals, lab results, and other records can be checked from multiple locations within the healthcare facility, including, for example, the ward pharmacy. Accordingly, a user within the ward pharmacy 104 (FIG. 1) can view the wards within the medical facility from the computing device 104c. When the user selects a ward, a patient list is provided from which the user can select a patient and associated records for display on the computing device. Alternatively, the user can enter all or part of the patient's name into the computer so that records relating to that patient are provided by the computer for selection by the user. . As soon as the selection is made, the record is displayed.

In one embodiment, FIG. 6 depicts first, a block that prepares the patient care system 100 to receive an infusion order—set system parameters block 502; 3rd, Block Dispensing Based on Infusion Orders - Dispensing Block 506; 4th, Block Authorizing Infusion Orders - Pharmacy Authorization Block and Physician Authorization Block 508 and 510; 5th, Block Performing Infusion Orders - Medication Administration. Block 512; Sixth, Block Accounting and Replenishing Inventory Used to Dispense Based on Infusion Orders and Billing Patients for Infusion Orders--Inventory and Billing Block 518; , Modify infusion order block--modify block 514; and eighth, Infusion order progress, Infusion, ensuring that the correct medication is dispensed efficiently and provided to the correct patient in the correct amount at the correct time. A block that sends messages to various personnel and subsystems regarding messages to support the , etc.--message block 520. FIG. Modify block 514 may include block-stop order block 516 that stops the order based on information provided by transfer interface 310 .

The set system parameters block 502 includes functional blocks that prepare the infusion system 210 to create and process infusion orders. The set system parameters block 502 includes, but is not limited to, a set tolerance block 542, a set default value block 544, a database build block 546, a function define block 548; and block 550 for determining system settings. Block 502 for setting system parameters is further described below with reference to FIG.

Infusion order creation block 504 includes functional blocks used to create infusion orders. Infusion order generation block 504 includes similar functionality as described with reference to prescription generation block 304 (FIG. 4). The infusion order creation block 504 includes, but is not limited to, an input information block 560 , a calculation block 562 , a check block 564 and an override block 566 . Infusion order creation is further described below with reference to FIG. The result of infusion order creation is infusion order 702 (FIG. 8). An infusion order 702 typically includes an infusion schedule 704 (FIG. 8).

An infusion order may require authorization as described with reference to block 308 (FIG. 4). In FIG. 6, pharmacist prescribing authorization and physician prescribing authorization are considered separately in pharmacy authorization functional block 508 and physician authorization functional block 510 . Physician authorization 510 may not be required if the infusion order is initiated by a physician. Infusion orders typically require pharmacy authorization 508 and physician authorization 510 if the order is created by a clinician other than a pharmacist or physician at the point of care 106 . However, if drug 124 is needed immediately, infusion system 210 allows the administering clinician to bypass prescribing authorization 508 and physician authorization 510 . In the case of an urgent order or a non-urgent order for routine medication, the infusion system 210 determines that the patient care system 100 does not store information related to the medical care that the clinician 116 wishes to administer to the patient 112 . can judge. If the infusion system 210 recognizes that the clinician 116 is authorized to initiate the desired care, the system 210 allows the care to be performed without going to blocks 508 and 510 . This authorization is then obtained on the following medications.

Preparation 506 based on infusion orders can be accomplished at several locations throughout the medical facility, including, but not limited to, pharmacies, nursing centers, floors, and treatment locations 106 . Preparation 506 includes providing instructions to dispense medication 124 and minimizing the likelihood of errors in dispensing medication.

Drug administration 512 occurs at treatment location 106 . The infusion system 210 is designed to perform order fulfillment as efficiently and accurately as possible. The infusion system 210 provides the managing clinician with the tools to administer the right drug to the right patient in the right amount, at the right time, through the right route, with the right pump settings. Medication management module provides status information output to messaging module 520 when an alert, alarm, reminder, or other message is appropriate to assist the clinician in administering medication. In response to the status information output, messaging module 520 forwards an associated text message, audible display enable, or both to one or more electronic computing devices.

As known to those skilled in the art, infusion orders are frequently modified. The infusion system 210 performs a modification 514 and provides instructions for modifying the infusion order. Modifications 514 include modifying infusion durations, flow rates, infusion sites, and stopping orders 516 . Modify block 514 also includes the functional blocks necessary to perform infusion order modification.

The infusion system 210 may include a patient care system wide 100 defined stop order 516 . A change in the patient's condition can generate a message 520 for appropriate action. The infusion system 210 cooperates with the transfer interface 310 to automatically stop 516 orders upon discharge or death.

System 100 includes inventory and billing module 518 . The inventory and billing module 518 allows financial transactions related to patient care to proceed with minimal human intervention. Completion of medication administration 512 may trigger patient billing via billing interface 312 . The billing interface can include an HL7 interface. When a patient is billed based on completion of infusion order preparation 506, inventory and billing system 210 includes a crediting process. The crediting process can be triggered when an infusion bag is returned for disposal or re-entry into the pharmacy's inventory management system.

Infusion system 210 includes a messaging module 520 for communicating with entities throughout patient care system 100 . Specifically, message module 520 sends a text message, an audible display enable, or both to one or more electronic computing devices within patient care system 100 . The message is sent in response to status information output provided by a medication management module or other infusion system module within patient care system 100 . The messages are associated with status information outputs and thus provide appropriate alerts, alarms, reminders, or other messages to assist the clinician in managing medications.

For example, when a doctor enters a new order, a message appears at the pharmacy informing the pharmacist that the infusion order requires authorization. Similarly, if the infusion order is properly authorized, clinician 116 receives a message on digital assistant 118 informing clinician 116 that the infusion order should be processed according to infusion schedule 704 . The override 566 can generate 520 messages to doctors and/or pharmacies. The infusion system 100 can distinguish between system-wide overrides and subsystem overrides in determining whether it is necessary to generate 520 a message. Messaging 520 includes messages sent to and received from central systems, pharmacies, physicians, billing modules, and inventory modules.

The system can present the clinician 116 with a personal computer display view. A personal computer display provides a summarized view of the clinician's patient's unresolved clinical issues. Clinician 116 can quickly retrieve detailed information about the patient. The system 100 can also generate emails or pages to the digital assistant 118 or other communication device when there are certain critical patient conditions.

Also shown in FIG. 6 are some of the communication paths that occur in patient care system 100 . Highlighted communication paths are provided to facilitate description of injection system 210 . Those skilled in the art will appreciate that when the patient care system 100 is implemented on a network, the various functional blocks communicate with each other through the highlighted paths in FIG. 6 and through alternate paths not shown in FIG. I know it can be done. The set system parameters block 502 functions to communicate data related to system parameters to the infusion order creation block 504 via path 522 and/or receives data from the infusion order creation block 504 and how the received data includes the ability to provide data that informs the infusion order creation block 504 whether it is related to system parameters.

Infusion orders can be passed directly to infusion dispensing block 506 via path 524 . The infusion order may also be passed to pharmacy authorization block 508 via path 526 and/or to physician authorization block via path 528 before being sent to dispensing block 506 . Pathway 530 highlights delivery of medication 124 from the dispensing area to treatment location 106 . Delivery can be accomplished using medication cart 132 . Paths 532 , 534 , 536 , and 538 represent inventory and billing 518 transactions for various other functions such as, but not limited to, infusion order creation 504 , preparation 506 , medication administration 512 , and modification 514 . It emphasizes that it can be associated with Paths 572, 574, and 576 highlight that a greater number of functions and actors included in patient care system 100 can generate and receive information via message 520 block. Path 582 highlights that the pharmacist can create and/or change system defaults 544 . Path 580 also highlights the availability of information, such as infusion orders, to various functional units throughout system 100 .

FIG. 7 is a block diagram illustrating the functional elements for system parameter settings 502 of FIG. System parameter settings 502 include, but are not limited to, tolerance settings 542 , default value settings 544 , database construction 546 , function definitions 548 , and system setting value determination 550 . Tolerances 542 include, but are not limited to, net dose tolerance 542a, flow rate tolerance 542b, administration time tolerance 542c, administration system duration 542d, administration duration tolerance 542e, and site change tolerance 542f. Including tolerance. The infusion system 210 may also include separate tolerances for order entry and modifications from the ordered tolerances. For example, identifying separate tolerances such as, but not limited to, dosing system duration 542d, maximum infusion duration override enablement in order entry, and maximum infusion duration override enablement in dosing. can be done.

The net dose latitude 542a is the maximum concentration of drug that is safe to administer to the patient at any given time. The infusion system 210 associates a net medication tolerance with a drug. A net medication tolerance 542a can be defined in a drug identification file in a drug database. During infusion order creation 504, the infusion system 210 determines the flow rate 560e, the number of infusion bags required at a particular time 562a, the concentration of the principal ingredient in each infusion bag, the time each infusion bag is to be administered, the time each infusion The total amount of bags can be determined. The flow rate can be adjusted by manually entering or changing the final concentration or duration of each infusion bag. In one embodiment, the infusion system 210 performs a net concentration check 564a (FIG. 8) to ensure that the drug does not exceed the maximum concentration. However, at any point when the final concentration of the solution exceeds the maximum concentration of the drug while the clinician 116 is changing the flow rate by adjusting the final concentration, the infusion system 210 will send a message to the administering clinician. send 520 . The administering clinician can obtain permission to override the net medication tolerance 542a. The infusion system 210 may request the clinician 116 to provide a reason for the override.

The infusion system 210 can include an adjustable flow rate tolerance 542b and a flow rate adjustment tolerance for dosing. Flow rate tolerances 542 b are optionally defined for all tissue levels of patient care system 100 . Tolerances 542b can be for the entire patient care system 100 or for subsystems of the patient care system 100 . For example, different flow rate tolerances 542b may apply to subsystems such as, but not limited to, neonatal departments, pediatric departments, psychiatric departments, specific nursing departments, and specific patients. The flow rate tolerance 542b can be specified for the originally ordered flow rate or for the most recent flow rate. The clinician 116 can also specify flow rate tolerances specific to a particular order.

The infusion system 210 may include a predetermined indication as to whether the administering clinician 116 is authorized to override the flow rate tolerance 542b without requiring a new order. This display may apply to the entire patient care system 100 , subsystems, or individual clinicians 116 .

Maximum infusion duration 542d may be separately defined for various portions of patient care system 100. FIG. The maximum infusion duration 542d can also be specific to a particular drug 124. A maximum infusion duration override 566 (FIG. 8) may occur if it is allowed to override the maximum infusion duration 542d at the time of order entry. Override maximum infusion duration on administration sets whether it is allowed to override the maximum infusion duration 542d at the time of administration and which groups of users are allowed to do so. can be provided to If overriding is allowed during order entry and/or administration, the infusion system 210 can define a subset of clinicians 116 that are authorized to override the maximum infusion duration 542d.

Default values 544 include, but are not limited to, default values such as drug diluent default value 544a, diluent amount default value 544b, dose default value 544c, and unit of measure default value 544d. Units of measure (UOM) default values 544 d include the ability to specify optimal units of measure for various portions of patient care system 100 . For example, drugs can be measured in different units by physicians, medication clinicians, pharmacists, financial officers, and drug selectors. A physician's UOM is generally a measurable value such as "mmol", "mEq", "ml", and/or "mg", as opposed to "vial" and/or "puff". The doctor's UOM is used for business purposes such as ordering and information entry 560 .

A dosing clinician's UOM is generally a value that reflects the UOM that the drug is to be administered, such as "puff," "tbsp," and "tab." The administration clinician's UOM is used during drug administration 512 . The dosing clinician's UOM can also appear in dosing reports, admixture fill and manufacturing work orders, and other documentation.

A pharmacy's UOM is generally a value that reflects the physical form in which the drug is dispensed, such as "tab", "vial", "inhalator", and "jar". The pharmacy's UOM is used in the preparation 506 and stockpile and dispensing systems. Financial UOMs are commonly used to calculate financial figures that appear on invoices and packing slips. A drug screener's UOM is commonly used in screening drugs.

Default values for units of measure 544d may be specified using a check box table arranged within a table in which check marks associate various UOMs with users of the UOM. Infusion system 210 can use the same UOM for more than one function. For example, a physician's UOM can be the same as a pharmacist's UOM. Default value settings 544 contain the data necessary to tune the various UOMs. For example, UOM default values 544d may include multipliers and divisors necessary to create a one-to-one correspondence between the various UOMs. The default value of UOM 544b can be changed to suit individual clinician's needs. However, a one-to-one correspondence must be maintained by patient care system 100 . The infusion system 210 can be designed to maintain a history of dosage unit default values.

The infusion system 210 can also include a dosage measurement suffix. Medication measurement suffixes can default during order entry. A medication measurement suffix can be a common unit of medication measurement and can include units related to patient characteristics such as body surface area and weight. Medication measurement suffixes can be specified per drug, per order type, per dose, and per UOM.

Database construction 546 may include, but is not limited to, a database and/or dispensing area 546a, additive information 546b, solution 546c, premix definition 546d, preference 546e, timing override reason 546f, flow rate override reason 546g. , conversion tables 546h, flow rate descriptions 546i, equipment and routing information 546j, and message triggers 546k.

Timing override reason 546f includes a displayable reason for changing the timing of the infusion order. For example, timing override reasons 546f may include stylus-selectable reasons for digital assistant display 118a to perform an infusion order at a time other than the time specified in the original infusion order. If the clinician 116 administers the medication outside the ordered administration time tolerance 542c, the clinician 116 may be required to select a change reason code from the displayed reasons 1008f (FIG. 11). . Examples of other reason codes include, but are not limited to, PRN administration reason codes and codes for stopping infusions.

Medications 124 and/or infusion orders can have flow rate tolerances, including system flow rate tolerances 542b. Infusion system 210 may include flow rate override reason table 546g. Flow rate override reason 546g is an annotation that clinician 116 may select and/or provide when clinician 116 needs to change the flow rate beyond the limits set by flow rate tolerance 542b. The infusion system 210 may include a predefined message trigger 546k to indicate whether to send a message to the patient's physician when the clinician 116 overrides the flow rate tolerance defined by the order. The infusion system 210 also includes a predefined message trigger 546k that indicates whether or not to communicate when the clinician 116 overrides a tolerance, such as the flow rate tolerance 542b, to a level other than an order. be able to.

The infusion system 210 can include conversion tables 546h such as, but not limited to, flow rate conversion tables, variable component conversion tables, and variable flow rate conversion tables. Flow rate transformations can be, but are not limited to, dose/time, volume per unit of body weight/time, dose per unit of body surface area/time, and total dose and total dose at a particular concentration. It includes converting the infusion order into a flow rate defined by volume/time, if initially specified by a method such as duration.

Variable ingredient conversion involves converting multiple flow times for infusion orders having variable ingredients in separate infusion bags into flow rates for the infusion bag currently being administered. Orders with variable components include, but are not limited to, orders such as ordered orders. In a sequenced order, different bags have different ingredients and potentially different flow rates.

Variable flow rate conversion involves the conversion of infusion orders with varying flow rates to the flow rate for the solution currently being infused. Variable flow rate orders include, but are not limited to, orders such as bolus/basal, orders, tapering dose orders, and modified dose orders.

The injection system 210 can include a predetermined injection flow rate 542b. Predetermined infusion flow rate 542b enables selection from a drop-down list as a shortcut from keyboard entry of a flow rate that can be associated with flow rate description 546i.

Predefined functions 548 include, but are not limited to, dispensing area function 548a, bag duration function 548b, override request verification function 548c, duration vs. volume function 548d, duration vs. flow rate function 548e, and flow vs. drip rate function 548e. Functions such as function 548f are included. The infusion system 210 can include a duration-to-volume function 548d for determining the volume to infuse for each infusion order. Flow rate to drip rate function 548f uses information about medical device 330 to convert flow rate to drip rate.

The determined settings 550 include, but are not limited to, settings such as override permissions 550a, flow rate precision 550b, volume precision 550c, and time precision 550d. If desired, the infusion system 210 can determine the total infusion volume and flow rate of the infusion order. Once these numbers are determined, it is desirable to round the calculated values to flow rate accuracy 550b and volume accuracy 550c that are understandable to clinicians 116, such as physicians, pharmacists, and nurses. Flow velocity display precision 550b can be set to display flow velocity to a set number of decimal places. Various parts of the patient care system 100 can independently determine the accuracy for the displayed flow rate. For example, the infusion system 210 may display up to one decimal place for adult treatment locations and three decimal places for neonatal treatment locations. Flow accuracy 550b reflects the department in which the clinician's patient is located. Infusion order flow rates can be rounded to a system defined precision. Accuracy may be the same for all infusion orders and may depend on the patient's department.

Volume display precision 550c can similarly be set to display the infusion volume to a set number of decimal places. Configurable time precision 550d can be used to calculate the duration of a dose based on the flow rate if the infusion is a single dose infusion or an intermittent infusion. The calculated total volume for each infusion bag is rounded according to volume precision 550c. The administration time is rounded by the injection system 210 according to the set time precision 550d. The time accuracy 550d may be the same for all infusion orders regardless of patient department, or it may be department specific.

(order creation)
FIG. 8 is a block diagram showing functional components for infusion order creation 504 of FIG. Create Infusion Order 504 includes functional blocks for creating infusion orders. Infusion order creation 504 includes information inputs 560 , calculations 562 , checks 564 and overrides 566 . Information inputs 560 may include functions such as, but not limited to, order type identification 560a, drug identification 560b, dose identification 560c, diluent identification 560d, flow rate identification 560e, and injection site identification 560f.

Infusion order creation 504 is linked to infusion bag preparation 506 , infusion bag delivery (path 530 ), drug administration 512 , and infusion order modification 514 . Infusion order types 560a include, but are not limited to, order types such as single dose, loading dose, intermittent dose, and continuous dose. Continuous infusions include alternating infusions, sequential infusions, taper infusions, and titration infusions. Upon selecting the first drug 560b in an infusion order, the format of the infusion order type 560a for that drug can default. The ordering clinician may have the option of selecting different order types. Dose 560c and unit of measure 544d can also default. The unit of measure 544d can be correlated with drug and/or dose 544c. The infusion system 210 can include one default diluent or several default diluents for the drug. One default can be identified as the preferred diluent. A description can be associated with the diluent to assist the ordering clinician in deciding which diluent to select. References can be included in the description of diluents, and use of certain diluents can be avoided if the patient is hypertensive.

Infusion system 210 may also allow additional infusion order subtypes 560a based on the infusion order types previously described. Additional infusion order subtypes 560a may include, but are not limited to, TPN infusion orders, chemotherapy continuous infusion orders, piggyback infusion orders, and bolus parenteral infusion orders. The infusion order subtypes are accessible from various parts of the infusion system 210, allowing sorting and filtering of infusion orders by subtype. A special label format for each infusion order subtype can also be defined to further customize the order and associated pharmacy workflow for that infusion order subtype.

While locating medication 124 during infusion order generation 504, medication 124 may be flagged as an additive and/or solution to assist clinician 116 in infusion order generation. This designation can be made in the drug identification file.

The drug dose 560c can be determined in several ways, including but not limited to body weight, body surface area, and input depending on the rate. If no flow rate is entered, the infusion system 210 will calculate the flow rate according to the dose and time specified. The ordering clinician can specify the diluent 560d and its amount. A pharmacy may provide default values for such parameters--see line 582 (FIG. 6). A check 564 can be performed to ensure that the net concentration 564a and flow rate 564b for drug 560b are adequate.

The infusion system 210 can identify and/or calculate the flow rate 560e based on the patient's weight, body surface area, and/or specific treatment frequency and duration of treatment. The ordered flow rate 560e is checked 564b against a flow rate tolerance, such as system flow rate tolerance 542b. The net concentration of drug 124 may be checked 564a against a net concentration tolerance, such as system net concentration tolerance 542a.

In one embodiment, the flow rate 560e may also include a display of a default flow rate description to facilitate order entry. The flow rate 560e can refer to the flow rate description database 546i.

Calculations 562 may include calculation of dosage based on patient weight and/or height (possibly provided by ADT interface 310), amount of drug, amount of diluent, concentration, or rate. Calculations 562 include, but are not limited to, the flow rate, the quantity of bags 562a if not specified in the prescription or the number of infusion bags required at a particular time, the time each infusion bag will be administered, and It can include calculating the total volume of each infusion as well as the total volume of each infusion bag based on the concentrations of the components in solution. The flow rate, amount to be injected and/or duration can be varied. If changed, the infusion system 210 automatically calculates the amount dependent on the change, and based on the calculation, if the maximum dosage for the component at that concentration exceeds that specified in the drug file for that component: The patient care infusion system 210 can alert the pharmacist and/or clinician 116 and request a reason code for the adjustment.

Calculations 562 may include calculations such as, but not limited to, bag volume calculations 562a, conversion calculations 562b, duration to volume calculations 562c, and flow rate to drip rate calculations 562d. Checks 564 include various checks that an infusion order may undergo. The checks include, but are not limited to, net concentration check 564a, flow rate check 564b, administration time check 564c, duration check 564d, and injection site check 564e. If an infusion order fails a check 564, the clinician 116 can override the check. Overrides 566 may include overrides such as, but not limited to, net concentration override 566a , flow rate override 566b , administration time override 566c , duration override 566d , and injection site override 566e . The override 566 can generate 520 a message to the doctor and/or pharmacy. The infusion system 210 can distinguish between system-wide overrides and subsystem overrides in determining whether it is necessary to generate 520 a message.

Overrides can include an indication of whether the clinician has the authority to override tolerances. For example, flow rate override 566b may indicate whether the clinician entering the infusion order has the authority to override the system's flow rate tolerance 542b. This representation may be applied to patient care system 100 or subsystems. Duration override 566d may indicate whether the clinician 116 entering the infusion order has permission to override system duration 542d. This representation may be applied to patient care system 100 or subsystems. Override 566 also includes an indication of reason for override 566f . Override reason 568f may be selected by clinician 116 from a drop down menu.

The result of infusion order creation 504 is infusion order 702 . Infusion order 702 may include infusion schedule 704 . As long as the infusion order 702 is active, the infusion system 210 can predict the time and generate an infusion schedule 704 for filling the infusion bag for that time, if not specified on demand. The ordering clinician does not need to specify an end date for the infusion order. The infusion system 210 can include automatic scheduling of infusion bag delivery based on tolerances 542 defined in the infusion system 210 .

(order preparation)
FIG. 9 is a block diagram showing functional components for infusion order preparation 506 of FIG. Infusion preparation 506 includes functional blocks for preparing infusion orders 702 (FIG. 8). Infusion preparation 506 can include, but is not limited to, preparation location determination 506a, ingredient scan 506b, bag duration check 506c, and bar code printing 506d for medication label 124a. Barcode printing 506d may include the functionality described above with reference to label printing 326 (FIG. 4).

After an infusion order is entered into the infusion system 210, preparation instructions are routed to preparation locations. The preparation location depends on the preparation program 506 and injection elements of the injection system 210 . Infusion system 210 may include an adjustable database, such as preparation area database 546a, that identifies where infusion orders are to be prepared. Infusion orders can be prepared at a pharmacy or at a remote location such as a floor or treatment location 106 . The clinician 116 is guided through the preparation process, including barcode verification of ingredients, using event management information that can be displayed on a digital assistant 118 or other device with a display.

Medication label 124a identifies the ingredients and ingredient concentrations. Medication label 124a can be printed at any location. Medication label 124a preferably includes bar code printing 506d. Bar code printing 506d can include bar code label 124a printing for each infusion bag. Label 124a helps ensure that the correct medication is administered at the correct time and/or in the correct order. Alternating and sequential infusion orders are particularly prone to mis-sequence and mis-timing. Barcode printing 506 d may include printing a unique barcode label for each bag in infusion order 702 . Barcode printing 506d can also include printing a barcode label 124a that uniquely identifies the combination of ingredients and concentrations of those ingredients within the infusion bag. Barcodes for medications 124 may include prefixes, suffixes, and National Drug Codes (NCDs). In one embodiment, the barcode may also include lot and expiration. Alternatively, separate barcodes containing lot and expiration may be provided. Other embodiments of barcodes may be used, including active or passive RFID tags, magnetic strips, and the like.

(drug administration)
FIG. 10 is a block diagram showing functional components for drug delivery 512 of FIG. Medication administration 512 includes functional blocks used to administer medication to patient 112 . Medication administration 512 includes reading medication barcode 512a, reading patient barcode 512b, performing expiration date check 512c, notifying titration 512d, displaying flow rate vs. drip rate 512e, starting "anytime" infusion 512f, downloading operating parameters 512g. , and time monitoring 512h. The infusion system 210 can also convert orders, which may have one or more flow rates, such as tapering orders and alternating orders, into flow rates for the infusion bag currently being administered. The infusion system 210 can also convert orders with infusion bags containing different ingredients, such as sequential orders, into flow rates for the infusion bag currently being administered.

Upon administration of medication 124, clinician 116 scans medication label 124a. The infusion system 210 includes scanning the barcoded label 124a to initiate the execution of an infusion order, change the flow rate, change the bag, and/or stop the infusion order. The infusion system 210 verifies that the infusion bag with the barcoded label should be administered at the time and to the patient 112 . A history of drug administration, including flow rate and amount administered, can be collected and maintained. Some infusion orders require the hanging of the infusion bag with the intention of administering a specific amount of only a portion of the infusion bag. Infusion system 210 allows clinician 116 to order a dose of an infusion bag. Most infusion pumps have the ability to define the amount or flow rate and time to be administered. Once this time has elapsed, the infusion pump automatically prevents further administration. The infusion system 210 provides a message on the drug label 124a that it should be partially dosed and the proper amount should be dosed as a reminder to the dosing clinician.

The flow rate versus drip rate display 512e uses the data generated by the flow rate versus drip rate function 548f to provide the administering clinician with the drip rate for the current infusion bag. During drug administration 512, clinician 116 can use digital assistant 118 to check flow rate and other operating parameters. Flow rate changes 1002b (FIG. 11) are communicated in real time.

The injection system 210 may include initiation 512f of a PRN injection or an "on demand" injection. An "anytime" infusion start 512 causes the creation of a new active order and the dispensing of PRN medication. This option includes prompting the clinician 116 to select a PRN infusion from a list of previous PRN orders placed for the patient, and setting the requested infusion bag default value to one. can be done. The clinician 116 may have the authority to change the amount of infusion bag requested.

Downloading operating parameters 512g includes determining whether the patient identifier associated with the care and/or the patient identifier retrieved from the wristband 112a is the same as the patient identifier associated with the care at the central location. can be done. The determination is often made by a first computer, eg, first central server 109 . If the infusion system 210 determines that the various patient identifiers are not the same, the system can generate an alarm message 520 . If the infusion system 210 determines that the various patient identifiers are the same, the infusion system 210 can download the operating parameters directly to the medical device 332 . The infusion system 210 can send operational parameters to a medical device 332 such as the infusion pump 120 .

One advantage of the system program 210 is that the operating parameters for the medical device 332 can be used by the digital assistant 118 or any other computer at a remote location before the operating parameters are available to program the medical device 332 . The point is that there is no need to pass through. Bypassing the remotely located computer eliminates a potential source of error in administering medication 124 to patient 112 . Operational parameters for medical device 332 can be sent "directly" to medical device 332, assuming various validations are achieved. In this context, "directly" means that operational parameters can be sent to the medical device without passing through the digital assistant 118 or any other computer at a remote location.

In another embodiment, the infusion system 210 can include an additional block (not shown) in which the central computer receives the second medication identifier. A remotely located clinician 116 may enter a second medication identifier. The second drug identifier can be a revised first drug identifier. For example, the second medication identifier can be part of the prescription or electronic physician order that is the source of the first patient ID and operational parameters. The infusion system 210 can then verify that the first and second drug IDs are equivalent before sending operating parameters to the medical device. The second medication ID may replace the revised first medication ID between the time the prescription is entered and the time the medication 124 arrives at the treatment location 106 . The infusion system 210 will then sound an alarm if the second drug identifier is not equivalent to the first drug identifier that was included in the drug label 124a. In yet another embodiment, injection system 210 may include additional blocks (not shown) by which operating parameters are used to program medical device 332 .

Various blocks of infusion system 210 , such as block 512 , may include functionality for displaying treatment information on digital assistant 118 . This may include the ability to display information that accurately mirrors the information on display 120 c of infusion pump 120 . The information on display 120c of infusion pump 120 can be supplemented with information about patient 112, patient location, and infusion order. This information may include information about multiple channels of infusion pump 120 . The information displayed may include, but is not limited to, information such as personality, prompt lines, status lines, operating icons and lift indications. Operational icons include drip, stop sign, flow check piggyback, and delay start. The lift display includes information such as drug label and infusion rate. Those skilled in the art are familiar with the display information and operation icons described above.

The time monitoring function 512h of the infusion system 210 calculates the time remaining to complete the order and the amount of infusion order remaining to be administered. When the clinician 116 uses the infusion system 210 to fill infusion orders, change flow rates, and check infusion status, the infusion system 210 calculates the time and volume remaining to be administered, and the calculated results are stored in the bag. If you have indicated that you will be using a portion of For example, upon the last bag of an order that should be stopped before the full dose is administered and/or upon the bag of an order that should be replaced before the full dose is administered, the clinician 116 may contact the digital assistant 118 and/or Receive alerts on cart 132 . The alert may include a message such as "Dose only 150ml".

Time monitoring 512h includes the ability to track any changes made to flow rate using barcode scanning. The pharmacy is notified in real time to adjust the next required infusion bag preparation 506 according to the changes. Monitoring preparation 506 and drug administration 512 allows for just-in-time delivery of drug 124 . Just-in-time delivery reduces waste due to canceling or modifying infusion orders. Monitoring also ensures patient 112 safety.

For PRN order titrations, the clinician 116 is automatically notified of the required flow rate change if the titration conditions in the order indicate that the flow rate must be changed. The injection system 210 includes a predefined function for calculating the conversion of flow rate to titration rate 548f. The values defined by injection system 210 may be adjustable. The infusion system 210 can include automatic conversion 548f of flow rate to drip rate to assist the clinician 116 while administering the procedure.

(Documentation and modification of orders)
FIG. 11 is a block diagram illustrating functional components for infusion order documentation 1012 and infusion order modification 514 and messaging 520 of FIG. Modify 514 includes functional blocks used to modify existing infusion orders. Modifying 514 can also be viewed as creating new orders and updating existing infusion orders. Modifications 514 include modification changes 1002, normal all ordering options available for new orders 1004, recheck 1006, recheck override 1008, and new flow rate versus new drip rate display 1010. be able to. Modification of infusion orders often leads to documentation 1012 and messaging 520 . Modification 514 includes the functionality described with respect to prescription modification module 336 (FIG. 4). However, modifications 514 may also be accessed from other portions of patient care system 100 such as, but not limited to, prescription entry 324 , prescription activation 306 , and prescription authorization 308 .

Modifications 514 include modify duration 1002a, modify flow rate 1002b, use new infusion site 1002c, identify reason for modification 1002d, identify infusion bag volume 1002e, and process stop orders 1002f. The clinician 116 may also change the infusion rate without ordering if the patient 112 is complaining of discomfort, such as when the patient 112 is vomiting, or to promote fluid balance.

Revision changes 1002 include identification of new duration 1002a, identification of new flow rate 1002b, identification of new injection site 1002c, identification of correction reason 1002d, identification of remaining amount in infusion bag 1002e, stop order 516. be The ordering options available during initial infusion order creation 504 are generally also available for modification of the infusion order. The ordering options available during initial order creation 504 include those shown in FIG. Recheck 1006 and recheck override 1008 are similar to check 564 and override 566 described with reference to FIG. The new flow rate versus new drip rate display 1010 helps the clinician minimize the potential for error during drug administration 512 . A modified infusion order can result in a modified infusion schedule.

The flow rate is frequently modified at the treatment location 106 for reasons such as to catch up if an infusion is inadvertently stopped briefly without rescheduling dispensing. Such modifications may not require a new infusion schedule 704 to be communicated to the pharmacy. In other cases, the new schedule 704 must be communicated to the pharmacy or other dispensing staff. Flow rate modification 1002 b triggers rescheduling of infusion orders and/or messages 520 to appropriate clinicians 116 .

When the clinician 116 enters the flow rate modifications 1002b into the infusion system 210 at the treatment location 106, the clinician 116 may also choose to recalculate the infusion schedule 704 and send it to the pharmacy. The clinician 116 has the option of requesting new medication labels 124a to be printed by the barcode printing 506d module. New medication label 124a includes data reflecting new information about any of the previously prepared infusion bags.

The injection system 210 and/or the clinician 116 can request modification 1002c of the injection site. Sites can be selected from a list of anatomy on a computer screen. The clinician 116 may be requested to identify 1002d the reason for the revision. Reasons stored in the database, such as, but not limited to, timing override reasons 546f and flow rate override reasons 546g, may be displayed for easy identification by the clinician 116. There may be separate hard-coded reasons for physician-ordered revisions. For physician-ordered revisions, the clinician 116 may be required to identify the physician.

Prior to performing the modification, the amount remaining in the current infusion bag is identified 1002e. The clinician 116 may be provided with the option of receiving the calculated volume from the unmodified flow rate and/or volume readings.

If desired, the current injection can be stopped 1002f. If an order stop is not required, for example, the same infusion bag can be used with a new flow rate and/or a new additional drug, and the old flow rate can be identified and compared to the modified flow rate.

Any previously prepared infusion bags can be checked for expiration based on the new infusion schedule 704 . When an infusion order is resumed after a temporary suspension or order hold, an expiration check can be made for expiration of the solution that has already been prepared.

The new infusion schedule 704 is used to control preparation 506 at the pharmacy or other preparation location. System defaults 544 can be set as to whether any prepared bags should be credited to the patient 112 through the billing interface 312 and whether they should be credited to inventory. .

Infusion order change 1002 includes all ordering options 1004 available for new orders. The revised flow rate can be rechecked 1006 for rules and tolerances such as, but not limited to, net concentration 1006a, flow rate 1006b, administration time 1006c, duration 1006e, and injection site 1006f. Overrides 1008 may be available for out-of-tolerance corrections. The infusion system 210 can display 1008f reasons for overrides and medications being administered at times other than those specified in the original order. The clinician 116 can be requested to identify the reason for the revision.

The infusion system 210 can provide the clinician 116 with a display showing the modified drip rate associated with the modified flow rate 1002 . Display information can be calculated by a predefined function of flow velocity versus drop velocity 548f. The infusion system 210 can also be provided with a description of typical infusion tubes used within the infusion system 210 for use in calculating the drip rate.

The modifications result in the infusion system 210 confirming that the infusion bag has expired and providing a message to the clinician 116 if the infusion bag expires before the order is completed. The message may request the clinician 116 to contact the pharmacy. Checking the expiration of an infusion bag for solutions such as, but not limited to, pre-mixed solutions and solutions manufactured outside the infusion system 210 can include parsing of scan codes.

Flow rate override 1008b may indicate whether the clinician 116 modifying the infusion order has the authority to override the ordered limits without requiring approval for the new infusion order. This representation may be applied to patient care system 100 or subsystems.

Documentation 1012 captures infusion order information in real time. Documentation includes, but is not limited to, multiple concurrent injections, and documentation of duration changes 1012a , flow rate changes 1012b , volume changes 1012c, and injection site changes 1012d .

The infusion system 210 can help the clinician 116 capture any changes in flow rate as they occur. The clinician 116 can make any required flow rate changes in the infusion order, such as reducing the flow rate of the morphine infusion from 4 ml to 2 ml. Although the infusion system 210 can recognize the change as a new order, the infusion system 210 can be configured to avoid duplication so that the modified order does not result in the production of new bags.

Documentation 1012 includes, but is not limited to, the ability to document changes such as infusion pause, infusion stop, and/or infusion restart. The clinician 116 may stop the injection for a variety of reasons, such as a defective injection site, a missed injection, etc., and/or heparin/saline injection to facilitate patient 112 movement. can be locked. Infusion can resume when a new site/infusion is restored. However, the length of time allowed for this may be variable and is typically recorded by injection system 210 .

Government regulations often require tracking of all stops in the process of infusion administration. The infusion system 210 allows the administering clinician 116 to scan the drug label 124a and adjust the flow rate 1002a based on tolerances, such as those generated by the tolerance settings 542, to allow the digital assistant 118 or other computer to Allows documentation of flow rate modifications on the device. The flow rate modification 1002 b corresponds in real time to the relevant pharmacy infusion schedule 704 to ensure just-in-time infusion bag inventory for the patient treatment area 106 . Documentation 1012 may enable retroactive application of orders under certain circumstances.

The injection system 210 includes functionality for documenting injection sites 1012d and multiple injections 1012e for multiple injection sites. In many situations, a patient 112 will have multiple drugs 124 and "pending" infusions, such that some infusion drugs flow into one site and other infusion drugs flow into another site. For example, morphine infusion, antibiotics and saline infused into the right arm (site 1) and 2/3 & 1/3 flowing into the TPN and dual lumen CVL (site 2). The injection system 210 allows the clinician 116 to document through which site the various fluids are being injected. In a treatment location 106, such as an intensive care unit, more than one infusion drug can flow into a single line or lumen. The clinician 116 can indicate to which lumen of the CVL the infusion or drug is flowing.

The injection system 210 includes the ability to document the site location 1012d for injection and any site location changes. Infusion sites are frequently changed due to occlusions or strategies. Therefore, the clinician 116 must document changes in site location when infusion is removed and then resumed.

The infusion system provides a centralized device configuration. Operating parameters for medical devices such as infusion pump 120 often include default values and/or acceptable ranges. Default values and/or tolerances, such as flow rate tolerances 542 b , can reside in memory associated with infusion system 210 and/or device 332 . For example, infusion pump 120 may include a database having a table of medications with associated flow rate tolerances. If the clinician 116 enters a flow rate that exceeds the associated flow rate tolerance, the clinician 116 is warned and then allowed or prohibited from continuing. Devices 332, such as heart rate monitors, may also have configurable tolerances for alerts. In addition to alerts, many other characteristics such as network name, IP address, polling frequency, and color can generally be set for device 332 . Infusion system 210 includes the ability to configure medical devices 332 individually or in groups from one or more central computers.

System configuration parameters may be defined for a first type of medical device. System configuration parameters are sent and received by devices of the first type unless the particular device of the first type has more specific configuration parameters that apply to that particular device of the first type. . For example, a first plurality of first type medical devices may be located at a general medical procedure location. A second plurality of first type medical devices may be located at the location of the focused medical treatment. A general medical procedure location may not have specific set-up parameters, while an intensive medical treatment location may not have specific treatment parameters. The system configuration parameters apply to all first type medical devices throughout the infusion system 210, i.e., devices within general medical care locations, unless the specific configuration parameters apply to, for example, an intensive medical care location. will be

For each type of equipment, the parameters that apply to all equipment of that type across equipment in a particular group are defined by the specific configuration parameters if the particular equipment belongs to a group having such a definition. overrides the system configuration parameters unless is overridden to a more specific level within the infusion system 210 . Groups may be defined as clinical services, nursing rooms, and/or combinations of services and nursing rooms.

For each type of instrument, the user can define a set of configuration parameters that apply to all instruments of that type used in operations with a specified range of attributes that override any other definitions. In a hospital, an operation may consist of an infusion order and attributes that may include patient weight, medication, patient condition, and patient severity.

Devices can be associated with a particular patient by identifying them as part of a general group, a specific group, and/or by including device addresses in tables in the database. General or specific configuration parameters can then be sent to the device according to the device's identity. That particular configuration parameter can then be read back to the infusion system 210 and compared to the originally transmitted configuration parameters to confirm that the initial configuration parameters were correctly received by the device 332 . If the configuration parameters were not received correctly, the infusion system 210 can provide a message 520 identifying a discrepancy or communication failure.

The infusion system 210 can detect changes to configuration parameters made at the device without going through a central computer and send messages and/or alerts 520 . The infusion system 210 can also poll devices to confirm their configuration parameters. When a system and/or particular configuration parameter changes, the change can be propagated to all devices 332 identified in the system as belonging to groups according to the groupings identified in the infusion system 210.

Throughout this document and related claims, "central location" and "remote location" are terms relative to each other. A “remote location” is any location where a patient is being treated through a controlled medical device, such as patient treatment location 106 where patient 112 is being treated through infusion pump 120 . A “central location” is any location other than a remote location where the parameters for operating the medical device are accessible, such as, but not limited to, the location of the pharmacy computer 104 and the central system 108 . In a typical arrangement, several remote locations, such as treatment site 106, communicate with the central location.

Although the present disclosure focuses on the use of infusion pump 120 within system 210, it is understood that other medical devices may be used within system 210 without departing from the scope of the present invention. For example, various types of medical devices include, but are not limited to, infusion pumps, ventilators, dialysis machines, and the like. An additional class of medical devices are micro-electro-mechanical systems (MEMS) components. MEMS is a technology used to create extremely small devices that can be sub-millimeter in size. MEMS devices are typically fabricated from glass wafers or silicon, but this technology has grown well beyond its origins in the semiconductor industry. Each MEMS device is an integrated microsystem on a chip that can incorporate moving mechanical parts in addition to optical, fluidic, electrical, chemical and biomedical elements. The resulting MEMS devices or elements respond to many types of inputs including pressure, vibration, chemicals, light, and acceleration. The MEMS component can be several different elements including various types of pumps, flow valves, flow sensors, tubes, pressure sensors or combinations of elements.

Accordingly, one use of the MEMS components is as an in-line MEMS pump 5314, shown schematically in FIG. 53, as further described in detail below . MEMS pump 5314 can pump fluid contained within IV bag 5320 through tube 5312, through access device 5324, and from there into the patient's body. The MEMS component has a MEMS local electronics element attached to it, the MEMS electronics element connecting to an external ruggedized MEMS controller, the MEMS controller described herein. It can communicate with the system 210 like the infusion pump 120 of the present invention described in the literature. In one embodiment of the MEMS pump 5314, the MEMS electronics 5332 are embedded in the MEMS pump 5314 and are preferably capable of storing operational information for MEMS parameters. A MEMS controller with its electronics and power supply can be physically or wirelessly connected to the MEMS electronics elements. In one embodiment, the parameter manipulation information can be loaded from removable MEMS controller 5338 . Pump element 5314 preferably generates fluid flow through tube 5312 based on information stored locally within MEMS electronics 5332 . This information is preferably downloaded from a hardwired but removable MEMS controller 5338 . In addition, MEMS components can communicate with system 210 via wireless communication. In addition, the MEMS controller is capable of transferring information to and from system 210, fully automating the control and interrogation of MEMS components within system 210 through wireless or wired communication paths.

The use of MEMS or other emerging economical manufacturing technologies provides the opportunity to add MEMS elements to disposable line sets to provide additional functionality such as pumping, valving, and sensing. Some or all of the supporting local electronics could be included in the disposable portion of the lineset. For example, it may be preferable to include a memory chip containing calibration information for a combination of pumps, pressure sensors, and/or flow sensors, valves, or disposable elements. Disposability is desirable because it eliminates the need for costly sterilization of system components between each subsequent application.

(popup window)
In one embodiment, the system can automatically provide the clinician with information related to one or more medications via pop-up windows. The medication table is preferably entered into central database 108b. A drug table may include generic names for one or more drugs and any trade names associated therewith. Linked to each drug in the drug table is a respective message for display via a pop-up window. Messages may be defined by the medical facility or predefined by the system supplier. Messages associated with each drug include: 1) hazards associated with the drug, e.g., when handled or exposed; 2) how the drug is administered by the clinician; 3) physician reference information regarding the drug; and 5) warnings regarding injection setup procedures such as opening roller clamps for piggyback injections.

Pop-up windows indicate when a drug is in the computing device, such as when the drug is being ordered by a physician via CPOE, when the drug is being processed by a pharmacy or the like, and when the drug is being administered to a patient by a clinician. displayed when selected or entered in In one embodiment, upon completing the selection or entry of a medication on the remote computing device, a database within the central system 108 is accessed and at least one of the pop-up window messages associated with the medication is sent to the remote computing device. provided to the device and displayed to the clinician.

At least one of the pop-up window messages associated with the medication is preferably provided for display upon initiation of particular steps of the medication order, processing and administration procedures. For example, upon entry of a drug into a computing device, such as a CPOE, a pop-up window with a message regarding physician reference information regarding the drug is displayed, and in one embodiment, another pop-up window regarding risks associated with the drug is displayed. be able to. Then, upon processing of the order by a pharmacy or the like, one or more pop-up windows are displayed on the computing device 104 within the pharmacy to provide general information about the drug and possible hazards associated with the drug. . Then, when the order is being fulfilled by the clinician, the clinician is provided with information regarding the administration of the drug and, in one embodiment, possible hazards associated with the drug, such as how to handle the drug. One or more pop-up windows are displayed on the associated computing device (ie handheld 118).

The pop-up windows displayed on the computing device are preferably specific to the medication order, the transaction, and the step in the administration procedure being performed by the clinician. For example, pop-up windows containing physician reference information are preferably not displayed to nurses via handheld device 118 . Nevertheless, in one embodiment, a user or hospital can define when and if a pop-up window should be displayed when a medication is selected or entered into a particular computing device.

The pharmacy also preferably defines when and when the pop-up window should be displayed. For example, pop-up windows are preferably not displayed for over-the-counter medicines. Instead, the pop-up window is preferably displayed for medications that the pharmacy or medical facility believes additional information in the pop-up window will assist in ordering, dispensing, or administering the medication.

(Administration of drugs)
A method of administering drug 124 with infusion system 210 is described below. The method includes the ability to modify the infusion order. Modifications include modifying the flow rate, infusion site, pausing the infusion, resuming the infusion, and hanging a new drug 124 container. The method comprises the steps of scanning a barcode 512b associated with the patient, scanning a barcode 512a associated with the medication, checking 512c for expiration if the infusion is a mixture, and reason for correction. and recording the remaining amount of the infusion bag or receiving a value calculated from the previous volume and flow rate 1002e. Infusion bag expiration confirmation 512c can include the use of mixture tables and/or barcodes.

Reasons for modification can be selected from predefined table 546g. Modification reasons can also include hard-coded values for physician-ordered changes. If the hard-coded value is selected, the clinician 116 will be prompted to select a physician from a list of physicians. The attending physician can be the default value in the list of physicians.

There may be a quick select function to stop administration of drug 124, eg stop order 1002f. If rapid selection is not selected, the following steps can be included. Recording the flow rate and/or receiving a pre-value for the flow rate--the pre-value is displayed on the digital assistant's display 118a, on the infusion pump's display 120c, and/or on the medical cart 132; Comparing the calculated flow rate—this comparison can be accomplished using rules and tolerances of the infusion system 210 or subsystem; displaying an appropriate message; converting between the flow rate and the drip rate. The 1012-conversion that may be displayed may be calculated based on the infusion system 210 pre-defined drip rate conversion table 548f. The infusion system 210 generally uses a tube-based description to facilitate the clinician's 116 selection of the correct infusion rate transformation.

Changing the flow rate triggers the infusion system 210 to check the expiration date of the infusion bag based on the expected flow rate. If the solution expires before or during administration, a message is sent to the clinician 116, for example, "This solution will expire during the scheduled dosing period. Please contact the pharmacy." If it is a premixed infusion bag and/or a customized infusion bag, the expiration date is verified by parsing the scan code, if possible. A pre-injection site is accepted or a new injection site location is selected from a list or graphical anatomy. The schedule 704 is then recalculated and pharmacy restocking is performed. Infusion system 210 may include biometrics to identify the patient and clinician 116 .

Prior to authorizing clinician 116 to access infusion system 210 , infusion system 210 accesses information related to the identity of clinician 116 . The infusion system 210 may identify the clinician 116 using a device such as a barcode reader to read the clinician's 116 badge 116a. The system also provides for positive identification of the clinician 116, to ensure that the clinician is an authorized user of the system, and to authorize the clinician 116 to access portions of the infusion system 210. Biometrics can also be used to determine if you have. The infusion system 210 may require a combination of a clinician badge 116a, or other key, and a verified biometric match to authorize the clinician 116 to access the infusion system 210. FIG. The system is also configured to terminate access to the infusion system 210 when the clinician badge 116a is removed from the vicinity of the clinician badge 116a, or other device used to read the key. can also

Biometrics is the art and science of statistically analyzing measured biological data. One field of biometrics is that which determines a unique physical characteristic, such as a fingerprint. Biometrics allow an individual to be identified to a digital system such as infusion system 210 . A digital persona is created, making transactions and interactions more convenient and secure. Biometric features for identification include, but are not limited to, features such as fingerprints, facial, iris and retina scans, and voice identification. A biometric device includes a scanning device or reader, software for converting the scanned information into digital form, and storage for storing biometric information for comparison with stored records. The software identifies specific points of agreement in the data processed by the algorithm and compares the data. Unlike passwords, PIN codes, and smart cards, infusion system 210 biometrics cannot be lost, forgotten, or stolen.

A biometric scanner may be associated with a device for reading the clinician's 116 badge 116a. For example, a biometric scanner can be a thumb print reader on the handle of a barcode reader. In another embodiment, biometric scanners and electronic key readers may be located on portable medication carts and/or medical devices. When the clinician 116 places the electronic key within a certain distance from the medical device, the processor will know the particular individual's electronic biometric identification file it should seek. Infusion system 210 preferably prompts clinician 116 to scan his biometric information. Biometric information is entered into infusion system 210 by some type of biometric reader or biometric scanning device. A one-to-one comparison is made between the scanned biometric information and a pre-stored electronic biometric identification file for the particular individual. This one-to-one match comparison is more efficient than a one-to-many match file because it does not require searching the entire clinician database for matches. Instead, only one specific comparison is made. If there is a match, then clinician 116 is granted access to medical device 332 . If there is no match, the clinician 116 is denied access.

Furthermore, in another embodiment, the medical device does not have a controller. For example, the medical device can be a pumping device that does not have a controller, or rather simply receives control signals from a separate controller. In one embodiment, the controller for such medical devices can be a first central computer 109 . Therefore, the first central computer 109 can send control signals directly to the medical equipment to control the medical equipment.

In another embodiment, after the infusion system 210 has granted access to the clinician 116, the infusion system 210 may deny that access when the electronic key is removed from the biometric scanner or proximity to the biometric scanner. finish. The proximity within which the electronic key must be held may be predetermined and/or may be a variable programmable infusion system 210 parameter.

In one embodiment, the infusion system 210 includes an encrypted digital fingerprint template, the clinician's name, login name, and password. One technology for implementing clinician identifiers includes the "IBUTTON 400" provided by Dallas Semiconductor technology. The injection system 210 can be activated when the clinician places his finger on the fingerprint scanner. Once the infusion system 210 finds a match, the infusion system 210 can request the clinician 116 to log into the infusion system 210 . If the infusion system 210 does not find a biometric match, the system will not allow the clinician 116 to access the infusion system 210 .

In another embodiment, a database storing biometric information may be maintained within central system 108 , pharmacy computer 104 , and/or treatment location 106 . At the point of care 106 , this database may be maintained within the portable cart 132 , digital assistant 118 , and/or medical device 332 . Such a distributed database allows remote devices to be accessed even if the network 102 is unable to communicate between the various locations. When network 102 communication is restored, the remote and central databases can be synchronized with any information modified elsewhere, so that both infusion system 210 databases can be updated appropriately.

Infusion system 210 provides a closed-loop infusion therapy management system. The closed loop begins with clinician 116 orders. Among other methods, clinician 116 may enter orders through digital assistant 118 and/or medical cart 132 . The order is then available in real time for pharmacy authorization 508 and physician authorization 510 . Orders are available in real time as an electronic medication administration record (eMAR). The eMAR is available to the clinician 116 for infusion administration. The infusion system 210 automatically documents drug administration 512 and modifications 514 such as flow rate changes 1002b. Through the drug administration 512 process, the infusion system 210 simultaneously coordinates inventory and billing 518 of the infusion system 210 and/or subsystems. The infusion system 210 also provides event management and decision support data. The infusion system 210 is device independent in the sense that it can operate on workstations, wireless tablets, and handheld digital assistants 118 . Although the injection system 210 typically operates in real time, batch processing and other messaging can be used to coordinate various stages of the injection system 210 process.

The closed-loop infusion therapy management system includes infusion order entry 560, order preparation 506, and infusion status availability. Infusion order entry 560 is possible through several means including, but not limited to, prescription entry module 324 , prescription modification module 336 , and pharmacy interface 316 . Computer screen 400 may be used in entering infusion orders. The infusion status provides infusion usage by patient 112 and informs the pharmacy of the need for additional infusion bags.

(Clinician interaction with infusion system)
Additionally, the infusion system 210 can use a login system to determine whether the clinician 116 has access to the infusion system 210 . An example of a login system interface screen for infusion system 210 is shown in login screen 1903 of FIG. In the interface screen, clinician 116 enters both a username and password and clicks the "login" key. System 210 checks to ensure that the username and password are valid for system 210 . If either the username or password are not valid, the system 210 will notify the clinician 116 that the login was unsuccessful at the login screen 2005 shown in FIG. Clinician 116 will then have the opportunity to re-enter the username and password to correct any errors. If the username and password are valid, clinician 116 will have access to system 210 . Additionally, if the clinician 116 logs into the digital assistant 118 but does not use it for a period of time, security measures in the system 210 prevent further use of the digital assistant 118 until the clinician 116 logs in again. be.

A lead clinician can also log into the system 210 . As described in detail herein, the lead clinician is typically the clinician's direct supervisor or a designated person. Additionally, the lead clinician may be a person who assists the clinician in workflow or assists in monitoring alarm or alert conditions. Generally, the lead clinician retains at least one department-wide oversight or responsibility role. Therefore, the lead clinician must log in with the above login and password and then select the department associated with the lead clinician.

After the clinician 116 has completed the login process shown in FIG. 19 and has been granted access to the system 210, the clinician 116 can perform several administrative functions. One such management function is the selection of departments. As shown in department selection interface screen 2105 of FIG. 21, clinician 16 may select a department from drop down menu 2107 . In the example shown in FIG. 21, the clinician 116 has selected "Neurology ICU" as the department. After clinician 116 selects the appropriate department from drop down menu 2107, clinician 116 can press arrow key 4809 to enter the selected department.

Another administrative function that the clinician can perform is selecting the clinician's shifts. As shown in the shift selection screen interface 2211 of FIG. 22, the clinician 116 can select either standard shifts or customized shifts. Several selectable standard shifts are provided in drop-down menu 2107 for that entry. However, if the clinician 116 selects a customized shift, the clinician is required to enter the start and end times for the customized shift. The clinician 116 can also manually enter the shift in the provided area 2255 and then tap the enter key 4809 .

A View Patient interface screen 2313 is shown in FIG. In this screen 2313, the clinician 116 can see the patients associated with the clinician 116 after a shift has been selected. A clinician 116 can also view the work associated with the clinician 116 . Thus, a "to do" list can be provided based on the patient, the clinician's work, or both. Different levels of shading and/or coloring may be utilized to distinguish between levels of emergency medical care required for a particular patient. Additionally, various icons can be used in association with the patient to help the clinician 116 quickly understand the medical needs of the patient. View Patient interface screen 2313 of FIG. When the clinician 116 selects the "Add Patient" key 2315, the clinician can be provided with a list of additional patients.

Clinician 116 may also be provided with patient selection interface screen 2417 shown in FIG. This screen 2417 allows the clinician 116 to select patients to add to the clinician's shift. Patients may be from departments associated with the clinician, or clinicians may choose to add patients from different departments. Clinicians 116 can also select the time they will be with the patient. In addition, clinician 116 can also find more patients with key 2419 . It is also understood that the clinician 116 may remove a patient from the shift at any time.

The system 210 can also provide messages to the clinician 116 specific to the patient assigned to the clinician's shift. General messages can include items such as order profile changes and medication administration errors.

A patient information menu interface screen 2521 shown in FIG. 25 is also available on the system. Patient information menu screen 2521 provides a miniature patient chart for the selected patient. The patient menu screen 2521 also links the clinician 116 to patient-related items such as drug/infusion administration, infusion stop, infusion restart, infusion titration, flow rate history, pump status, and patient removal from shift. It also provides functionality. The patient menu screen 2521 also has tabs for allergies and Ht/Wt, medication history, and laboratory results. An example of an allergy and Ht/Wt interface screen 2521a is provided in FIG. 25A . Normally, this screen 2521a is displayed when the mini chart is first opened. It displays information about the patient's drug and general allergies, and the latest record of the patient's height and weight. An example of a medication history interface screen 2521b is provided in FIG. 25B . Generally, this screen 2521b provides the clinician with the patient's medication history within the selected lookback period. The lookback period can be adjusted by the clinician. Finally, an example of a test result interface screen 2521c is shown in FIG. 25C . Test results are made available at system 210 through the laboratory interface. All available results are shown and displayed in reverse chronological order.

An infusion schedule interface screen 2623 for a patient is shown in FIG. This screen 2623 shows the infusion schedule for the selected patient. Clicking on one of the identified orders, such as order 2625 for morphine sulfate on infusion schedule screen 2623, will cause system 210 to link to drug order interface screen 2627 shown in FIG. 26A . Medication order screen 2627 provides order details 2625 for a particular order (ie, morphine sulfate). As part of detailed order 2625 , treatment parameters 2629 are provided along with the ability to link to warnings 2631 and additional information 2633 .

FIG. 28 shows a patient profile infusion schedule interface screen 2835 in which one of the scheduled infusions has failed. As shown in screen 2835 , a “medication failure” icon 4837 is shown next to the scheduled morphine sulfate infusion order 2839 . By clicking the "Medication Failure" icon 4837, the system 210 links the clinician 116 to the medication failure interface screen 2941 shown in FIG. Medication failure screen 2941 requests clinician 116 to enter or select in drop-down menu reason 2943 for medication failure. Medication failure interface screen 2941 also asks clinician 116 whether the medication schedule for order 2839 should be adjusted. To adjust the medication schedule, clinician 116 selects selection box 2945 on interface screen 2941 . When the clinician 116 clicks on the drop down menu and enters 2943 selecting a medication failure reason, the drop down menu will expand as shown on interface screen 3047 of FIG. Typically, the clinician will select the "not needed" reason 3045 if the medication is no longer needed. If the clinician 116 selects the "not required" reason 3045 for the medication failure, the system 210 removes the medication failure icon 4837 and displays the "not required" icon 4837 as shown in the infusion schedule screen 3135 of FIG. Insert 4857.

When the clinician 116 is ready to administer a medication regimen or order to the patient, the clinician 116 selects the order 3225 within the schedule interface screen 3235, as shown in FIG. ” key 3249 . After the clinician 116 selects the "Get Items" key 3249 in screen 3249 of FIG. 32, system 210 displays medication interface screen 3351 as shown in FIG. In the Medications screen 3351 , the clinician 116 may scan the selected medications from the pharmacy as shown in icon 3353 to scan the “pharmacy” or select the “skip warehouse scan” key 3355 to scan the warehouse. It has the ability to skip scan blocks. Item information is displayed on the clinician's PDA 118 when the clinician 116 scans the item, such as by scanning a bar code on the item. An example of the scan screen 3465 is shown in FIG. For example, when clinician 116 scans a medication, prescription 3467 is displayed on scan screen 3465 . However, if the scanned item does not match the order for the patient, a scan error screen 3569 as shown in FIG. 35 will be displayed on the clinician's PDA 118. FIG. As shown in interface screen 3569 , when a scanning error is detected, the clinician 116 will be provided with the identification of the item to request or locate as shown in screen 3569 . If the barcode cannot be scanned, for example because the barcode label is dirty or damaged, the data requested by the scan can be manually entered.

If the selected drug is within the same therapeutic class as another drug recently administered to the patient, the clinician's digital assistant 118 displays a warning message. Similarly, if the item has already been retrieved by another clinician, digital assistant 118 displays a message indicating such occurrence.

If the order to be picked up is a mix at the point of administration, the individual components will be identified on the digital assistant 118 and picked up by the clinician 116 . After the item is picked, the system 210 will generate a bag ID and prompt the clinician 116 to print the label 124a. At this point, the clinician 116 also mixes the ingredients. After the clinician 116 prints out the label, the label is added to the bag and can be scanned by the digital assistant 118 .

A particular order can be on-call or on hold. These orders are displayed on a patient profile screen, such as interface screen 2835 of FIG. On-call or pending orders are only available for viewing, not for pick-up. These orders are later activated as needed.

Scenarios may also occur where the clinician 116 has an item containing an unused medication item for the patient. Referring to interface screen 3657 of FIG. 36, the clinician 116 has the ability to identify reasons for not administering medication, such as not required due to monitoring results, inability to visit the patient, or refusal of medication. If the patient is not already identified in screen 3657, the clinician 116 can select 3661 the patient by scanning the patient or entering the patient's name. In addition, the clinician 116 may select to return to the drug inventory in the pharmacy by entering with the “discard/return” selection key 3663 . For certain narcotics and controlled drugs, two signatures (i.e., a second authorization, generally in the form of a login and password) are required for both the initial acquisition of the drug and the return of the drug to the warehouse. signature) may be required.

Interface screen 3657 of FIG. 36 also provides the clinician 116 with the ability to scan the patient ID to identify the patient. If the wrong patient is scanned, or the patient ID does not scan properly, the system 210 will display a message that the scan is invalid. Additionally, if the clinician 116 is unable to administer the medication, the clinician will typically have to enter a reason 3659 for not administering the medication, as shown in screen 3657 of FIG. Some reasons for not administering the drug are that the drug is not needed due to monitoring results, the patient is unavailable, or the drug is refused by the patient.

After the clinician 116 has confirmed the patient and item or medication, the Confirm Pathway interface screen 3771 is displayed. As shown in FIG. 37, an example of a path confirmation screen 3771 assists the clinician 116 in confirming path 3773, line 3775 and site 3777. FIG. A medication regimen 3778 may also be provided on the route confirmation screen 3771 . After the clinician has entered path 3773, line 3775, and site 3777, clinician 116 can select compare button 4817 and system 210 will verify that the entered data is correct.

The clinician 116 can then select the pump channel mode as shown in interface screen 3881 of FIG. Pump channel mode interface screen 3881 shows therapy 3882 and clinician 116 has the option to designate therapy 3882 or piggyback therapy 3883 as primary therapy 3884 . Each channel of the pump has the ability to deliver primary therapy in addition to piggyback therapy. After completing the pump channel mode selection, the clinician can perform a pump channel scan. FIG. 38A shows a pump channel scan interface screen 3885. FIG. In the pump scan screen 3885, the clinician 116 scans the medical device, such as by scanning the bar code corresponding to the pump channel 121 and then clicking the arrow key 4809, for example.

Clinician 116 (a) scans a patient, such as on interface screen 2313 of FIG. 23, (b) scans a drug, such as on interface screen 3465 of FIG. 34, and (c) scans interface screen 3885 of FIG. After scanning the pump channels, such as above, the clinician 116 can program the infusion pump and perform a comparison of the programmed infusion pump parameters or settings to the parameters of the pharmacy order.

(Comparison of device settings and orders)
An exemplary flow chart of the comparison process 5200 is provided in FIG. This process can also be applied to program the infusion settings remotely from the server. Referring to FIG. 52, the comparison process 5200 begins at block 5202 after the clinician 116 has completed scanning the patient ID 112a, medication container or bag ID 124a, and pump channel 121 as indicated above. Scanning the patient, medication bag, and pump channel provides an association of relevant baseline data, which allows the system 210, and more specifically the server 109, to further analyze and compare this additional data. can be done. First of all, however, the first central server 109 checks at block 5204 to ensure that the scanned or entered data regarding the patient, medication bag and pump channel results in a valid association. If the three data items do not result in a valid association, the system 210 displays an error message at block 5206 and the clinician 116 at block 5202 rescans the codes for each of the patient ID, bag ID and pump channel ID. Request re-entry. If the three data items resulted in a valid association at block 5204, then server 109 determines whether the identified pump channel 121 exists in server 109's database and for which it utilizes, as described below. will also run the sequence to determine if the

After the pump channel ID is scanned into the system 210, the first central server 109 checks at block 5208 to determine if the selected pump channel 121 is valid. Various reasons for a pump channel invalid determination may be that the pump channel does not exist in the system, the selected pump channel is already running, and the like. If the pump channel 121 check yields an invalid result, an error message is displayed and the clinician is informed that an invalid channel was selected. Until the clinician 116 rescans the pump channels and a valid channel is identified at block 5208, the comparison step 5200 is precluded and the system cannot make the comparison, as indicated at block 5214. However, if the result of the check confirms that the selected channel 121 is a valid channel, the system proceeds to block 5212 and establishes the appropriate link, as described below.

At some point during the comparison step 5200, the second central server 108a generates an XML message containing data related to the patient ID and order ID. As shown in the flow chart for comparison step 5200 , XML data can be generated and transferred to first central server 109 as shown in block 5210 at any point prior to block 5212 . However, if the XML data received by the first central server 109 from the second central server 108a is invalid or incomplete, then the comparison step is skipped and, as indicated at block 5214, the system determines that the comparison step is not allow it to proceed. Conversely, if the XML data associated with the patient ID and order ID are complete and valid, after the first central server 109 receives the XML data from the second central server 108a, the comparison process 5200 continues to block 5212. move on.

At block 5212 , the first central server 109 attempts to establish a link or association between the patient ID, order ID and pump channel 121 . If at block 5212 the first central server 109 cannot establish a link between the identified data, then the comparison step 5200 is excluded and, as indicated at block 5214, the system 210 indicates that the step should proceed. not allowed. Additionally, system 210 displays an error message that some data is missing or inaccurate and the system is unable to make the comparison. If the first central server 109 establishes a suitable link between the identified data at block 5212, the system proceeds to block 5216 where the clinician 116 is requested to press the compare button 4817 on the digital assistant 118. move on. An example of the sequence of screens occurring at block 5216 is described below.

After the appropriate link is established by first central computer 109, system 210 proceeds to one of the comparison interface screens, such as comparison interface screen 3986 of FIG. In this comparison interface screen 3986, the system 210 provides instructions to the clinician 116 to program the infusion pump before making any comparisons. Comparisons can be made to ensure that pharmacy parameters for medication and pump settings are in sync. In a preferred embodiment, system 210 performs a speed comparison in comparison step 5200 shown herein. However, the system is capable of performing single comparisons or simultaneous multiple comparisons of any injection parameter, such as rate, volume, dose, and the like.

If the infusion is a primary infusion, click the "compare" button 4817 on the comparison interface screen 3986 and then be given an instruction to wait for instructions before starting the pump channel. If the infusion is a piggyback infusion, instructions are given to press the start key on the pump 120 and then click the “Compare” button 4817 . For piggyback infusions, if the clinician 116 presses the compare button 4817 at block 5216 before pressing the start key on the pump, an interface screen 4287 typically shown in FIG. 42 is displayed giving the clinician an error indication. will be

First, before making the comparison, system 210 polls server 109 to ensure that the communication link between pump 120, server 109 and digital assistant 118 remains active. If the communication link is active, comparison step 5200 proceeds. If the communication link is lost, the comparison process cannot proceed.

Therefore, after the clinician 116 presses the compare button 4817, the system 210 proceeds to block 5218 shown in FIG. At block 5218, system 210 determines whether channel 121 is ready. For example, if the infusion is identified as a primary infusion but the channel is already running, the system will default to block 5214 and display an error message that the system cannot make the comparison. Additionally, if the infusion is identified as a piggyback infusion and the start key on the pump has not been pressed, the system defaults to interface screen 4287 of FIG. Notify clinician 116 to press.

The comparison process 5200 also checks the pump 120 at block 5220 to determine if the setpoints or operating parameters programmed into the pump 120 contain fresh data. As an example, the system may require that programming of pump data into the pump be completed within a specified time limit (ie, 5 minutes) before requesting a comparison. Such time limits for determining whether data is new data can be set by the medical facility. If the data is not fresh data, the system will return to block 5214 and display an error message that the data is not fresh. System 210 will then request that pump 120 be reprogrammed so that the comparison process can proceed. If the data is determined to be fresh data at block 5220 , system 210 will perform a comparison at block 5222 . The actual data comparison is typically done at the first central server 109 . As mentioned above, the comparison is to determine if the parameters programmed into the pump match the doctor's orders. Additionally or alternatively, the pump settings can be remotely programmed by a remote controller or server.

After performing the comparison at block 5222, the system 210 determines whether there is a match or a mismatch at block 5224 and returns the results to the clinician 116 via the digital assistant.

An example of the comparison interface screen 3987 that accompanies a comparison resulting in a match is shown in FIG. 39A and identified by block 5226 in FIG. In this example, the clinician 116 is instructed to start the infusion pump 120 if the pharmacy prescription parameters and the programmed pump channel settings match.

An example of a comparison interface screen that accompanies a discrepancy between the pharmacy prescription parameters and the programmed pump settings at block 5224 is shown in discrepancy comparison interface screen 4087 of FIG. If this result occurs, the system 210 requests the clinician 116 to either accept the discrepancy identified at block 5228 or reprogram the infusion pump at block 5230 and make another comparison at block 5216. It will be. Normally, the mismatched parameters will be displayed on the mismatch screen 4807 . If the discrepancy is accepted, it is recorded in system database 109 at block 5232 . Additionally, if a discrepancy is accepted at block 5228, the server 108a directs the clinician to the appropriate screen.

FIG. 41 displays an example of a comparison interface screen 4187 where system 210 cannot make a comparison because some of the data is unavailable. Specifically, in the example of FIG. 41, the pump speed set point is not entered into system 210 . Therefore, system 210 cannot make a comparison until additional data such as velocity is input in this example. Typically, if an infusion is already running, if the system fails to receive updated pump information, if there is a system communication error, or if data from either programmed channel information or pharmacy prescription information If there are gaps, system 210 cannot make the comparison. Finally, comparison screen 4287 of FIG. 42 displays another scenario in which system 210 cannot make a comparison until the indicated further steps are taken. Typically, this interface screen 4287 will indicate that the infusion is a piggyback infusion and that the clinician 116 has pressed the start key on the infusion pump 120 before pressing the compare button 4817, as indicated by the instructions in interface screen 3986 of FIG. It is provided when you press the compare button 4817 in the interface screen 3986 of FIG. 39 without pressing it.

After the infusion pump begins therapy, the clinician 116 can view the status of the pump on his or her digital assistant 118 in the pump status interface screen 4391 shown in FIG. The pump status display 4391 displays a list of all current infusions for a given patient. Typically, one of five icons, an infusion in progress indicator 4807, an infusion waiting indicator 4810 , an infusion stopped indicator 4811, an unknown icon, and a delay icon, is displayed in this screen in conjunction with the infusion. become. The pump status display 4391 does not update in real time while the current screen is displayed, but tapping the refresh button 4819 will display the latest real time pump status screen.

As shown in FIG. 44, clinician 116 may view flow rate history interface screen 4493 . The clinician 116 can go directly to the flow history screen 4493 by clicking on the flow history link on the patient menu interface screen 2521 shown in FIG. Flow history shows the history of programmed flow history changes for the current injection on a given channel. Patient information associated with the channel is typically displayed along with the current prescription information for that channel. Additionally, after the clinician 116 logs in on the digital device 118, selects a shift, and selects a patient, the clinician 116 can, without limitation, record infusions performed, stop infusions, or restart infusions. Including logging, logging infusion aborts, viewing pump flow rate history as described above, viewing pump infusion status as described above, responding to pump alarms and pump alerts as described below, viewing messages/notifications and responding to messages/notifications. Various tasks can be performed on the digital device 118 . Specifically, with respect to recording the infusions performed, after the clinician 116 has scanned the item barcode, patient barcode, and pump channel barcode, the clinician programmed as detailed above. Pump settings can be compared to orders entered by the pharmacy. Typically, the clinician 116 would then perform the infusion using the pump 120 and record the infusion using the digital device 118 .

To initiate an infusion, the clinician 116 typically scans the patient's wristband barcode 112a and then scans the infusion bag barcode label 124a. When prompted by digital device 118, clinician 116 enters and compares lines, sites and routes for infusion, as shown in interface screen 3771 of FIG. Next, at screen 3881 of FIG. 38, the clinician 116 selects 3883 primary or piggyback infusion and scans the pump channels. The clinician 116 then programs the pump as directed by the physician's order. When programming the pump 120, the clinician 116 chooses to perform a comparison check between the pharmacy order and the pump, as shown in FIGS. 39-42. If the programmed pump settings match the pharmacy-entered order, an interface screen such as screen 4287 will indicate the match, and the clinician 116 can tap OK button 4805 to accept the match. Finally, the clinician 116 will press the start key on the pump 120 . The digital assistant 118 will then display the administration results recording interface screen 4937 of FIG. 49, and the clinician 116 can enter the appropriate results from the selections in the drop down list. These steps can be repeated for additional patients and/or additional pumps or channels.

Prior to administering the drug, the clinician 116 may be prompted to enter the parameters being monitored, such as heart rate prior to administering digoxin or pain assessment prior to administering morphine. If the parameter being monitored is associated with a drug, each dose of drug displayed on the digital assistant 118 has a link to an interface screen where the clinician 116 can enter the value. An example of such an order with a link 5001 to the input of the parameter being monitored is shown in the order displayed in FIG. After the monitored parameter link 5001 is selected, a monitored parameter input interface screen 5003 as shown in FIG. 50A is displayed. Clinician 116 can then enter the requested information into system 210 .

Additionally, the system 210 may require the clinician 116 to monitor the cycle count, typically when picking up narcotics or controlled drugs from the pharmacy. In one example, when a warehouse drawer is opened to provide a narcotic or controlled drug, the digital assistant 118 may display a cycle count interface screen 5101 as shown in FIG. This interface screen 5101 prompts the clinician to count the units of medication currently in the reservoir or vault and prompts him to enter this data into the fields provided. System 210 then compares this amount to the expected count. If the cycle counts do not match, digital assistant 118 displays a message indicating the mismatch and then displays cycle count screen 5101 again. If the cycle counts do not match again, the system 210 will record the discrepancy and appropriate action can be taken.

If desired, the clinician can stop an ongoing infusion before it is finished. This can be done with or without an abort order to abort the infusion within the system. Aborted infusions can be resumed as needed, for example when titrating an order. When both the aborted infusion icon 4813 and the ongoing infusion icon 4807 are displayed on the digital assistant 118, the clinician 116 can display a list of all ongoing infusions for the patient on the digital assistant 118. be instructed to move. An example of such an infusion abort interface screen 2727a is shown in FIG. 27A . In FIG. 27A , the aborted infusion order will be highlighted and indicated as being an aborted infusion order. The clinician 116 would then scan the bar code on the solution container for the discontinued infusion and then scan the patient's ID. An interface screen 2727b as shown in FIG. 27B is then provided on the clinician's digital assistant 118. FIG. Interface screen 2727b allows the clinician to enter the time the infusion was discontinued and the reason for discontinuing the infusion. The clinician can then physically stop the infusion pump 120 by pressing the stop button on the infusion pump 120 .

A resume infusion interface screen 2727c is provided in FIG. 27C . It is also possible to resume an infusion that has been recorded as aborted without an order to abort it. To resume infusion, clinician 116 must first navigate to the appropriate interface screen on digital assistant 118 . Tapping the abort infusion icon 4811 in the patient menu will display a list of all infusions that are currently aborted for that patient, as shown in interface screen 2727c of FIG. 27C . A prompt is provided to the clinician to select the infusion to resume. The clinician 116 then scans the barcode on the solution container for the infusion to be resumed. The system 210 compares the scanned IDs to those for infusions currently canceled for the patient. After the system 210 compares the ID with those currently suspended for the patient, the digital assistant 118 prompts the clinician 116 to scan the patient's ID. System 210 then verifies that the scanned ID matches the patient's ID, after which system 210 displays the scanned infusion prescription on digital assistant 118, as shown in interface screen 2727d of FIG. 27D . and prompt the clinician 116 to select an institution-defined reason for resuming the infusion. Once a reason is selected, the clinician 116 can resume infusion with the pump 120 and then tap arrow 4809 to continue. System 210 records the infusion as restarted.

Various icons are used to assist the clinician 116 , as shown in various screen shots/interfaces to the digital assistant 118 . Many of these icons are shown in FIG. Patient list button 4801 is a key that, when tapped, allows clinician 116 to go directly to a patient list screen, such as patient list screen 2313 shown in FIG. A return button 4803 is a key for returning the screen on the digital assistant 118 to the previous screen when tapped. OK button 4805 is tapped to approve the data being shown on digital device 118 . Tapping the OK button 4805 usually brings up the next screen. Infusion in progress indicator button 4807 indicates that a programmed infusion for the selected pump 120 and channel is currently being performed. Infusion pending indicator 4810 indicates that the programmed infusion for the selected patient, pump 120 and channel is pending. Aborted infusion indicator 4811 indicates that the programmed infusion for the selected patient, pump 120 and channel has been discontinued. Stop infusion order indicator 4813 indicates that the infusion for the patient, pump 120 and channel selected by the pharmacy-entered order is to be stopped. Physician notes indicator 4815 indicates the presence of physician notes for the selected patient, pump 120 and channel. The clinician 116 can tap the notes indicator 4815 to view the notes. A Compare button 4817 is provided on various screens that, when tapped, causes the system 210 to perform a comparison between the scanned item and the pharmacy-entered order, and additional comparisons. Refresh button 4819 is tapped to update the latest data to show on the screen. Exit button 4821 allows the clinician to exit the current screen and return to the previously displayed screen. The Enter button 4809 is also an OK button, which is tapped to accept and enter data selected from options in a drop-down list or manually entered in a field. Compare match indicator 4823 indicates that the programmed pump settings match the pharmacy-entered order information. Comparison mismatch indicator 4825 indicates that the programmed pump settings do not match the pharmacy-entered order information. Unable to compare indicator 4827 indicates that the system cannot compare programmed pump settings with pharmacy-entered order information. Pump alarm/alert indicator 4872 indicates that an alarm or alert condition has occurred. When alarm/alert indicator 4872 is tapped, an expanded pump alarms/alerts screen is displayed. On the alarm/alert screen, a red alarm/alert icon 4872 indicates an alarm condition and a yellow alarm/alert icon 4872 indicates an alert condition. Alarm/alert silence button 4874 is tapped to temporarily silence audible alerts on digital device 118 . Communication loss indicator 4833 indicates that pump 120 and/or hub 107 is not properly communicating with system 210 . The message that accompanies this indication describes the steps to take to resolve the issue. Wireless module low battery alert indicator 4835 indicates that hub 107 is currently running on a spare battery with less than 30 minutes of battery life remaining.

The above disclosure regarding setup and use of the digital assistant 118 has discussed the clinician 116 performing these functions. However, it is understood that these tasks can be performed by any administrative or staff member of the hospital, whether that individual is a clinician 116 or not.

(Emergency notification process)
Referring to Figure 12, a preferred embodiment of an emergency notification system 1200 is shown. Notifying party 1210 is in communication with communication network 1220 . Those skilled in the art will appreciate that a variety of communication networks are operable including, but not limited to, Ethernet networks, coaxial cable networks, wireless local area networks, and wireless wide area networks. Additionally, various communication network protocols such as, but not limited to, Transfer Control Protocol/Internet Protocol (“TCP/IP”), Wireless Application Protocol (“WAP”), and User Datagram Protocol (“UDP”). Available. Further, communication network 1220 can operate as part of a larger communication network. For example, communication network 1220 can be a wireless communication network that communicates with an existing wired communication network, such as within a hospital.

In communication with communication network 1220 is notifying party 1210 . The notifying party 1210 can be a hospital clinician, such as a nurse, doctor, hospital administrator, or security personnel. The notifying party 1210 can also be a patient. Additionally, the notifying party 1210 can be an automated process, such as a computer program or medical device. An automated process acting as a notifying party 1210 can be programmed to broadcast an emergency notification across the communications network 1220 upon the occurrence of a particular condition or event. For example, an automated process can be programmed to broadcast an emergency notification upon sensing a patient condition.

Emergency notifications are received by one or more target parties 1230 . Target parties 1230 can be clinicians, such as doctors and nurses. The target party 1230 can also be an emergency responder or security personnel, or an environmental disaster response team. Target party 1230 can be any individual in communication with communication network 1220 . Embodiments of the present invention provide the notifying party 1210 with the option of sending the emergency notification to only a specific target party 1230 or multiple target parties 1230 or all target parties 1230 . This embodiment allows the notifying party 1210 to select which target parties 1230 receive the emergency notification.

Target party 1230 and notifying party 1210 are in communication by communication network 1220 . Those skilled in the art will appreciate that the various communication modalities 1240 that can be provided to the notifying party 1210 and the target party 1230 communicate with the communication network 1220 . For example, communication modality 1240 can be a wired connection, such as a personal computer or programmable controller. The communication modality 1240 can also be a wireless network connection enabled through a handheld computer or cell phone.

Referring now to FIG. 13, a notification interface 1300 from the perspective of the notifying party 1210 is shown. Those skilled in the art will recognize the various interfaces that authorize notifying parties 1210 to broadcast emergency notifications over communications network 1220 . The notification interface can be an intranet or an Internet-connected website. The notification interface can also be activated by a cell phone or other phone or email. In one embodiment, notification interface 1300 is a handheld computer of the type commonly found commercially. Examples include PalmOne, Inc. Palm devices manufactured by PalmOne, Inc. Visor device manufactured by Hewlett Packard, Inc. Jornada devices manufactured by Dell, Inc. Axim device manufactured by Sony, Inc. and Clie devices manufactured by Toshiba, Inc. , Compaq and Symbol.

In one embodiment, notification interface 1300 includes menu 1330 listing one or more options 1340 . For example, one notification option 1340 may allow the notifying party 1210 to select a particular clinician or clinician type as the target party 1230 for emergency notifications. Another notification option 1340 may allow the notifying party 1210 to choose to cancel the emergency notification if it was sent in error. Additional notification options 1340 may include inputs for patient identification, patient location, emergency type, and expected response time.

Referring now to FIG. 14, one embodiment of receiving interface 1400 from the perspective of target party 1230 is shown. Like the notification interface 1300, the reception interface 1400 is operable on a variety of different platforms and may continue to be implemented under the principles of the invention. In one embodiment shown in FIG. 13, receiving interface 1400 is a handheld computer. Interface 1400 includes screen 1420 for displaying configurable information 2350 . Information 2350 may include emergency notification information such as patient identification information, location of emergency occurrence, type of emergency, and expected response time.

Both the notification interface 1300 and the reception interface 1400 are optionally configured with hotkeys 1350,1460. With respect to notification interface 1300, hotkey 1350 can be configured to send an emergency notification that includes information automatically obtained from notification interface 1300 itself. For example, pressing hotkey 1350 on notification interface 1300 can be configured to automatically send an emergency notification containing that information.

(Messaging & notifications including alarm/alert notifications)
The system provides the ability to send notifications and messages. Notifications include, but are not limited to, patient status lists, alarms, alerts, infusion schedules, orders, overrides, warnings, therapy parameters, links to additional information, medication failures, route confirmations, comparisons, flow rate information, physician notes, Loss of communication, low battery, dosing results, etc. can be included. The system also provides the ability to display these and additional notifications. One means of displaying notifications is on the digital assistant 118 . Notifications may also be provided to any one of multiple clinicians and/or lead clinicians.

As mentioned above, one type of notification is alarm/alert notification. The system allows incremental increases in notifications. The specific alarm/alert escalation process is shown in FIG. Typically, a notification step is provided for sending notifications to any number of clinicians 116 . The escalate identified alarms/alerts process 1500 of FIG. offer. In a preferred embodiment, the clinician's device is a personal digital assistant (“PDA”) 118, as shown in FIGS. 1 and 3, generally having a display 118a and an audible tone or sound generator 118c. For illustrative purposes only, the clinician's device is identified hereinafter as digital assistant 118 in this detailed description. Additionally, alarm/alert escalation process 1500 provides an escalation process in the event that the clinician fails to respond to the alarm/alert notification on digital assistant 118 . When an escalation process is initiated, a notification is sent to the digital assistant 118 of another or second clinician identified in the escalation process. Although alarm/alert notifications are sent to the digital assistant 118, it is understood that typically pump alarms and alerts can only be resolved at the pump. As described herein, silencing an alarm or alert in the digital assistant 118, as in block 1580 of FIG. 15, may or may not affect the pump.

The alarm/alert escalation process 1500 begins at block 1505 when at least one or both of an alarm condition or an alert condition is triggered in the medical device 120 . In the preferred embodiment shown in FIG. 3, following the triggering of an alarm or alert at medical device 120, a signal containing data relating to the alarm or alert condition is generated and transmitted from medical device 120 to server 109 at block 1510. be. In a wireless environment, a medical device 120 having a wireless transmitter or connected to a wireless hub 107 is provided. In the latter example shown in FIG. 3, hub 107 receives signals from medical device 120 and converts the signals into a form suitable for transmission to system network 102 over wireless channel or link 128. . Additionally, if hub 107 recognizes that an alarm, alert, or other notification is a duplicate notification, hub 107 can discard the duplicate notification. The transmitted signal is received by a wireless access point 114 within the medical environment. Wireless access point 114 provides an interface between a wireless communication path (ie, wireless path 128) and a wired communication path, such as wired communication path 110 shown in FIG.

After the server 109 receives the data related to the alarm or alert condition sent at block 1510 , the server 109 performs prerequisite checks at block 1515 . Prerequisite check 3030 involves associating an alarm or alert condition on medical device 120 with a particular patient and associating that patient with a primary clinician, also referred to as a first clinician (this association may be performed by central system services device 108a). ) and associating the first clinician with that clinician's digital assistant 118 . The server 109 uses the information obtained in its prerequisite checks at block 1515 to determine whether the medical device 120 (and in one embodiment, the particular channel 121 of the infusion pump 120), the patient, the primary or primary clinician. and the first clinician's digital assistant 118. It is understood that there is a many-to-many relationship between patients 112 and clinicians 116 . Thus, multiple primary clinicians, multiple secondary clinicians, and multiple n-level clinicians can be associated with one particular patient. Additionally, n-level escalation is also possible within the system.

Typically, the server 108a stores within it patient-to-clinician many-to-many associations and patient-to-department associations. Server 108a transmits these associations to server 109, which stores these associations. Similarly, server 108a transmits the lead clinician-to-department association to server 109 for storage.

Following the prerequisite check at block 1515 , server 109 determines the appropriate channel 121 mapping from patient 112 to clinician 116 . Once the mapping is complete, at block 1520 the server 109 determines whether the first clinician's digital assistant 118 is active. If the first clinician's digital assistant 118 is active, then the server 109 generates a signal representing an existing alarm or alert condition. The signal includes data such as patient name, patient location, bed identification, room identification, alarm or alert type, condition description, time, date, clinician identification and/or prescription. In a preferred embodiment, this signal is transmitted from server 109 to wireless access point 114 . At block 1525, the wireless access point 114 then transmits a signal associated with the alarm or alert condition to the clinician's digital assistant 118 via wireless communication transmission.

A signal associated with an alarm or alert condition may also be transmitted to the lead clinician, subordinates of the first clinician, or even a second clinician at block 1525 . Such signals can be transmitted via wireless or wired communications. Additionally, the lead clinician may be using a digital assistant 118, desktop computer, or some other electronic device. The lead clinician is generally the clinician's immediate supervisor or someone else. Additionally, the lead clinician may be someone who assists the clinician's workflow or assists in monitoring alarm or alert conditions.

The signal is received by the clinician's digital assistant 118 and subsequently displayed at block 1530 in FIG. This block displays alarm or alert conditions on the clinician's digital assistant 118 . The display on the clinician's digital assistant 118 can be a visual display, an audible display, or both a visual and an audible display. Additionally, the visual representation may include one or more text, icons, symbols, and the like. Similarly, as noted above, the audible indication may include different audible sounds at different decibel levels. Visual and audible indicators are configurable by the hospital. FIG. 16A discloses a screen shot of an exemplary alarm/alert interface list screen 1662a on the clinician's digital assistant 118. FIG. Alarm/alert list interface 1662a contains a list of patients currently associated with alarms/alerts for the active channel. As shown in FIG. 16A , the clinician's digital assistant 118 currently has three active alarm/alert displays. There is an alarm state for patient 1 1664 , an alarm state for patient 2 1666 and an alert state for patient 3 1668 . As shown in Figure 17, each patient name and corresponding alarm/alert icon is hyperlinked to the appropriate pump alarm details interface screen. In one embodiment, the patient list is filtered to include only patients currently associated with the clinician 116 logged into the digital assistant 118 displaying this interface screen. This clinician-to-patient association may be made as the primary clinician or as the interim clinician. A second clinician can also be accessed through the escalation process. The alarm/alert list interface 1662 is generally accessed by clicking the alarm/alert icon 4872 displayed on the digital assistant 118 of the clinician 116 during normal clinician workflow.

As noted above, if an alarm or alert condition is displayed on the clinician's digital assistant 118 at block 1530, this indication may be provided visually, audibly, or both. If an audible indication is provided to the clinician's digital assistant 118, an alarm icon 4872 appears on the clinician's digital assistant's 118 display 118a. If an audible indication is provided, the clinician may have the ability for the clinician to mute the audible indication even if the clinician is not responding to an alarm or alert condition. If the clinician silences the alarm, the server 109 will start a silence timer. The visual indication will remain even if the audible indication is muted. As shown in FIG. 16A , if the alarm/alert is providing an audible indication to the clinician's digital assistant 118, but the clinician has muted the sound, an alarm/alert muted icon 4874 is provided. be. Further, upon escalating alarm/alert conditions, the muting of the audible indication can be deactivated if the clinician does not respond to the alarm within the time limit of the timer. An alternative embodiment of an audible indication could be a vibrating alert.

Further, it is understood that multiple alarm/alert condition times may occur simultaneously or overlap. In response, simultaneous or overlapping signals containing data associated with the particular alarm or alert condition are generated and transmitted from the medical device 120 to the server 109 at block 1510 . Alarm/alert signals can originate from the same medical device 120 or different medical devices 120 . Further, the alarm/alert signals can relate to the same patient or different patients. However, each alarm/alert signal is routed individually to the alarm/alert escalation process 1500 described herein for each individual alarm/alert condition. A particular clinician may have numerous alarm/alert displays on his/her digital assistant 118, as shown in FIG. 16A . Another example of an alarm/alert screen is shown on interface screen 1662b of FIG. 16B . As is common in the present system, the line referenced as 1676 in interface screen 1662b of FIG. 16B marks the end of the list, specifically the alarm/alert display list for a particular clinician within this interface. indicate.

FIG. 17 shows a detailed view after selecting to view one of the alarm/alert displays for a hyperlink to a patient on the clinician's digital assistant 118 from list 1662a in the interface of FIG. 16A . A patient alarm/alert interface 1765 is shown. Here, the clinician has selected an alarm display for Patient 1, 1664. Alarm/alert details screen 1765 provides a message to the clinician detailing the reason for the alarm/alert. The clinician can click refresh button 4819 to update the current information displayed on screen 1765 . There may be multiple alarms or alerts 1878, 1882 for the same patient, as shown on the interface 1867 of FIG. This alarm/alert interface 1867 provides a list of all active pump alarms/alerts currently associated with a given patient. These active pump alarms/alerts may be from multiple channels 121 and/or pumps 120 and may even be spread across multiple hubs 107 . This interface screen 1867 is accessed by identifying a given patient on the pump alarm list screen 1662.

After a signal is sent to the clinician's digital assistant at block 1525 and received by the primary clinician's digital assistant 118 at block 1530 , a timer is started at block 1535 at server 109 . This timer has a time limit. A typical escalation time limit is about 2 minutes, but this time limit is configurable by the hospital. At block 1540, the system determines whether the alert or alarm has been responded to within the time limit of the timer. If the timer time limit is reached without an acknowledgment from the primary clinician's digital assistant 118 , the process proceeds to block 1545 . At block 1545 , the system further inquires as to whether the alarm/alert condition has been acknowledged or responded to at the medical device 120 . If there is no response at the primary clinician's digital assistant 118, or at the medical device 120, or by the primary clinician, then at block 1545 the alarm/alert process is escalated.

Whenever a loss of communication occurs after an alarm/alert condition is triggered but before confirmation of the alarm/alert condition, the alarm/alert condition will recover once the loss of communication is repaired. . Similarly, if an alarm/alert condition is triggered after a loss of communication, the alarm/alert condition will recover once communication is restored.

Once the alarm is escalated, server 109 performs another precondition check at block 1550 . This prerequisite check 1550 includes the steps of associating the patient with the second clinician (this association can be performed at the central system services device 108a) and connecting the second clinician to the second clinician's device or the second clinician. 2, associating with the clinician's digital assistant 118, also referred to as the clinician's digital assistant 118. The server 109 uses the information obtained in its prerequisite checks at block 1550 to establish a relationship between the medical device 120 , the patient, the second clinician, and the second clinician's digital assistant 118 .

Following the second prerequisite check at block 1550 , the server 109 may also determine whether the second clinician's digital assistant 118 is active. If the second clinician's digital assistant 118 is active, then the server 109 generates an escalated signal representing an existing alarm or alert condition. This escalated signal also includes data such as patient name, patient location, room identification, bed identification, alarm or alert type, condition description, time, date, clinician identification and/or prescription. In a preferred embodiment, the escalated signal is transmitted from server 109 to wireless access point 114 . The wireless access point 114 then transmits the escalated signal associated with the alarm or alert condition to the second clinician's digital assistant 118 via wireless communication transmission at block 1555 .

Escalated signals associated with alarm or alert conditions may also be transmitted to the primary clinician at block 1555 . Such escalated signals can be via wireless or wired communications. Additionally, the lead clinician may be using a digital assistant, desktop computer, or some other electronic device. As noted above, the lead clinician is typically the clinician's direct supervisor or a specific person or person who assists the clinician in workflow or in monitoring alarm or alert conditions.

The escalated signal is received by the second clinician's digital assistant 118 and subsequently displayed at block 1560 of FIG. This block displays an alarm or alert condition on the second clinician's digital assistant 118 . The display on the second clinician's device can be a visual display, an audible display, or both a visual and an audible display. Additionally, the visual representation may include one or more text, icons, symbols, and the like. Similarly, as noted above, the audible indication can include various audible sounds. However, it is understood that the original signal sent to the first clinician (see block 1525) is still retained in the first clinician's digital assistant, as shown in block 1530 of FIG. . The signal in the first clinician's digital assistant 118 can be intensified (ie, it can be shown in a larger size or font, it can blink, increase the volume of the audible alert, etc.).

After the secondary signal is sent to the clinician's digital assistant at block 1555 and received by the second clinician's digital assistant 118 at block 1560, at least two individuals (the first clinician and/or the chief Clinician) and at least two devices with alarm/alert status active. Accordingly, any of these clinicians can respond to the alarm/alert condition, as shown in blocks 1540 and 1565 . At block 1570 , the escalated alarm process continues until the alarm/alert condition is cleared on any one of the clinician's digital assistant 118 , the lead clinician's computer or device, or the medical device 120 . Become.

Referring to block 1520, if the server 109 determines that the primary clinician's digital assistant 118 is not active, and if the server 109 determines at block 1545 that the alarm/alert condition still exists, the server 109 performs the actions discussed above. Proceeding to block 1550, an appropriate secondary clinician or primary clinician to send the alarm/alert signal will be determined. Additionally, it is understood that block 1520 can occur at any time during the alarm/alert escalation process 1500 . One reason the clinician's digital assistant 118 is not active can be loss of signal from the server 109 . As shown in communication loss interface screen 4501 of FIGS. 45A and 45B , if the signal is lost, digital assistant 118 provides clinician 116 with screen 4501 indicating signal loss and/or an audible/vibrating indication. . The Lost Communication screen 4501 also notifies the clinician 116 as to which patient's signal was lost. At screen 4501, the system 210 also provides the clinician 116 with troubleshooting information for regaining the signal. Pump alarms and alerts cannot be received by the digital assistant 118 when the hub 107 or digital assistant 118 is out of radio range.

Other reasons the digital assistant 118 is not active may be low battery power in the digital assistant 118, low battery power in the wireless hub 107, or loss of digital assistant signal due to the access point 114. . System 210 provides a low battery screen to clinician 116 . As shown in interface screen 4603 of FIG. 46, one type of low battery screen is a screen that alerts the clinician that a low battery condition exists in the wireless hub 107 connected to the patient's infusion pump. When the low battery screen is provided, it contains a list of patients whose infusions are associated with that particular hub 107 . The patient list will typically include only patients currently associated with the clinician logged into the digital assistant 118 displaying screen 4603, as well as all patients who share the same infusion pump 120/hub 107 with the logged-in clinician. Filtered to include. This clinician-to-patient association may be the primary or secondary clinician through the escalation process. It is understood that there may be other reasons why the clinician's digital assistant 118 is not active. Nevertheless, whenever the clinician's digital assistant 118 becomes inactive, the process 1500 can proceed to block 1550 so that a signal can be sent to the second clinician and/or the lead clinician. can. Additionally, as discussed above with respect to the timeout and other features of the present disclosure, if the communication signal from server 109 or medical device 120 is lost, a signal loss will occur on digital assistant 118, as shown in FIGS. 45A and 45B . message can be provided.

At any time during the alarm/alert process, the primary clinician can respond to the alarm/alert signal. If the primary clinician responds to the alarm/alert signal at block 1540, the escalated process will be bypassed. However, if an escalated process was initiated at block 1550, at block 1565 the attending physician or second clinician may respond to the alarm/alert signal. Similarly, the alarm/alert condition can be cleared at any time, either at the medical device 120 or by the lead clinician, prior to or during the alarm/alert escalation process. After the alarm/alert condition is cleared on the medical device 120 or by the lead clinician at block 1540 or block 1565, at block 1540 the audible alarms on the medical device 120 and the clinician's digital assistant 118 are terminated. Become.

At block 1585, server 109 records all alarm/alert conditions as events. Recording the event includes recording information about the alarm/alert condition, recording the responding clinician of the alarm/alert condition, and recording the start time of the alarm/alert condition (see block 1505). and recording the time the alarm/alert condition was corrected. Additionally, at block 1590, the server 109 will reset the timer and update the medical device alarm list. Alarm/alert conditions can also be recorded in the pump's event history.

(exemplary use case)
55A-62 are flowcharts of exemplary operations that may be performed using the systems described herein. Exemplary operations include taking a new infusion, scanning pump channels, changing the channel to which a pump is assigned, stopping/aborting an infusion, restarting an infusion, and removing a pump. In general, each of these operations includes information indicating the operation to be performed, information identifying which patient 112 is to be affected (e.g. patient ID), and which medication 124 for that patient 112. receives an input from an electronic device, such as digital assistant 118, that includes information (eg, RxID) identifying which is to be affected. This information is then sent to the first central server 109, which verifies that the channel identification information matches the infusion order information and verifies that the correct infusion operation was performed. .

(Injection process)
An example of an implant performing process 5500 is shown in FIG. 55A. Part of the injection performing process 5500 is an alternative embodiment of the comparison procedure 5200 outlined above. Perform infusion process 5500 can be used to initiate a new infusion. In general, the administering infusion process 5500 includes information indicating that the administering infusion process is to be performed, information identifying which patient 112 is to be affected (e.g., patient ID), and which drug 124 for that patient 112 . receives input from an electronic device, such as digital assistant 118, that includes information (eg, RxID) identifying which is to be initiated for infusion. Step 5500 then sends this information to the first central server 109, which confirms that the channel identification information matches the infusion order information and confirms that the correct infusion has been initiated. to confirm.

More specifically, this exemplary infusion administration process 5500 begins at block 5502 when second central server 108a causes digital assistant 118 to display a list of patients. An example of a digital assistant display 118a showing a list of patients is shown in FIG. The list of patients is preferably limited to patients 112 associated with the user (eg, clinician 116) logged into that digital assistant 118 at that time. Once the user selects a patient 112, information identifying the selection and/or the patient 112 is returned from the digital assistant 118 to the second central server 108a. Communication between the digital assistant 118 and the second central server 108a may be via any suitable communication channel, such as the wireless/wired network 102 described above. Then, at block 5504, the second central server 108a causes the digital assistant 118 to display the list of actions. An example of a digital assistant display 118a showing a list of actions is shown in FIG. The list of actions is preferably limited to actions associated with the selected patient 112 . For example, the “make an infusion” action would only be available if at least one infusion is currently associated with the selected patient 112 .

When the user selects the "make an injection" action from the action list, information identifying the selected action is sent to the second central server 108a. In response, at block 5506, the second central server 108a displays a screen on the digital assistant 118 prompting the user to select the drug 124 to be injected from the list of drugs displayed on the digital assistant 118. Let An example of a digital assistant display 118a showing a list of medications is shown in FIG. A list of medications is preferably retrieved from the database of the second central server 108a based on the actual order for this patient 112 . Of course, this list can have any number of items, including no injection practices or one injection practice. Data indicative of the selected medication 124 is then sent to the second central server 108a.

Next, at block 5508 , the second central server 108 a causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the patient 112 . An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with patient 112 is shown in FIG. The user can scan the barcode label on the patient's wristband 112a using the digital assistant's 118 scanner. Alternatively, the user can manually enter the patient identifier into digital assistant 118 . At block 5510, the patient identifier is then sent to the second central server 108a for verification. A second central server 108a then attempts to look up the patient identifier in its database. If the patient identifier (eg, wristband ID) does not exist as a valid patient identifier in the database, at block 5512 the second central server 108a causes the digital assistant 118 to display a patient invalid notification. Once the user acknowledges the invalid patient notification (or the notification times out), at block 5508 the digital assistant 118 redisplays the screen prompting the user to scan the machine-readable identifier associated with the patient 112.

At block 5510, if the patient identifier (eg, wristband ID) exists as a valid patient identifier in the database, at block 5514, the second central server 108a retrieves the machine-readable identifier associated with the medication 124 to be administered. Cause the digital assistant 118 to display a screen prompting the user to scan. An example of a digital assistant display 118a that prompts a user to scan a machine-readable identifier associated with medication 124 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the medication label 124a on the bag of medication 124 (eg, the barcode on the infusion bag). Alternatively, the user can manually enter the medication identifier into digital assistant 118 . Then, at block 5516, the medication identifier is sent to the second central server 108a for verification. The second central server 108a attempts to look up the drug identifier in its database. If the medication identifier (eg bag ID) does not exist as a valid medication identifier in the database, then at block 5518 the second central server 108a causes the digital assistant 118 to display an item invalidation notification. Once the user acknowledges the item invalidation notification (or the notification times out), at block 5514 digital assistant 118 redisplays a screen prompting the user to scan the machine-readable identifier associated with medication 124 and resume. indicate.

Once a valid drug identifier is obtained, the second central server 108a uses the drug identifier to look up the patient identifier in the database. The patient identifier from the database is then compared to the scanned (or manually entered) patient identifier at block 5520 and the scanned (or manually entered) medication 124 is scanned (or manually entered). ) is of patient 112 . If the two patient identifiers do not match, at block 5518 the second central server 108a causes the digital assistant 118 to display an item invalid notification.

If the two patient identifiers match (i.e., this patient 112 matches this medication 124), then at block 5522, the second central server 108a displays a screen prompting the user to enter a route, line, and site. Display it on the digital assistant 118 . An example of a digital assistant display 118a prompting the user to enter a path, line, and site is shown in FIG. Then, at block 5524, data indicating paths, lines and sites are sent to the second central server 108a for verification. When a route discrepancy occurs, at block 5526 the second central server 108a causes the digital assistant 118 to display a route discrepancy notification. An example of a digital assistant display 118a with a discrepancy notification is shown in FIG. Once the user acknowledges the path mismatch notification (or the notification times out), at block 5522 digital assistant 118 redisplays the screen prompting the user to enter a path, line, and site. If no path mismatch occurs, at block 5528 the second central server 108a causes the digital assistant 118 to display a screen asking the user to select between manual prescription comparison and automatic prescription comparison. If manual prescription comparison is selected at block 5530, at block 5532 the second central server 108a causes the digital assistant 118 to display an indication of the parameters to be manually verified by the user.

Subsequently, at block 5534, the second central server 108a determines whether there are more items (eg, medication) to administer to this patient 112. FIG. For example, the injection order selected at block 5506 may require a primary injection and a piggyback injection. If there are more items (eg, medication) to administer to this patient 112, then at block 5514, the second central server 108a prompts the user to scan a machine-readable identifier associated with the medication 124 to administer. The prompting screen is displayed on the digital assistant 118 . An example of a digital assistant display 118a that prompts a user to scan a machine-readable identifier associated with medication 124 is shown in FIG. If there are no more items (eg, medications) to be administered for this patient 112, then at block 5536 the second central server 108a causes the digital assistant 118 to display a screen showing the results of the administration. FIG. 57 shows an example of the digital assistant display 118a showing the implementation results.

The implementation results are also passed to the first central server 109 . For example, performance results can be passed to the first central server 109 as form variables (as if submitted from a web page). Then, at block 5538, the first central server 109 checks all of the implementation results for any errors. If there are no failures, at block 5540 the first central server 109 commits all new channel-patient-drug relationships to the first central server 109 database. Then, at block 5542, the first central server 109 reverts to control of the second central server 108a by navigating to the predetermined URL associated with the second central server 108a. If there are one or more failures, then at block 5544 the first central server 109 discards the channel-patient-drug relationship associated with the error and replaces the channel-patient-drug relationship associated with the success with Commit to the first central server 109 database. Failures can be associated with the second central server 108 a and/or the first central server 109 . Accordingly, when the first central server 109 returns to control of the second central server 108a at block 5546, the first central server 109 navigates to the predetermined URL associated with the second central server 108a. Additionally, failures (eg, integrity failures) associated with the first central server 109 are preferably sent back to the second central server 108a.

Returning to block 5530, if automatic prescription comparison is selected, at block 5531 the second central server 108a sends a "prescription comparison" XML document to the first central server 109; A "prescription comparison" XML document includes a patient identifier (eg, wristband ID), a medication identifier (eg, bag ID), a completion URL, and a cancellation URL. The URL for Completion is the network address that will be used if a prescription match is found. The revocation URL is the network address used if no prescription match is found.

Once the first central server 109 receives the "prescription comparison" XML document, at block 5548 the first central server 109 determines whether the "prescription comparison" XML document is valid. judge. For example, the first central server 109 can check whether data normally expected in a "prescription comparison" XML document is missing from the received "prescription comparison" XML document. If the first central server 109 determines that the "prescription comparison" XML document is not valid, at block 5550 the first central server 109 notifies the user that the "prescription comparison" operation could not be performed. causes the digital assistant 118 to display an error message shown in . This indication can include reasons such as what data is missing from the "prescription comparison" XML document. After the user presses the "OK" button to acknowledge the error message, at block 5552, the first central server 109 returns a revocation code to the second central server 108a via the revocation URL.

If the first central server 109 determines that the “prescription comparison” XML document is valid, the first central server 109 initiates a channel scanning step 5554 . Typically, a channel scan step 5554 scans for machine-readable identifiers associated with "new" pump channels (eg, pump channel 103a) and determines whether the scanned channel is available (eg, assigned to any patient 112). assigned to the current patient 112 but unused, assigned to another patient 112 and overridden, etc.). If the scanned channel is not available, the "do injection" operation is cancelled. In such a case, the first central server 109 sends a revocation code back to the second central server 108a via the revocation URL. If the scanned channel is available, a new channel-patient-drug relationship is created. The channel scan process 5554 is described in more detail below with reference to FIG.

If the channel scanning step 5554 determines that the scanned channel is valid and available, then at block 5556 the first central server 109 displays a screen prompting the user to program the pump channel. 118 to display. Digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5560 the first central server 109 determines whether communication with the pump channel is working properly. For example, if status information has not been received from the channel within a predetermined amount of time, the first central server 109 can determine that communication with the pump channel is not functioning properly.

If communication with the pump channel is not functioning properly, at block 5562 the first central server 109 displays a screen to the digital assistant 118 indicating that a prescription comparison cannot be performed due to loss of communication with the pump channel. display. Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5560 the first central server 109 rechecks whether communication with the pump channel is working properly.

If communication with the pump channel is functioning properly, at block 5564 the first central server 109 determines if any data associated with this channel is missing. For example, if the status information received from a channel is missing an expected sequence number, the first central server 109 may determine that the data associated with this channel is missing. If channel data is missing, at block 5564 the first central server 109 causes the digital assistant 118 to display a screen indicating that the prescription comparison cannot be performed due to missing channel data. Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5560 the first central server 109 rechecks whether communication with the pump channel is working properly.

If no channel data is missing, at block 5568 the first central server 109 determines if the channel is already in service. For example, the first central server 109 can determine whether the pump channel is operational by reading status information received from the channel. If the channel is already active, at block 5570 the first central server 109 causes the digital assistant 118 to display a screen indicating that the prescription comparison cannot be performed because the channel is already active. An example of a digital assistant display 118a indicating that a prescription comparison cannot be performed is shown in FIG. Digital assistant display 118a may also indicate that the user must press a particular key on pump 120 (eg, start). Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5572 the first central server 109 rechecks whether communication with the pump channel is working properly.

If communication with the pump channel is not functioning properly, at block 5574 the first central server 109 displays a screen to the digital assistant 118 indicating that a prescription comparison cannot be performed due to loss of communication with the pump channel. display. Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5574 the first central server 109 rechecks whether communication with the pump channel is working properly. If communication with the pump channel is functioning properly, at block 5576 the first central server 109 performs the requested prescription comparison.

Returning to block 5568, if the channel is not running, at block 5578 the first central server 109 determines if the pump channel is configured to transmit speed information. If the pump channel is not set to send speed information, then at block 5580 the first central server 109 displays a screen indicating that the channel is not sending speed information and prescription comparisons cannot be performed. is displayed on the digital assistant 118 . An example of a digital assistant display 118a indicating that a prescription comparison cannot be made is shown in FIG. The digital assistant display 118a may also indicate that the user should press a particular key on the pump 120 (eg, speed). Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5572 the first central server 109 rechecks whether communication with the pump channel is working properly. If the pump channel is set to transmit rate information, at block 5576 the first central server 109 performs the requested prescription comparison.

As part of the prescription comparison, the first central server 109 uses the channel identifier obtained by the channel scan step 5554 and the patient identifier transmitted by the second central server 108a to match one drug identifier ( or two drug identifiers if both the primary drug 124 and the piggyback drug 124 are associated with this channel). One or more drug identifiers from the database are then compared to the scanned (or manually entered) drug identifiers at block 5582 . If one or more drug identifiers from the database do not match the scanned (or manually entered) drug identifier, then at block 5584 the first central server 109 causes the digital assistant 118 to display a drug invalid notification. . For example, the digital assistant 118 displays a message that the scanned medication 124 is not associated with the scanned channel, and the actual medication 124 (primary and piggy, if applicable) assigned to the scanned channel. Both back) can be shown. Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5572 the first central server 109 rechecks whether communication with the pump channel is working properly.

As an additional part of the prescription comparison, the first central server 109 uses the channel identifier obtained by the channel scan step 5554 and the patient identifier transmitted by the second central server 108a to look up the medication rate in its database. . The dose rate from the database is then compared to the actual rate received from the pump channel at block 5584 . If the medication rate from the database does not match the actual rate received from the pump channel, at block 5586 the first central server 109 causes the digital assistant 118 to display a rate mismatch notification. An example of a digital assistant display 118a with a discrepancy notification is shown in FIG. For example, the digital assistant 118 can display a message indicating that the speed of the channel should be adjusted and indicate the correct value. Again, digital assistant display 118a preferably includes a "compare" button and a "cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the new channel-patient-drug relationship at block 5558 and passes the revocation code to the second Return to central server 108a. If the user presses the "compare" button, at block 5572 the first central server 109 rechecks whether communication with the pump channel is working properly.

Additionally, the digital assistant display 118a may include an "accept discrepancy" button. If the user presses the "accept discrepancy" button, then at block 5588 the first central server 109 returns the discrepancy code and unmatched speed to the second central server 108a via the completion URL. If at block 5584 the medication rate from the database matches the actual rate received from the pump channel, at block 5590 the first central server 109 causes the digital assistant 118 to display a match notification. An example of a digital assistant display 118a with match notifications is shown in FIG. Once the user receives the match notification message, at block 5588 the first central server 109 returns the match code and matching speed to the second central server 108a via the completion URL.

(Channel scanning process (for implantation process))
FIG. 56 shows an example of the channel scanning process 5554 used above with reference to FIG. Typically, a channel scan step 5554 scans for machine-readable identifiers associated with pump channels and determines whether the scanned channels are available (eg, assigned to the current patient 112 but not in use). Prompt the user to make a decision. If no scanned channels are available, the "do injection" operation is cancelled. In such case, the first central server 109 returns a revocation code to the second central server 108a via the revocation URL. If the scanned channel is available, a new channel-patient-drug relationship is created.

More specifically, the exemplary scan channel process 5554 first displays a screen prompting the user to select a sub-channel (eg, primary or piggyback) at block 5602 and scan for a machine-readable identifier associated with the channel. central server 109 causes the digital assistant 118 to display. An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with a channel is shown in FIG. For example, the user can use the digital assistant's 118 scanner to scan a barcode label associated with the channel. Alternatively, the user can manually enter the channel identifier into digital assistant 118 . Additionally, the user may choose to skip the scanning step that results in a return to the second central server 108a via a completion URL, and a return to the second central server 108a via a revocation URL. You may choose to cancel the scan that caused the .

The channel identifier is then sent to the first central server 109 for verification at block 5604 . The first central server 109 then attempts to look up the channel identifier in its database. If the channel identifier does not exist as a valid channel identifier in the database (e.g., not properly formatted, not configured in first central server 109, etc.), then at block 5606 first central server 109 , cause the digital assistant 118 to display a channel disabled notification. For example, the digital assistant 118 can display a message that the channel is not set up in the first central server 109 and a button that allows the user to rescan the channel identifier or cancel the operation. can include If the user chooses to cancel the operation, at block 5608 the first central server 109 preferably sends a cancellation code to the second central server 108a via the cancellation URL.

Once a valid channel identifier is obtained, the first central server 109 uses the channel identifier to look up patient identifiers in the database. Then, at block 5610, the first central server 109 compares the patient identifier from the database with the scanned (or manually entered) patient identifier. If there is a valid patient identifier in the database but the two patient identifiers do not match (i.e. the channels are assigned to different patients 112), at block 5612 the first central server 109 checks the database. to see if the channel is active (in primary and/or piggyback mode).

If the channel is active, at block 5614 the first central server 109 displays a "not overridable" message indicating that a different patient 112 was associated with the channel that was scanned and the channel is currently active. Causes the digital assistant 118 to display an error message. The message may also include data indicating the patient 112 (eg, patient name), primary medication 124, and/or piggyback medication 124 associated with the scanned channel. The user is preferably given the option to cancel or rescan. If the user chooses to cancel the operation, at block 5608 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5602 the first central server 109 selects a sub-channel (e.g., primary or piggyback) and scans for a machine-readable identifier associated with that channel. The screen prompting the user is displayed on the digital assistant 118 .

If the channel is not active, at block 5616 the first central server 109 issues an "override continue" alert indicating that a different patient 112 was associated with the channel scanned, but the channel is currently not active. Cause the message to be displayed on the digital assistant 118 . This warning message preferably indicates that continuing will overwrite existing data (eg, disassociate other patients 112). The alert message may also include data indicating the patient 112 (eg, patient name), primary medication 124 and/or piggyback medication 124 associated with the scanned channel. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, at block 5608 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5602 the first central server 109 selects a sub-channel (e.g., primary or piggyback) and scans for a machine-readable identifier associated with that channel. A screen prompting the user is displayed on the digital assistant 118 . An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with a channel is shown in FIG. If the user chooses to continue, at block 5618 the first central server 109 creates a new channel-patient-pharmaceutical relationship and updates the new channel-patient-pharmaceutical relationship to the latest "web session ”. If this new channel-patient-pharmaceutical relationship is ultimately retained, as detailed above, at block 5540 of FIG. to the first central server 109 database.

If there is a valid patient identifier in the database and if at block 5620 the two patient identifiers match (i.e. the channel is assigned to this patient 112), the first central server 109 at block 5622 , checks the database to see if the subchannel is free. In other words, the first central server 109 checks that there is no primary infusion associated with this channel if the primary sub-channel is selected at block 5602, and the piggyback sub-channel is selected at block 5602. Checks that there are no piggyback injections associated with this channel, if any. If the sub-channel is free, at block 5618 the first central server 109 creates a new channel-patient-drug relationship and places the new channel-patient-drug relationship in the current "web session". store in If the sub-channel is not free, at block 5624 the first central server 109 checks the database to see if the sub-channel is in service (in primary and/or piggyback mode).

If this sub-channel is active, then at block 5626 the first central server 109 indicates that this patient 112 is already associated with a scan channel and that the selected sub-channel is currently active. Causes digital assistant 118 to display an overwrite not possible" error message. The error message may also include data indicating the patient 112 (eg, the patient's name), primary medication 124 and/or piggyback medication 124 . The user is preferably given the option to cancel or rescan. If the user chooses to cancel the operation, at block 5608 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5602 the first central server 109 selects a sub-channel (e.g., primary or piggyback) and scans for a machine-readable identifier associated with that channel. A screen prompting the user is displayed on the digital assistant 118 .

If the sub-channel is not active, at block 5628 the first central server 109 indicates that the selected sub-channel is currently not active but associated with the channel on which this patient 112 was scanned. Causes the digital assistant 118 to display a Continue message. The error message may also include data indicating the patient 112 (eg, the patient's name), the primary medication 124, and/or the piggyback medication 124. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, at block 5608 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5602 the first central server 109 selects a sub-channel (e.g., primary or piggyback) and scans for a machine-readable identifier associated with that channel. The screen prompting the user is displayed on the digital assistant 118 . If the user chooses to continue, at block 5618 the first central server 109 creates a new channel-patient-pharmaceutical relationship and updates the new channel-patient-pharmaceutical relationship to the current "web session". Store in When the user presses continue again, the first central server 109 returns control to the most recent action (eg, making an injection).

(Pump channel change process)
An example of a pump channel change process 5700 is shown in FIG. 57A. A change pump channel process 5700 can be used to change infusion from one pump channel to another without losing the channel-patient-drug relationship in the database (eg, by a nurse). Generally, the change pump channel process 5700 includes information indicating that the change pump channel process is to be performed, information identifying which patient 112 is to be affected (e.g., patient ID), and that patient 112 An input is received from an electronic device, such as digital assistant 118, that includes information (eg, RxID) identifying which drug 124 for the patient is to be affected. This information is then sent by step 5700 to the first central server 109, which verifies that the channel identifier information matches the pump channel change order information.

More specifically, the exemplary pump channel change process 5700 begins at block 5702 when the second central server 108a causes the digital assistant 118 to display a list of patients for selection. An example of a digital assistant display 118a showing a list of patients is shown in FIG. The list of patients is preferably limited to those patients associated with the user (eg, clinician 116) logged into that digital assistant 118 at that time. Once the user selects a patient 112, information identifying the selection and/or the patient 112 is returned from the digital assistant 118 to the second central server 108a. Communication between digital assistant 118 and second central server 108a may be via any suitable communication channel, such as wireless/wired network 102 described above. Then, at block 5704, the second central server 108a causes the digital assistant 118 to display the list of actions. An example of a digital assistant display 118a showing a list of actions is shown in FIG. The list of actions is preferably limited to actions associated with the selected patient 112 . For example, a "change pump channel" operation could only be performed if the infusion associated with this patient 112 is currently listed in the database of the second central server 108a.

When the user selects the "change pump channel" action from the action list, information identifying the selected action is sent to the second central server 108a. In response, at block 5706, the second central server 108a displays a screen prompting the user to scan a machine-readable identifier associated with the medication 124 affected by this "change pump channel" action. 118 to display. An example of a digital assistant display 118a that prompts a user to scan a machine-readable identifier associated with medication 124 is shown in FIG. The user can use the scanning digital assistant 118 to scan the drug label 124a on the bag of drugs 124 (eg, the bar code on the infusion bag). Alternatively, the user can manually enter the medication identifier into digital assistant 118 .

Then, at block 5708, the medication identifier is sent to the second central server 108a for verification. The second central server 108a attempts to look up the drug identifier in its database. If the medication identifier (eg bag ID) does not exist as a valid medication identifier in the database, then at block 5710 the second central server 108a causes the digital assistant 118 to display an item invalidation notification. Once the user acknowledges the item invalidation notification (or the notification times out), at block 5706 the digital assistant 118 retrieves the machine-readable identifier associated with the medication 124 affected by this "change pump channel" action. Redisplay the screen prompting the user to scan.

At block 5708, if the drug identifier (eg bag ID) exists as a valid drug identifier in the database, the second central server 108a transmits the "change pump channel" XML document to the first central server 109. . The "change pump channel" XML document includes a patient identifier (eg, selected from the list in block 5702), medication identifier (eg, bag ID), URL for completion, and URL for cancellation. The completion URL is the network address that will be used when the "change pump channel" operation is attempted. The revocation URL is the network address used if the "change pump channel" operation fails.

Once the first central server 109 receives the "change pump channel" XML document, at block 5724 the first central server 109 determines whether the "change pump channel" XML document is valid. For example, the first central server 109 can check whether any data normally expected in a "pump channel change" XML document is missing from the received "pump channel change" XML document. If the first central server 109 determines that the "change pump channel" XML document is not valid, at block 5726 the first central server 109 indicates that the "change pump channel" operation could not be performed. Cause the digital assistant 118 to display an error message to the user. This indication can include reasons such as what data was missing from the "pump channel change" XML document. After the user presses the "OK" button to acknowledge this error message, at block 5728 the first central server 109 returns a failure code to the second central server 108a via the cancel URL.

If the first central server 109 determines that the “modify pump channel” XML document is valid, the first central server 109 initiates a channel scanning step 5730 . This channel scanning step 5730 is associated with the "old" channel (ie, the user is moving from the "old" channel to the "new" channel). Typically, a channel scan step 5730 prompts the user to scan the machine-readable identifiers associated with the "old" pump channels and determines whether the scanned channels are associated with patient identifiers and medication identifiers (FIG. 58). as described in more detail below with reference to ). If the scanned channel is not associated with a patient identifier and patient identifier, the "change pump channel" action is cancelled. In such a case, at block 5728, the first central server 109 transmits a revocation code back to the second central server 108a via the revocation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the old channel is valid), then at block 5732 the first central server 109 retrieves the patient 112, the old channel of the primary infusion, and the piggyback infusion. cause the digital assistant 118 to display a message indicating the old channel of Digital assistant 118 preferably also displays a message indicating that both infusions (primary and piggyback) are being moved by this operation, along with the "Continue" and "Cancel" buttons. If the user presses the "Cancel" button, then at block 5728 the first central server 109 sends a revocation code back to the second central server 108a via the revocation URL.

If the user presses the “continue” button, the first central server 109 initiates another channel scanning process 5734 . This channel scan step 5734 is associated with the "new" channel (ie, the user is moving from the "old" channel to the "new" channel). Typically, the scan channel step 5734 prompts the user to scan a machine-readable identifier associated with a "new" pump channel to see if the scanned channel is available (e.g., assigned to any patient 112). assigned to the current patient 112 but unused, assigned to another patient 112 and overridden, etc.). If the scanned channel is not available, the "change pump channel" action is cancelled. In such a case, at block 5728, the first central server 109 transmits a revocation code back to the second central server 108a via the revocation URL. The channel scan process 5734 is described in more detail below with reference to FIG.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the new channel is valid), then at block 5736 the first central server 109 determines whether any other infusions are currently in this new channel. channel is not associated with a valid channel. If another infusion is already associated with the new channel, then at block 5738 the first central server 109 sends a message to the user indicating that another infusion is now associated with the new channel and to the user. Causes digital assistant 118 to display a message asking if she wishes to overwrite the current infusion. This message preferably includes a "Yes" button, a "No" button, and a "Cancel" button. If the user presses the "Cancel" button, then at block 5728 the first central server 109 sends a revocation code back to the second central server 108a via the revocation URL. If the user presses the “No” button, the first central server 109 initiates another channel scanning process 5834 .

If the user presses the "No" button, at block 5740 the first central server 109 attempts to resolve the channel-patient-drug relationship in the database for this new channel. If the attempt to resolve the channel-patient-drug relationship in the database for the new channel at block 5742 was unsuccessful, then at block 5744 the first central server 109 associates the patient identifier with the primary infusion that was not moved. causing the digital assistant 118 to display a "change pump channel" error message containing the drug identifier (if applicable) that was removed and the drug identifier (if applicable) associated with the piggyback infusion that was not transferred. . Once the user acknowledges the "change pump channel" error message by pressing the "OK" button, at block 5746 the first central server 109 passes the failure code to the second central server 108a via the completion URL. send it back to

If another infusion was not already associated with the new channel at block 5736, or if the attempt to resolve the channel-patient-drug relationship in the database for the new channel was successful at block 5742, then at block 5748: The first central server 109 attempts to change the channel-patient-drug relationship in the database for both primary and piggyback infusions from the old channel to the new channel. If the attempt at block 5750 to move the channel-patient-drug relationship in the database from the old channel to the new channel is unsuccessful, the first central server 109 displays a "pump channel changed" error message to the digital assistant 118. Let

If the attempt to move the channel-patient-drug relationship in the database from the old channel to the new channel was successful at block 5750, then at block 5752 the first central server 109 determines the patient identifier associated with the moved primary infusion. Causes digital assistant 118 to display a "change pump channel" success message containing the drug identifier (if applicable) and the drug identifier associated with the piggyback infusion that was moved (if applicable). The display preferably also includes a message to the user to move the tube to the new channel. Once the user acknowledges the "change pump channel" success message by pressing the "OK" button, at block 5746 the first central server 109 sends a success code to the second central server 108a via the completion URL. send back.

(Channel scanning process)
FIG. 58 shows an example of the channel scanning process 5730 used above with reference to FIG. Typically, the channel scanning step 5730 prompts a user to scan for machine-readable identifiers associated with pump channels and determines whether the scanned channels are associated with previously scanned patient and medication identifiers. If the scanned channel is not associated with these patient and drug identifiers, the current action (eg, stop, abort, resume, change channel, remove pump, etc.) is cancelled.

More specifically, the exemplary channel scanning process 5730 causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the channel at block 5802 when the first central server 109 to start. An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with a channel is shown in FIG. For example, a user can use the digital assistant's 118 scanner to scan a barcode label associated with a channel. Alternatively, the user can manually enter the channel identifier into digital assistant 118 .

The channel identifier is then sent to the first central server 109 for verification at block 5804 . The first central server 109 then attempts to look up the channel identifier in its database. If the channel identifier does not exist as a valid channel identifier in the database (e.g., not properly formatted, not configured in first central server 109, etc.), then at block 5806 first central server 109 , causes the digital assistant 118 to display a channel disabled notification. For example, the digital assistant 118 can display a message that the channel is not set up in the first central server 109 and a button that allows the user to rescan the channel identifier or cancel the operation. can include If the user chooses to cancel the operation, at block 5808 the first central server 109 preferably sends a cancellation code to the second central server 108a via the cancellation URL.

Once a valid channel identifier is obtained, the first central server 109 uses the channel identifier to look up patient identifiers in the database. Then, at block 5810, the patient identifier from the database is compared to the scanned (or manually entered) patient identifier. If the two patient identifiers do not match, at block 5812 the first central server 109 causes the digital assistant 118 to display a patient invalid notification. For example, the digital assistant 118 can display a message that the scanned patient 112 is not associated with the scanned channel and indicate the actual patient 112 assigned to the scanned channel. Again, the PDA display may include buttons that allow the user to rescan the channel identifier or cancel the operation. If the user chooses to cancel the operation, at block 5808 the first central server 109 preferably sends a cancellation code to the second central server 108a via the cancellation URL.

Once a valid channel-patient relationship is established, the first central server 109 uses the channel identifier and the patient identifier to create a single drug identifier (or both primary drug 124 and piggyback drug 124) in the database. If associated with this channel, retrieve two drug identifiers). One or more drug identifiers from the database are then compared to the scanned (or manually entered) drug identifiers at block 5814 . If one or more drug identifiers from the database do not match the scanned (or manually entered) drug identifier, at block 5816 the first central server 109 causes the digital assistant 118 to display a drug invalid notification. . For example, the digital assistant 118 may display a message that the scanned medication 124 is not associated with the scanned channel, and the actual medication 124 (primary and piggyback, if applicable) assigned to the scanned channel. ) can be shown. Again, the PDA display may include buttons that allow the user to rescan the channel identifier or cancel the operation. If the user chooses to cancel the operation, at block 5808 the first central server 109 preferably sends a cancellation code to the second central server 108a via the cancellation URL.

If a valid channel-patient-pharmaceutical relationship is established, at block 5818 the first central server 109 indicates that a valid channel scan was performed without issuing an additional indication on the digital assistant 118. , returns control to the most recent action (eg, administer, stop, abort, resume, change channel, remove pump, etc.).

(Channel scanning process (new channel))
FIG. 59 shows an example of the channel scanning process 5734 used above with reference to FIG. Typically, the scan channel step 5734 prompts the user to scan for machine-readable identifiers associated with pump channels, and if the scanned channels are available (e.g., assigned to the current patient 112 but in use). not). If the scanned channel is not available, the current action (eg channel change) is cancelled.

More specifically, when the exemplary channel scanning process 5734 causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the channel by the first central server 109 at block 5902. to start. An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with a channel is shown in FIG. For example, the user can use the digital assistant's 118 scanner to scan a barcode label associated with the channel. Alternatively, the user can manually enter the channel identifier into digital assistant 118 .

The channel identifier is then sent to the first central server 109 for verification at block 5904 . The first central server 109 then attempts to look up the channel identifier in its database. If this channel identifier does not exist as a valid channel identifier in the database (e.g., not properly formatted, not configured in first central server 109, etc.), then at block 5906, first central server 109 causes the digital assistant 118 to display a channel disabled notification. For example, the digital assistant 118 can display a message that the channel is not set up in the first central server 109 and a button that allows the user to rescan the channel identifier or cancel the operation. can include If the user chooses to cancel the operation, at block 5908 the first central server 109 preferably sends a cancellation code to the second central server 108a via the cancellation URL.

Once a valid channel identifier is obtained, the first central server 109 uses the channel identifier to look up patient identifiers in the database. Then, at block 5910, the first central server 109 compares the patient identifier from the database with the scanned (or manually entered) patient identifier. If a valid patient identifier exists in the database but the two patient identifiers do not match (i.e. the channels are assigned to different patients 112), at block 5912 the first central server 109 checks the database and Check if this channel is active (in primary and/or piggyback mode).

If the channel is active, at block 5914 the first central server 109 sends a "non-overrideable" indication that a different patient 112 is associated with the scanned channel and that the channel is currently active. ' causes the digital assistant 118 to display an error message. The error message may also include data indicating the patient 112 associated with the scanned channel (eg, the patient's name), the primary medication 124, and/or the piggyback medication 124. The user is preferably given the option to cancel or rescan. If the user chooses to cancel the operation, at block 5908 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5902 the first central server 109 causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the channel.

If the channel is not active, at block 5916 the first central server 109 issues an "override continue" warning indicating that a different patient 112 was associated with the channel scanned, but the channel is currently not active. Cause the message to be displayed on the digital assistant 118 . This warning message preferably indicates that continuing will overwrite existing data (eg, disassociate other patients 112). The alert message may also include data indicating the patient 112 associated with the scanned channel (eg, the patient's name), the primary medication 124, and/or the piggyback medication 124. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, at block 5908 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5902 the first central server 109 causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the channel. If the user chooses to continue, at block 5918 the first central server 109 causes the digital assistant 118 to display a message indicating that it is authorized to use the selected channel. When the user presses "Continue", the first central server 109 returns control to the most recent action (eg dosing, channel change, etc.) without issuing additional indications to the digital assistant 118 .

If at block 5920 there is a valid patient identifier in the database and the two patient identifiers match (i.e., a channel is assigned to this patient 112), the first central server 109 at block 5922: Check the database to see if the channel is free (eg, no primary or piggyback injections are associated with this channel). If the channel is free, at block 5918 the first central server 109 causes the digital assistant 118 to display a message indicating that it is authorized to use the selected channel. If the channel is not free, at block 5924 the first central server 109 checks the database to see if the channel is active (in primary and/or piggyback mode).

If this channel is active, then at block 5926 the first central server 109 sends an "override" to indicate that this patient 112 is already associated with a scanned channel and that the channel is currently active. Impossible” error message is displayed on the digital assistant 118. The error message may also include data indicating the patient 112 (eg, the patient's name), the primary medication 124, and/or the piggyback medication 124. The user is preferably given the option to cancel or rescan. If the user chooses to cancel the operation, at block 5908 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5902 the first central server 109 causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the channel.

If this channel is not active, at block 5928 the first central server 109 sends a "continue" message indicating that this patient 112 is associated with the scanned channel, but that channel is currently not active. is displayed on the digital assistant 118 . The message may also include data indicating the patient 112 (eg, the patient's name), the primary medication 124, and/or the piggyback medication 124. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, at block 5908 the first central server 109 sends a cancellation code to the second central server 108a via the cancellation URL. If the user chooses to rescan, at block 5902 the first central server 109 causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the channel. If the user chooses to continue, at block 5918 the first central server 109 causes the digital assistant 118 to display a message indicating that it is authorized to use the selected channel. If the user presses continue again, the first central server 109 returns control to the most recent action (eg channel change) without issuing additional indications to the digital assistant 118 .

(Injection stop/stop process)
An example of an infusion stop/stop process 6000 is shown in FIG. The infusion stop/stop process 6000 can be used to temporarily stop (ie, pause) the infusion process or to stop (ie, terminate) the infusion process completely. Typically, the infusion stop/stop process 6000 includes information regarding whether a stop or stop is to be performed, information identifying which patient 112 is to be affected (eg, patient ID), and Input is received from an electronic device, such as digital assistant 118, including information (eg, RxID) identifying which medication 124 for 112 is to be stopped or discontinued. Step 6000 then sends this information to the first central server 109, which verifies that the channel identification information matches the stop/stop order information, and that the correct infusion is stopped. Or confirm that it will be canceled.

More specifically, the exemplary infusion stop/stop process 6000 begins when the second central server 108a causes the digital assistant 118 to display a list of patients at block 6002 . An example of a digital assistant display 118a showing a list of patients is shown in FIG. The list of patients is preferably limited to those patients associated with the user (eg, clinician 116) logged into that digital assistant 118 at that time. Once the user selects a patient 112, information identifying the selection and/or the patient 112 is returned from the digital assistant 118 to the second central server 108a. Communication between digital assistant 118 and second central server 108a may be via any suitable communication channel, such as wireless/wired network 102 described above. Then, at block 6004, the second central server 108a causes the digital assistant 118 to display the list of actions. An example of a digital assistant display 118a showing a list of actions is shown in FIG. The list of actions is preferably limited to actions associated with the selected patient 112 . For example, the "stop infusion" and "stop infusion" actions will only be available if the infusion associated with this patient 112 is currently running.

When the user selects a "stop infusion" action or a "stop infusion" action from the list of actions, information identifying the selected action is sent to the second central server 108a. In response, at block 6006, the second central server 108a lists all ongoing infusions for that patient 112 and scans for machine readable identifiers associated with medications 124 to be stopped or discontinued. The digital assistant 118 displays a screen prompting the user to An example of a digital assistant display 118a that prompts a user to scan a machine-readable identifier associated with medication 124 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the medication label 124a on the bag of medication 124 (eg, the bar code on the infusion bag). Alternatively, the user can manually enter the medication identifier into digital assistant 118 .

Then, at block 6008, the medication identifier is sent to the second central server 108a for verification. The second central server 108a attempts to look up the drug identifier in its database. If the medication identifier (eg bag ID) does not exist as a valid medication identifier in the database, then at block 6010 the second central server 108a causes the digital assistant 118 to display an item invalidation notification. Once the user has acknowledged the item invalidation notification (or the notification has timed out), at block 6006 the digital assistant 118 presents a screen prompting the user to scan the machine readable identifier associated with the medication 124 to be stopped or discontinued. Redisplay.

If at block 6008 the medication identifier (e.g. bag ID) exists as a valid medication identifier in the database, second central server 108a prompts the user to scan for a machine readable identifier associated with patient 112 at block 6012. The digital assistant 118 is caused to display a screen prompting to An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with patient 112 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the barcode label on the patient's wristband 112a. Alternatively, the user can manually enter the patient identifier into digital assistant 118 . Then, at block 6014, the patient identifier is sent to the second central server 108a for verification. The second central server 108a then attempts to look up the patient identifier in its database. If the patient identifier (eg, wristband ID) does not exist as a valid patient identifier in the database, then at block 6016 the second central server 108a causes the digital assistant 118 to display a patient invalid notification. Once the user acknowledges the invalid patient notification (or the notification times out), at block 6012 the digital assistant 118 redisplays the screen prompting the user to scan the machine-readable identifier associated with the patient 112.

At block 6014, if the patient identifier (eg, wristband ID) exists as a valid patient identifier in the database, the second central server 108a responds to a code indicating the reason for the "stop infusion" action or the "stop infusion" action. You can also prompt the user with If this reason code is not provided, the system preferably displays a message to the user that a reason code must be provided. Additionally, the second central server 108a can timestamp the order and/or prompt the user as to when this action should be performed. Still further, the second central server 108a preferably checks the status of the infusion order to determine whether the infusion order is active or aborted.

If the infusion order is active, at block 6018 the second central server 108a attempts to issue a "stop infusion" or "stop infusion" action by the user based on the user selection from block 6004. determine what If the user is attempting to issue a "stop infusion" action, then at block 6020 the second central server 108a sets the "DCFlag" in the "stop infusion" XML document to "FALSE". If the user is attempting to issue a "stop injection" action, at block 6022 the second central server 108a sets the "DCFlag" to "TRUE" in the "stop injection" XML document. Of course, any known method of displaying the state of variables can be used.

A "stop infusion" XML document containing patient identifier (e.g. wristband ID), medication identifier (e.g. bag ID), completion URL, cancellation URL, and DCFlag (indicating stop vs. stop) is then sent to the first central It is transmitted to the server 109 . The completion URL is the network address to be used when stopping or aborting an infusion is successful. The cancel URL is the network address that will be used if the "stop infusion" or "stop infusion" action fails or is cancelled.

Once the first central server 109 receives the "stop injection" XML document, at block 6024 the first central server 109 determines whether the "stop injection" XML document is valid. For example, the first central server 109 can check whether any data normally expected in a "stop injection" XML document is missing from the received "stop injection" XML document. If the first central server 109 determines that the "stop injection" XML document is not valid, at block 6026 the first central server 109 may perform a "stop injection" or "stop injection" operation. Causes the digital assistant 118 to display an error message that indicates to the user that it could not. This indication can include reasons such as what data was missing from the "stop injection" XML document. After the user presses the "OK" button to acknowledge the error message, at block 6028 the first central server 109 returns a failure code to the second central server 108a via the cancel URL.

If the first central server 109 determines that the “stop injection” XML document is valid, the first central server 109 initiates a channel scanning step 5730 . Typically, the channel scan step 5730 prompts the user to scan for machine-readable identifiers associated with the pump channel currently performing the infusion to be stopped or discontinued, and the scanned channels are identified as patient identifiers and drug identifiers. Determine if it is associated (as detailed above with reference to FIG. 58). If the scanned channel is not associated with a patient identifier and drug identifier, the "stop infusion" or "stop infusion" action is cancelled. In such a case, at block 6028, the first central server 109 transmits a revocation code back to the second central server 108a via the revocation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the channel is valid), then at block 6032 the first central server 109 determines whether the patient 112 and the drug 124 to stop and the drug 124 Causes the digital assistant 118 to display a message indicating the infusion to stop including details of the channels present. The PDA display preferably also includes a "Continue" button and a "Cancel" button. In this way, the user can manually stop the displayed infusion and then press the "Continue" button to prompt the first central server 109 to check if the correct infusion was actually stopped or aborted. can be notified to Alternatively, the user can press the "Cancel" button, at which point the first central server 109 at block 6028 returns a revocation code to the second central server 108a via the revocation URL. do.

If the user presses the “continue” button, at block 6034 the first central server 109 determines whether the infusion has stopped by reading the status information sent to the first central server 109 by the pump 120 . to decide. If the pump 120 cannot communicate with the first central server 109, the first central server 109 generates a loss of communication event for that channel. If communication with a channel is lost, the status of the infusion on that channel cannot be changed to "stopped" or "aborted" until communication with that channel is restored. If communication is working properly but the infusion was not stopped, then at block 6036 the first central server 109 displays a warning message indicating that the infusion was not stopped and indicating the patient 112 and the infusion to stop. is displayed on the digital assistant 118 . The display preferably also includes an "OK" button and a "Cancel" button. If the user presses the "OK" button, at block 6034 the first central server 109 checks again to see if the correct infusion was actually aborted or stopped. If the user presses the "Cancel" button, then at block 6028 the first central server 109 sends a cancellation code back to the second central server 108a via the cancellation URL.

If the infusion was stopped at block 6034, then at block 6038 the first central server 109 checks whether this is a "stop infusion" or a "stop infusion" operation. For example, the first central server 109 can check the state of a flag such as DCFlag set by block 6020 or block 6022 . If this is a "stop infusion" operation (i.e. suspend infusion), then at block 6044 the first central server 109 sends a success code and DCFlag-=FALSE to the second central server 108a via the completion URL. Send it back.

Otherwise, if this is an "abort infusion" action (i.e., end infusion), at block 6040 the first central server 109 retrieves the patient identifier, drug It preferably attempts to break the database association between identifiers and channel identifiers. If the user wants to stop or abort both primary and piggyback injections that are running on a channel, the user can perform the "stop injection" or "stop injection" operation twice, once for each injection. can be executed. If the first central server 109 did not succeed in disassociating the database at block 6042, then at block 6028 the first central server 109 passes the failure code to the second central server 109 via the revocation URL. Return to server 108a. If the first central server 109 successfully disassociates the database at block 6042, at block 6044 the first central server 109 sends a success code and DCFlag=TRUE to the second to the central server 108a.

The first central server 109 disassociates between the patient identifier, the drug identifier and the channel identifier for the selected infusion only if the "stop infusion" operation is successful. Otherwise, this association is maintained. For example, if the "stop infusion" operation succeeds or the "stop infusion" operation fails, the association between patient identifier, drug identifier, and channel is maintained. Similarly, upon receiving a success code from the first central server 109, the second central server 108a only updates the status of the infusion to "stopped" or "aborted." Any other outcome (eg, a cancel code or a failure code) will cause the second central server 108a to keep the injection in its previous state. At any point during process 6000, the user preferably has the option to cancel process 6000. FIG. The Stop/Abort step can be used to document that the infusion has been restarted for MAR purposes.

(Injection restart process)
An example of a reinfusion process 6100 is shown in FIG. A resume infusion process 6100 can be used to resume a stopped (ie, suspended) infusion process. However, the resume injection process 6100 cannot be used to restart an aborted (ie, terminated) injection process. Generally, the restart infusion process 6100 includes information indicating that the restart process is to be performed, information identifying which patient 112 is to be affected (eg, patient ID), and which patient 112 Input is received from an electronic device, such as digital assistant 118, including information (eg, RxID) identifying whether medication 124 is to be resumed. Step 6100 then sends this information to the first central server 109, which verifies that the channel identification information matches the resumption order information, and correct infusion is resumed. Confirm that

More specifically, the exemplary resume infusion process 6100 begins when the second central server 108a causes the digital assistant 118 to display a list of patients at block 6102 . An example of a digital assistant display 118a showing a list of patients is shown in FIG. The list of patients is preferably limited to those patients associated with the user (eg, clinician 116) logged into that digital assistant 118 at that time. Once the user selects a patient 112, information identifying the selection and/or the patient 112 is returned from the digital assistant 118 to the second central server 108a. Communication between digital assistant 118 and second central server 108a may be via any suitable communication channel, such as wireless/wired network 102 described above. Then, at block 6104, the second central server 108a causes the digital assistant 118 to display the list of actions. An example of a digital assistant display 118a showing a list of actions is shown in FIG. The list of actions is preferably limited to actions associated with the selected patient 112 . For example, a "resume infusion" action would only be available if the infusion associated with this patient 112 is currently in a stopped state.

When the user selects the "resume infusion" action from the list of actions, information identifying the selected action is sent to the second central server 108a. In response, at block 6106, the second central server 108a causes the digital assistant 118 to display a screen prompting the user to scan the machine-readable identifier associated with the medication 124 to be resumed. An example of a digital assistant display 118a that prompts a user to scan a machine-readable identifier associated with medication 124 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the medication label 124a on the bag of medication 124 (eg, the barcode on the infusion bag). Alternatively, the user can manually enter the medication identifier into digital assistant 118 .

Then, at block 6108, the medication identifier is sent to the second central server 108a for verification. The second central server 108a attempts to look up the drug identifier in its database. If the medication identifier (eg bag ID) does not exist as a valid medication identifier in the database, then at block 6110 the second central server 108a causes the digital assistant 118 to display an item invalidation notification. Once the user acknowledges the item invalidation notification (or the notification times out), at block 6106 the digital assistant 118 redisplays a screen prompting the user to scan the machine-readable identifier associated with the medication 124 and resume. indicate. If the user scans a machine-readable identifier associated with a medication 124 to be resumed and the medication 124 has been discontinued, the second central server 108a determines that the medication 124 may be resumed due to its discontinued status. Preferably, the digital assistant 118 displays a message to the user indicating that it cannot.

If at block 6108 the medication identifier (e.g. bag ID) exists as a valid medication identifier in the database but has not been discontinued, then at block 6112 the second central server 108a retrieves the machine readable identifier associated with the patient 112. Cause the digital assistant 118 to display a screen prompting the user to scan. An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with patient 112 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the barcode label on the patient's wristband 112a. Alternatively, the user can manually enter the patient identifier into digital assistant 118 . Then, at block 6114, the patient identifier is sent to the second central server 108a for verification. A second central server 108a then attempts to look up the patient identifier in its database. If the patient identifier (eg, wristband ID) does not exist as a valid patient identifier in the database, at block 6116 the second central server 108a causes the digital assistant 118 to display a patient invalid notification. Once the user acknowledges the invalid patient notification (or the notification times out), at block 6112 the digital assistant 118 redisplays the screen prompting the user to scan the machine-readable identifier associated with the patient 112.

At block 6114, if the patient identifier (eg, wristband ID) exists as a valid patient identifier in the database, the second central server 108a prompts the user for a code indicating the reason for the "resume infusion" action. can also If no reason code has been provided, the system preferably displays a message to the user that a reason code must be provided. Additionally, the second central server 108a can time stamp the order and/or prompt the user as to when the action should be performed. Still further, the second central server 108a preferably checks the status of the infusion order to determine whether the infusion order is active or aborted.

If the infusion order is active, the second central server 108 a transmits a “resume infusion” XML document to the first central server 109 . A "Resume Infusion" XML document includes a patient identifier (eg, wristband ID), a medication identifier (eg, bag ID), a completion URL, and a cancellation URL. The completion URL is the network address that will be used if the infusion is restarted successfully. The cancel URL is the network address that will be used if the "resume injection" operation fails or is cancelled.

Once the first central server 109 receives the "resume infusion" XML document, at block 6124 the first central server 109 determines whether the "resume infusion" XML document is valid. For example, the first central server 109 can check whether any data that would normally be expected in a "resume infusion" XML document is missing from the received "resume infusion" XML document. If the first central server 109 determines that the "resume infusion" XML document is not valid, at block 6126 the first central server 109 sends an error message indicating to the user that the "resume infusion" operation could not be performed. is displayed on the digital assistant 118 . This indication can include reasons such as what data was missing from the "restart injection" XML document. After the user presses the "OK" button to acknowledge the error message, at block 6128 the first central server 109 returns a failure code to the second central server 108a via the cancel URL.

If the first central server 109 determines that the “resume infusion” XML document is valid, the first central server 109 initiates a channel scanning step 5730 . Typically, the channel scan step 5730 prompts the user to scan for machine-readable identifiers associated with the pump channel currently associated with the infusion to resume, and whether the scanned channels are associated with patient identifiers and drug identifiers. Determine if (as detailed above with reference to FIG. 58). If the scanned channel is not associated with a patient identifier and drug identifier, the "resume infusion" action is cancelled. In such a case, at block 6128, the first central server 109 transmits a revocation code back to the second central server 108a via the revocation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the channel is valid), then at block 6132 the first central server 109 sends a message indicating the patient 112 and the infusion to resume to the digital assistant. 118 to display. The PDA display preferably also includes a "Continue" button and a "Cancel" button. In this method, the user can manually restart the displayed infusion and then press the "Continue" button to notify the first central server 109 to check if the correct infusion has actually been restarted. Alternatively, the user can press the "Cancel" button, at which point the first central server 109 at block 6128 returns a revocation code to the second central server 108a via the revocation URL. do.

If the user presses the “continue” button, at block 6134 the first central server 109 determines whether infusion has resumed by reading the status information sent to the first central server 109 by the pump 120 . judge. If the pump 120 cannot communicate with the first central server 109, the first central server 109 generates a communication loss event for that channel. If communication with a channel is lost, the infusion status for that channel cannot be changed to "resumed" until communication with that channel is restored. If communication is working properly but the infusion was not restarted, then at block 6136 the first central server 109 displays a warning message indicating that the infusion was not restarted and indicating the patient 112 and the infusion to be restarted. is displayed on the digital assistant 118 . The display preferably also includes an "OK" button and a "Cancel" button. If the user presses the "OK" button, at block 6134 the first central server 109 checks again to see if the correct infusion has indeed been resumed. If the user presses the "Cancel" button, then at block 6128 the first central server 109 sends a cancellation code back to the second central server 108a via the cancellation URL.

If infusion is resumed at block 6134, at block 6144 the first central server 109 returns a success code to the second central server 108a via the completion URL. A first central server 109 maintains an association between patient identifiers, drug identifiers, and channel identifiers for selected infusions . The second central server 108a only updates the status of the injection to "running" upon receipt of the success code from the first central server 109a. Any other result (eg, a cancel code or a failure code) will cause the second central server 108a to retain the injection in its previous state. Preferably, if the user wishes to resume both primary and piggyback injections running on a channel, the user performs the "resume injection" operation twice, once for each injection. can do. The restart step can be used to document that the infusion has been restarted for MAR purposes.

(Pump removal step)
An example of a pump removal process 6200 is shown in FIG. The remove pump process 6200 removes the channel-patient-drug relationship in the database of the first central server 109 independently of the discontinuation orders existing in the pharmacy's database and without going through the stop/stop infusion process 6000 described above. Can be used to terminate. Generally, the remove pump process 6200 includes information indicating that the remove pump process is to be performed, information identifying which patient 112 is to be affected (e.g., patient ID), and a patient 112 An input is received from an electronic device, such as digital assistant 118, that includes information (eg, RxID) indicating which medication 124 will be affected. Step 6200 then sends this information to the first central server 109, which verifies that the channel identification information matches the pump removal order information, and that the correct pump 120 is removed. be confirmed.

More specifically, the exemplary pump removal process 6200 begins at block 6202 when the second central server 108a causes the digital assistant 118 to display a list of patients for selection. An example of a digital assistant display 118a showing a list of patients is shown in FIG. The list of patients is preferably limited to those patients associated with the user (eg, clinician 116) logged into that digital assistant 118 at that time. Once the user selects a patient 112, the selection and/or information identifying the patient 112 is returned from the digital assistant 118 to the second central server 108a. Communication between digital assistant 118 and second central server 108a may be via any suitable communication channel, such as wireless/wired network 102 described above. Then, at block 6204, the second central server 108a causes the digital assistant 118 to display the list of actions. An example of a digital assistant display 118a showing a list of actions is shown in FIG. The list of actions is preferably limited to actions associated with the selected patient 112 . For example, the “pump off” action would only be available if the infusion associated with this patient 112 is currently listed in the first central server 109 database.

When the user selects the "pump removed" action from the list of actions, information identifying the selected action is sent to the second central server 108a. In response, at block 6206, the second central server 108a displays a screen to the digital assistant 118 prompting the user to scan the machine-readable identifier associated with the drug 124 affected by this "pump off" operation. to display. An example of a digital assistant display 118a that prompts a user to scan a machine-readable identifier associated with medication 124 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the medication label 124a on the bag of medication 124 (eg, the barcode on the infusion bag). Alternatively, the user can manually enter the medication identifier into digital assistant 118 .

Then, at block 6208, the medication identifier is sent to the second central server 108a for verification. The second central server 108a (or digital assistant 118) checks whether a properly formatted medication identifier has been received. Since the purpose of the "remove pump" operation is to remove associations from the database of the first central server 109a that do not have corresponding infusions in the database of the second central server 108a, the second central server 108a: Preferably, there is no need to check if the drug identifier matches the current infusion in the database of the second central server 108a.

If the medication identifier (eg, bag ID) is not properly formatted, at block 6210 the second central server 108a causes the digital assistant 118 to display an item invalidation notification. Once the user acknowledges the item invalidation notification (or the notification times out), at block 6206 the digital assistant 118 redisplays a screen prompting the user to scan the machine-readable identifier associated with the medication 124 to be reopened. indicate.

If the medication identifier (e.g., bag ID) was properly formatted at block 6208, then at block 6212 the second central server 108a displays a screen prompting the user to scan the machine readable identifier associated with the patient 112. Display it on the digital assistant 118 . An example of a digital assistant display 118a prompting a user to scan a machine readable identifier associated with patient 112 is shown in FIG. The user can use the digital assistant's 118 scanner to scan the barcode label on the patient's wristband 112a. Alternatively, the user can manually enter the patient identifier into digital assistant 118 . Then, at block 6214, the patient identifier is sent to the second central server 108a for verification. The second central server 108a (or digital assistant 118) then checks whether a properly formatted patient identifier has been received. Since the purpose of the "remove pump" operation is to remove associations from the database of the first central server 109 that do not have a corresponding infusion in the database of the second central server 108a, the second central server 108a: Preferably, there is no need to check whether the patient identifier matches the current infusion in the database of the second central server 108a. However, the second central server 108 a (or digital assistant 118 ) can check whether the patient identifier matches the patient 112 selected at block 6202 .

If the patient identifier (eg, wristband ID) is not properly formatted, or if the patient identifier does not match the patient 112 selected at block 6202, at block 6216 the second central server 108a sends an invalid patient notification. Display it on the digital assistant 118 . Once the user acknowledges the invalid patient notification (or the notification times out), at block 6212 the digital assistant 118 redisplays the screen prompting the user to scan the machine-readable identifier associated with the patient 112.

If at block 6214 the patient identifier (e.g., wristband ID) is properly formatted and matches the patient 112 selected at block 6202, then at block 6217 the second central server 108a generates the "stop alarm routing" XML Transmit the document to the first central server 109; The "stop alarm routing" XML document includes a patient identifier (eg, wristband ID), a medication identifier (eg, bag ID), a completion URL, and a cancellation URL. The completion URL is the network address that will be used if pump 120 is successfully removed. The cancel URL is the network address that will be used if the "remove pump" operation fails or is cancelled.

Once the first central server 109 receives the "stop alarm routing" XML document, at block 6224 the first central server 109 determines whether the "stop alarm routing" XML document is valid. For example, the first central server 109 can check whether any data normally expected in an "alarm routing stop" XML document is missing from the received "alarm routing stop" XML document. If the first central server 109 determines that the "stop alarm routing" XML document is not valid, at block 6226 the first central server 109 fails to perform the "stop alarm routing" action. causes the digital assistant 118 to display an error message that indicates to the user that This indication can include reasons such as what data was missing from the "stop alarm routing" XML document. After the user presses the "OK" button to acknowledge the error message, at block 6228 the first central server 109 returns a failure code to the second central server 108a via the cancel URL.

If the first central server 109 determines that the “stop alarm routing” XML document is valid, the first central server 109 initiates a channel scanning step 5730 . Typically, the scan channel step 5730 prompts the user to scan for machine-readable identifiers associated with the pump channel currently associated with the pump 120 to be removed, and whether the scanned channel is associated with a patient identifier and a medication identifier. Determine if (as detailed above with reference to FIG. 58). If the scanned channel is not associated with a patient identifier and drug identifier, the "pump off" operation is cancelled. In such a case, at block 6228, the first central server 109 transmits a revocation code back to the second central server 108a via the revocation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the channel is valid), then at block 6232 the first central server 109 indicates the patient 112 and infusion associated with this operation. Cause the message to be displayed on the digital assistant 118 . The PDA display preferably also includes a "Continue" button and a "Cancel" button. In this method, the user can manually stop the displayed infusion and then press the "Continue" button to notify the first central server 109 to check if the correct infusion was actually stopped. . Alternatively, the user can press the "Cancel" button, at which point the first central server 109, at block 6228, sends the revocation code to the second central server 108a via the revocation URL. Send it back.

If the user presses the “continue” button, at block 6234 the first central server 109 determines whether the infusion has stopped by reading the status information sent to the first central server 109 by the pump 120 . judge. If the infusion was not stopped, at block 6236 the first central server 109 causes the digital assistant 118 to display a warning message indicating that the infusion was not stopped. The display preferably also includes a "Continue" button and a "Cancel" button. If the user presses the "Cancel" button, then at block 6228 the first central server 109 sends a cancellation code back to the second central server 108a via the cancellation URL.

If the user presses the "Continue" button, at block 6240 the first central server 109 sends the patient identifier, the drug identifier, and the channel identifier for the primary infusion or the piggyback infusion, but preferably not both. Attempts to break the database association between identifiers. If the user wishes to stop alarm routing associated with both primary and piggyback injections running on one channel, the user can perform the "remove pump" operation twice, one for each injection. Can be run once. If the first central server 109 did not successfully disassociate the database at block 6242, then at block 6228 the first central server 109 sends a failure code to the second central server 108a via the revocation URL. Send it back. If the first central server 109 successfully disassociates the database at block 6242, at block 6244 the first central server 109 returns a success code to the second central server 108a via the completion URL. .

The first central server 109 disassociates between the patient identifier, drug identifier, and channel identifier for the selected infusion only if the "pump off" operation is successful. Otherwise, this association is maintained. The second central server 108a does not need to update the status of an infusion that was "released" upon receiving a success code from the first central server 109;

(Encrypted communication process)
As noted above, the system can include multiple digital assistants 118 and multiple medical devices (eg, infusion pumps 120) communicating via a wired or wireless network. Since some of the transmitted data is sensitive medical data, it is preferably encrypted and communicated to authorized users and devices only in a free environment. To set up a new digital assistant 118 or medical device 120, an activation phase of the authentication process can be performed. Each time a commissioned device is hardened, an authentication process is preferably performed to verify that communication is occurring with an authorized device and/or user. Once a device and/or user is authorized, encrypted data may be encrypted to send parameters, instructions, data, alarms, status information, and any other type of information between digital assistants, medical devices, and/or servers. One-way communication and/or two-way communication can occur.

Referring to FIG. 63, the digital assistant activation phase (ie, server registration phase) of the encrypted communication process 6300 begins when the first central server 109 creates a digital assistant user account (block 6302). For example, digital assistant user accounts can be set up using Microsoft Active Directory in a well-known manner. First central server 109 then generates a digital certificate for digital assistant 118 at block 6304 . Digital certificates can be generated in any manner. For example, a digital certificate can be generated in well-known fashion at the first central server 109 using Microsoft Digital Certificate Services. The digital certificate preferably contains the digital assistant's public key digitally signed with the first central server's private key. In other words, the first central server 109 acts as a certification authority (CA) for the digital assistant's digital certificate. Once the digital certificate is generated, at block 6306 the first central server 109 maps the digital certificate to the user account.

Then at block 6308 the digital assistant's digital certificate and the digital assistant's private key are sent by the first central server 109 to the digital assistant 118 at block 6310 . The digital assistant's digital certificate and the digital assistant's private key are preferably sent to the digital assistant 118 via a secure connection. For example, an RS-232 cable that is not connected to any other device can be used. Additionally, the first central server's digital certificate is sent by the first central server 109 at block 6312 to the digital assistant 118 at block 6314 . Again, the first central server's digital certificate is preferably sent to the digital assistant 118 via an encrypted connection such as an RS-232 cable that is not connected to any other device. At this point, the digital assistant 118 is activated (ie, registered with the server).

Of course, any method of communicating with the digital assistant 118 can be used. In one example, the digital assistant's private key can be stored in a storage device (eg, EPROM) associated with the digital assistant 118 at the time the digital assistant 118 is manufactured. Additionally, each digital assistant 118 can have the same private key with a different identification code used to distinguish the digital assistants 118 from each other.

Each time the activated digital assistant 118 is powered on, the digital assistant 118 and the first central server 109 will: A certification process must be performed. In the illustrated example, digital assistant 118 establishes an unencrypted 802.11 (wireless Ethernet) connection with first central server 109 at blocks 6316 and 6318 . Of course, any kind of connection can be used, such as a wired connection or a connection using another protocol.

64, at block 6402 the digital assistant 118 sends a request to the first central server 109 to establish an encrypted connection. The first central server 109 receives the digital assistant's request to establish an encrypted connection at block 6404 . The first central server 109 instructs the digital assistant 118 to establish an encrypted connection at block 6406 by sending a copy of the first central server's digital certificate over the unencrypted connection. Respond to requests. At block 6408, the digital assistant 118 receives the first central server's digital certificate.

At block 6410, the digital assistant 118 authenticates the first central server 109 using the first central server's digital certificate. Further, at block 6412, the digital assistant 118 retrieves the uniform resource locator (URL) associated with the embedded first central server 109 using the first central server's digital certificate. The digital assistant 118 now knows that it is talking to the real first central server 109 and can request data and services from the retrieved URL.

Next, at block 6414, the first central server 109 sends a request to the digital assistant 118 to establish the other half of the encrypted connection. The digital assistant 118 receives the first central server request at block 6416 . Digital assistant 118 responds to the request to establish an encrypted connection at block 6418 by sending a copy of the digital assistant's digital certificate to first central server 109 . At block 6420, the first central server 109 receives the digital assistant's digital certificate.

At block 6422, the first central server 109 authenticates the digital assistant 118 using the digital assistant's digital certificate. The first central server 109 now knows that it is talking to the activated digital assistant 118 and is able to communicate with the digital assistant 118 . 65, the first central server 109 identifies the files that this digital assistant 118 is authorized to access by mapping the session for the digital assistant's user account to the active directory at block 6502. Confirm.

Because the digital assistant 118 is now communicating with the first central server 109 via an encrypted connection, the digital assistant 118 is authorized to access the specific file on the first central server 109, At block 6504, the digital assistant 118 may establish an encrypted communication session with the first central server 109 by accessing the URL retrieved from the first central server's digital certificate. The first central server 109 also establishes an encrypted communication session at block 6506 . Additionally, at block 6508, the application on the first central server 109 verifies that the digital assistant 118 belongs to the appropriate active directory.

Although the digital assistant 118 can now authenticate, the first central server 109 still does not know the identity of the user using the digital assistant 118 . This is important because some users may have different access rights than others, and certain alarms and other data are only sent to certain users. Accordingly, an application on first central server 109 may request a username and password from the user of digital assistant 118 at block 6510 . Once the digital assistant 118 receives the request for username and password at block 6512, at block 6514 the digital assistant 118 retrieves the username and password from the user via prompts on the digital assistant display 118a. The username and password are then sent by the digital assistant 118 at block 6516 and received by the first central server 109 at block 6518 . An application on the first central server 109 may then authenticate the user at block 6520 .

Once a user is authenticated on a server (e.g., first central server 109), using authentication credentials to automatically authenticate a digital assistant 118 on another server (e.g., second central server 108a). can be done. In one example, a user can only be authenticated if the user has been authenticated at both the first central server 109 and the second central server 108a. Therefore, whenever a username or password is created or modified, the username and password are preferably synchronized between the first central server 109 and the second central server 108a.

After authenticating the user, first central server 109 preferably returns a token that is unique to the session between the user and first central server 109 . This session token is sent with each request made to the first central server 109 (eg, in an HTTP header or as a cookie) as a means of authenticating the source of the request and thus the destination of the response. Once this token is in place, the digital assistant 118 can continuously move from one wireless access point 114 to another.

66, the medical device activation phase (ie, server registration phase) of process 6300 begins at block 6602 when the first central server 109 creates a medical device user account. For example, medical device user accounts can be set up using Microsoft Active Directory in a well-known manner. The first central server 109 then generates a digital certificate for the medical device 120 at block 6604 . Digital certificates can be generated in any manner. For example, a digital certificate can be generated in a well-known manner at the first central server 109 using Microsoft Digital Certificate Services. The digital certificate preferably includes the medical device's public key digitally signed with the first central server's private key. In other words, the first central server 109 acts as a certification authority (CA) for digital certificates of medical devices. Once the digital certificate is generated, at block 6606 the first central server 109 maps the digital certificate to the user account.

Then at block 6608 the medical device's digital certificate and the medical device's private key are sent by the first central server 109 to the medical device 120 at block 6610 . The medical device's digital certificate and the medical device's private key are preferably transmitted to the medical device 120 over an encrypted connection, such as an RS-232 cable, that is not connected to any other device. Additionally, the digital certificate of the first central server 109 is sent by the first central server 109 at block 6612 to the medical device 120 at block 6614 . Again, the first central server's digital certificate is preferably transmitted to medical device 120 via an encrypted connection such as an RS-232 cable that is not connected to any other device. At this point, the medical device 120 is activated (ie, registered with the server).

Of course, any method of communicating with medical device 120 can be used. In one example, the medical device's private key may be stored in a storage device (eg, EPROM) associated with the medical device 120 at the time the medical device 120 is manufactured. Additionally, each medical device 120 can have the same private key with a different identification code used to distinguish the medical devices 120 from each other.

Each time an activated medical device 120 is powered up, the medical device 120 and the first central server 109 perform an authentication process in order to move from an unencrypted wireless connection to an encrypted wireless connection. There must be. In the example shown in FIG. 67, the medical device 120 establishes an unencrypted 802.11 (wireless Ethernet) connection with the first central server 109 at blocks 6702 and 6704 . Of course, any kind of connection can be used, such as a wired connection or a connection using another protocol.

Next, at block 6706, the medical device 120 sends a request to the first central server 109 to establish an encrypted connection. The first central server 109 receives the medical device's request to establish an encrypted connection at block 6708 . The first central server 109 instructs the medical device 120 to establish an encrypted connection at block 6710 by sending a copy of the first central server's digital certificate to the medical device 120 via an unencrypted connection. Respond to requests. At block 6712, the medical device 120 receives the first central server's digital certificate.

At block 6714, the medical device 120 authenticates the first central server 109 using the first central server's digital certificate. Further, at block 6716, the medical device 120 retrieves the uniform resource locator (URL) associated with the embedded first central server 109 using the first central server's digital certificate. The medical device 120 now knows that it is talking to the real first central server 109 and can request data and services from the retrieved URL.

Next, at block 6718, the first central server 109 sends a request to the medical device 120 to establish the other half of the encrypted connection. The medical device 120 receives the first central server request at block 6720 . The medical device 120 responds to the request to establish the encrypted connection at block 6722 by sending a copy of the medical device's digital certificate to the first central server 109 . At block 6724, the first central server 109 receives the medical device's digital certificate.

68, at block 6802, the first central server 109 authenticates the medical device 120 using the medical device's digital certificate. The first central server 109 now knows that it is talking to the activated medical device 120 and can communicate with the medical device 120 . In addition, the first central server 109 ascertains the files this medical device 120 is authorized to access by mapping the session for the medical device's user account to the active directory at block 6804 .

Because the medical device 120 is now communicating with the first central server 109 via an encrypted connection, the medical device 120 is authorized to access certain files on the first central server 109, At block 6806, the medical device 120 may establish an encrypted communication session with the first central server 109 by accessing the URL retrieved from the first central server's digital certificate. The first central server 109 also establishes an encrypted communication session at block 6808 . Additionally, at block 6810, the application on the first central server 109 verifies that the medical device 120 belongs to the proper active directory.

Although the medical device 120 can now be authenticated, the first central server 109 still does not know the identity of the user using the medical device 120 . In many cases, no user is associated with medical device 120 . For some applications this can be important as some users can have different access rights than others. Further, medical devices can have different "roles". For example, a medical device may have a "one-way communication" role or a "two-way communication" role. In this manner, a medical device 120 capable of two-way communication can be placed in a system requiring only one-way communication devices. Similarly, a system that can accommodate both one-way and two-way communication devices may need to be informed of the type of device to connect.

Accordingly, an application on the first central server 109 may request a username and password from the user of the medical device 120 at block 6812 . Once the medical device 120 receives the request for the username and password at block 6814, at block 6816 the medical device 120 receives the username and password from the user via a prompt on the medical device 120 or the associated digital assistant display 118a. retrieve the password. The username and password are then sent by the medical device 120 (or other device) at block 6902 of FIG. 69 and received by the first central server 109 at block 6904 . An application on the first central server 109 may then authenticate the user at block 6906 .

Once a user is authenticated on a server (eg, first central server 109), authentication credentials can be used to automatically authenticate the user on another server (eg, second central server 108a). . In one example, a user can only be authenticated if the user has been authenticated at both the first central server 109 and the second central server 108a. Therefore, whenever a username or password is created or modified, the username and password are preferably synchronized between the first central server 109 and the second central server 108a.

After authenticating the user, first central server 109 preferably returns a token that is unique to the session between the user and first central server 109 . This session token is sent with each request made to the first central server 109 (eg, in an HTTP header or as a cookie) as a means of authenticating the source of the request and thus the destination of the response.

Encrypted one-way communications can now be sent from medical device 120 to digital assistant 118 . For example, the medical device 120 can report settings, generate alarms, and the like. In the illustrated example, the medical device 120 determines the data to send to the digital assistant 118 via the first central server 109 at block 6908 . This data is then sent to the first central server 109 at block 6910 and received by the first central server 109 at block 6912 . Then, at block 6914, the first central server 109 determines the users authorized to receive this data, and at block 6916 determines the digital assistants 118 with which those users are currently associated. can be done. For example, a lookup table stored in a database on the first central server 109 can be used.

Then, at block 6918, the first central server 109 sends the data to the appropriate digital assistant 118, and at block 6920 the digital assistant 118 receives and displays the data. Additionally, encrypted two-way communication can be achieved. For example, digital assistant 118 and/or first central server 109 can send data, instructions, configuration information, or any other type of information to medical device 120 .

It should be emphasized that the above-described embodiments of the invention, especially any "preferred" embodiments, are possible examples and are merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the spirit and principles of the invention. All such modifications are intended to be included herein within the scope of this disclosure and this invention protected by the following claims.

Claims (21)

A pharmacy system for automated transfer and processing of electronic drug orders between a healthcare facility and an associated computerized patient care system, said pharmacy system comprising:
A billing interface, the billing interface comprising:
receiving the electronic drug order for a drug to be prepared for intravenous administration to a patient;
transmitting billing information calculated based on the electronic drug order, wherein the billing information is used to bill for the drug corresponding to the electronic drug order. a configured billing interface;
a central computer communicatively connected to the billing interface, the central computer comprising:
processing the electronic drug order, processing the electronic drug order corresponding to the electronic drug order by electronically accessing at least one drug database or file using the electronic drug order; automatically identifying one or more ingredients required to prepare the medicament;
sending data indicative of the identified one or more ingredients associated with the preparation of the medication corresponding to the electronic medication order to a preparation location for preparing the medication. with a central computer and
A pharmacy system , wherein the billing interface is configured to receive the electronic drug orders from the central computer . The central computer is
receiving a message containing information related to administering the drug to the patient;
2. The pharmacy system of claim 1, configured to: transmit the electronic drug order to the billing interface in response to receiving the message. The central computer is communicatively connected to an autofill and package system for automatically preparing the drug based on the electronic drug order and the one or more ingredients. 2. The pharmacy system of claim 1, wherein the pharmacy system is configured to: 4. The method of claim 3, wherein the central computer includes a schedule generator, the schedule generator configured to append the electronic drug order to a schedule specifying predetermined times for preparing medication for a patient. Described pharmacy system. 5. The pharmacy of claim 4, wherein the autofill and package system uses the schedule to determine when to prepare the medication corresponding to the electronic medication order using the one or more ingredients. system. The central computer uses at least one of dependent amounts provided by the electronic drug order, flow rate, concentration of ingredients, amount of diluent, amount of drug, patient weight, and patient height. is configured to perform calculations for a complete parenteral nutrition drug order;
4. The pharmacy system of claim 3, wherein the automated fill and package system is configured to prepare the medication based in part on the complete parenteral nutrition medication order. The electronic drug order comprises at least one of a single dose infusion, an intermittent infusion, a continuous infusion, a sequence, a titration, a chemotherapeutic continuous infusion, a piggyback infusion, a bolus parenteral infusion, and a complete parenteral nutrition mix infusion. 2. The pharmacy system of claim 1, comprising information for said preparation. 3. The pharmacy system of Claim 1, wherein the central computer is communicatively connected to a bar code scanner. The central computer is configured to use information from the barcode scanner to identify barcodes of the one or more ingredients used to prepare the medication based on the electronic medication order. 9. The pharmacy system of claim 8 , wherein: 2. The pharmacy system of claim 1, wherein the central computer is configured to batch process the medications corresponding to the electronic medication orders among other medications identified by respective electronic medication orders. The central computer is communicatively connected to a memory storing a plurality of instructions for preparing different medications, and the central computer is configured to store instructions for preparing the medications corresponding to the electronic medication order. 2. The pharmacy system of claim 1, configured to select at least some of the orders from. 2. The central computer of claim 1, wherein the central computer is communicatively connected to a printer configured to print bar code labels for drug containers enclosing the drug corresponding to the electronic drug order. pharmacy system. The central computer is
managing an inventory of ingredients for preparing a medicament;
and updating the inventory based on using the one or more ingredients for the preparation of the medication corresponding to the electronic medication order. pharmacy system. 3. The pharmacy system of Claim 1, wherein the billing information is sent to a third party financial system. The electronic drug order includes (a) a dosage at a particular concentration of the drug, (b) an amount of the drug per unit of body weight, (c) a dosage of the drug per unit of body surface area, or ( d) specifying at least one of total dosage and total duration . 16. The pharmacy system of claim 15 , wherein the electronic drug order specifies the at least one of (a)-(d) over a specified period of time. the central computer to identify at least one of a concentration or amount of at least one of the ingredients based on the electronic drug order specifying the at least one of (a)-(d); 16. The pharmacy system of claim 15 , wherein the pharmacy system is configured to: A pharmacy system for automated transfer and processing of electronic drug orders between a healthcare facility and an associated computerized patient care system, said pharmacy system comprising:
A billing interface, the billing interface comprising:
receiving the electronic drug order for a drug to be prepared for intravenous administration to a patient;
generating billing information based on the electronic drug order;
and transmitting the billing information, wherein the billing information is used in billing for the medication corresponding to the electronic medication order. When,
a central computer communicatively connected to the billing interface, the central computer comprising:
electronically processing the electronic drug order, processing the electronic drug order corresponding to the electronic drug order by accessing at least one drug database or file using the electronic drug order; automatically identifying one or more ingredients required to prepare the medicament;
said identified one or more ingredients at a preparation location for preparing said medication using data indicative of said identified one or more ingredients associated with said preparation of said medication corresponding to said electronic medication order; and transmitting said data indicative of
receiving a message containing information related to administering the drug to the patient;
in response to receiving the message, sending the electronic drug order to the billing interface to generate the billing information used in billing for the drug. A pharmacy system comprising: a central computer; 19. The pharmacy system of Claim 18 , wherein the central computer is configured to automatically trigger the transmission of the electronic drug order to the billing interface in response to receiving the message. . 19. The central computer of claim 18 , wherein the central computer is configured to receive the message from at least one of an infusion pump, a medication administration server, or a pharmacy input device that provided the IV dose to the patient. pharmacy system. 19. The pharmacy system of Claim 18 , wherein the billing information is sent to a third party financial system.

Images