JP6991190B2 - Electronic drug order transfer and processing methods and equipment - Google Patents

Description

(Reference)
This application is by reference to: US Patent Application No. 10 / 040,887 (filed January 7, 2002); US Patent Application No. 10 / 040,908 (filed January 7, 2002, Publication No. US). -2003-0130624-A1 (Published July 10, 2003); US Patent Application No. 10 / 059,929 (filed January 29, 2002, Publication No. US-2003-0141981-A1 (July 2003) Published on 31st)); US Patent Application No. 10 / 135,180 (filed April 30, 2002); US Patent Application No. 10 / 424,553 (filed April 28, 2003); US Patent Application No. 10 / 659,760 (filed September 10, 2003); US Patent Application No. 10 / 749,101 (filed December 30, 2003); US Patent Application No. 10 / 749,102 (December 2003) 30th May); US Patent Application No. 10 / 748,762 (filed December 30, 2003); US Patent Application No. 10 / 748,750 (filed December 30, 2003); US Patent Application No. 10 / 748,749 (filed December 30, 2003); US Patent Application No. 10 / 749,099 (filed December 30, 2003); US Patent Application No. 10 / 748,593 (December 2003) US Patent Application No. 10 / 748,589 (filed December 30, 2003); US Provisional Patent Application No. 60 / 377,027 (filed April 30, 2002); US Provisional Patent Application No. 60 / 376,625 (filed April 30, 2002); US Provisional Patent Application No. 60 / 376,655 (filed April 30, 2002); US Provisional Patent Application No. 60 / 444,350 (Filing February 1, 2003); US provisional patent application No. 60 / 488,273 (filed July 18, 2003); US provisional patent application No. 60 / 528,106 (filed December 8, 2003) ); And the document of US Pat. No. 5,842,841 is explicitly incorporated and made part of this specification.

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

(Background of invention)
Patient medical systems generally include computer networks, medical devices for treating patients, and controls over the medical devices. Although patient medical systems have been improved by utilizing computer-controlled automation systems and methods, patient medical systems still rely heavily on manual data management processes when it comes to medical devices and control of medical devices. For example, in modern hospitals, nursing stations are generally connected to computer networks, but computer networks usually extend to hospital rooms. Computer networks provide opportunities for automated data management processes, including the operation and monitoring of medical devices at the Point of Care and the control of medical devices. Despite advances in this area, automated data management techniques have not been fully utilized for point-of-care applications due to the lack of more efficient systems and methods. As the reliance on automated technology increases, the need to provide users with the ability to determine the operating state of a system or subsystem increases.

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

Typically, the invention includes a system with a medication management module and a wireless remote device located within a medical facility. Dosing management modules are associated with devices for pharmacotherapy applications such as infusion pumps. The wireless remote device includes message display means such as a visual display or an audible alarm transmitted over a wireless communication link in response to the status information output generated by the medication management module. Wireless remote devices also include modules or applications that generate a timeout when the wireless communication link is lost.

Other systems, methods, features, and advantages of the present invention will be apparent or apparent to those of skill in the art in light of the following drawings and detailed description. All such additional systems, methods, features, and advantages contained herein are within the scope of the invention and are intended to be protected by the appended claims.

(A brief description of the drawing)
The present invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily standard, but rather the emphasis is on clearly explaining the principles of the invention. Throughout some of the drawings in the drawings, the same reference numbers indicate the corresponding parts.
It is a schematic display of the patient medical system. Patient medical systems include pharmacy computers, central systems, and digital assistants at treatment locations. FIG. 1 is a block diagram of a computer system representing a pharmacy computer, a central system, and / or a digital assistant of FIG. The system includes an injection system or a portion thereof. It is a schematic representation of the part of the patient medical system of FIG. It is a block diagram which shows the functional element of the patient medical system of FIG. FIG. 1 is an exemplary computer screen for performing various functions of the patient medical system of FIG. It is a block diagram which shows the functional element of the injection system of FIG. Functional elements include, among other things, block for infusion system parameter setting, infusion order creation, infusion order preparation, drug administration, infusion order modification, and messaging. It is a block diagram which shows the functional element for setting the injection system parameter of FIG. It is a block diagram which shows the functional element for making an injection order of FIG. It is a block diagram which shows the functional element for preparation of an injection order of FIG. It is a block diagram which shows the functional element for drug administration of FIG. FIG. 6 is a block diagram showing functional elements for injection order documentation, injection order modification, and messaging of FIG. It is a figure of the emergency notification system which shows communication. FIG. 3 is a diagram of an emergency notification interface from the perspective of a notifying party, showing preferred notification options provided by the emergency notification system to the notifying party. FIG. 3 is a diagram of an emergency notification interface from the perspective of a target party, showing preferred emergency information received by the target party. It is an embodiment of the flowchart of the alarm / alert escalation process. It is a figure of the alarm / alert interface screen. Another figure of the alarm / alert interface screen. Another figure of the alarm / alert interface screen. It is a figure of the interface screen seen from the clinician's handheld device. It is a figure of the interface screen of the login process. It is a figure of another interface screen of the login process of FIG. It is a figure of the department selection interface screen. It is a figure of the shift selection interface screen. It is a figure of the patient browsing interface screen. It is a figure of the patient selection interface screen. It is a figure of the patient information menu interface screen. It is a figure of the allergy / height / weight interface screen. It is a figure of the drug history interface screen. It is a figure of the inspection result interface screen. It is a figure of the drug delivery schedule interface screen. FIG. 26 is another diagram of the interface screen of the drug delivery schedule process of FIG . It is a figure of the interface screen of workflow injection stop. It is another figure of the interface screen of workflow injection stop. It is the figure of the interface screen of the workflow for restarting an injection. It is the figure of the interface screen of the workflow for restarting an injection . FIG. 26 is another diagram of the interface screen of the drug delivery schedule process of FIG. It is a figure of the dosing failure interface screen. It is another figure of the interface screen of FIG. It is another figure of the interface screen of FIG. It is a figure of the schedule interface screen. It is a figure of the drug interface screen. It is a figure of the scan interface screen. It is a figure of another scan interface screen. It is a figure of the drug administration interface screen. It is a figure of the route confirmation interface screen. It is a figure of the pump channel scan interface screen. It is a figure of another pump channel scan interface screen. It is a figure of the comparison interface screen. It is another figure of the comparison interface screen. It is another figure of the comparison interface screen. It is another figure of the comparison interface screen. It is another figure of the comparison interface screen. It is a figure of the pump state interface screen. It is a figure of the flow velocity history interface screen. It is a figure of the communication loss interface screen. It is a figure of the communication loss interface screen. It is a figure of a low battery interface screen. It is a figure of a hub. It is a diagram of various icons used on the interface screen. It is a figure of the implementation result recording interface screen. FIG. 6 is a diagram of a dosing order with a monitoring parameter link. It is a figure of the monitoring parameter input interface screen. It is a figure of the cycle count interface screen. It is a flowchart of an order comparison process. FIG. 6 is a schematic diagram of a flow control system in which microelectromechanical system (MEMS) elements are connected to a line set. FIG. 3 is a schematic block diagram of software components loaded onto the first central computer of FIG. It is a flowchart of an exemplary injection execution process. It is a flowchart of an exemplary injection execution process. It is a flowchart of an exemplary injection execution process. It is a flowchart of an exemplary channel scan process. It is a flowchart of an exemplary pump channel change process. It is a flowchart of an exemplary pump channel change process. It is a flowchart of another exemplary channel scan process. It is a flowchart of yet another exemplary channel scan process. It is a flowchart of an exemplary injection stop / stop process. It is a flowchart of an exemplary injection resumption process. It is a flowchart of an exemplary pump removal process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process.

(Detailed explanation)
Although the invention can be made into many different embodiments, preferred embodiments of the invention are shown in the drawings and are described in detail herein. The present disclosure should be viewed as an illustration of the principles of the invention and is not intended to limit a wide range of aspects of the invention to the exemplary embodiments.

FIG. 1 is a schematic representation of a patient medical system. In one embodiment, the patient medical system 100 includes a pharmacy computer 104, a central system 108, and a treatment site 106 linked by a network 102. As shown in FIG. 2, the patient medical system 100 also includes an infusion system 210, also referred to as a medical system. The infusion system 210 is preferably a computer program, particularly a module or application (ie, a program or group of programs designed for the end user) residing on one or more electronic calculators in the patient medical system 100. It is a medication system implemented as. As described in more detail herein, the infusion system 210 links clinicians such as doctors, pharmacists, and nurses in an interdisciplinary approach to patient care.

(General system)
To explain this by moving to FIG. 3, the patient medical system 100 can include a plurality of medical devices 120. In one embodiment, the medical device is an injection pump 120. In yet another embodiment, the medical device is a control device for an injection pump. For easy reference, the present disclosure, as a whole, identifies the medical device of the system as an infusion pump, but the entire system 100 can incorporate any one or more of the various medical devices. Is understood. Therefore, as shown in FIG. 3, the plurality of injection pumps 120 are connected to the hub or the interface 107. As described in more detail herein, the infusion pump 120 may be of conventional design in which each infusion pump 120 is associated with one patient. However, as will be appreciated by those skilled in the art, the infusion pump 120 shown in FIG. 3 need not be associated with the same patient or treatment location, even though the infusion pump is connected to the same hub 107. Further, each injection pump 120 may be a single channel pump or a multi-channel pump such as a 3-channel pump . Generally, the pump periodically transmits a message containing pump status information to the hub 107. To centralize communication for cost effectiveness and / or to allow redesign of existing medical devices that are not currently communicating with the central computer system 108, thereby allowing each such medical device to work with the central computer system 108. A separate hub 107 can be used away from the medical device 120 so that it can communicate.

(Communication hub for the entire system)
In one embodiment, the serial port or other I / O port of the injection pump 120 is connected to the hub 107 using a conventional non-wireless transmission medium 105 such as twisted pair wire, coaxial cable, fiber optic cable and the like. The hub 107 is preferably connectable to a plurality of injection pumps 120 or only one pump via a one-way serial communication link 105. The hub 107 receives a signal from the connected pump and reproduces the received signal. Specifically, the received signal from the pump 120 is converted by the hub 107 into a format suitable for transmission to the system network 102 via the wireless communication path or the wireless communication link 128 and the wired communication system 110. Generally, the hub 107 transmits pump data to the system network 102. The hub 107 can also filter the information received from the pump 120 to prevent duplicate messages. In addition, the hub 107 allows remote viewing of pump status information on the clinician 116's digital assistant 118. Generally, the hub 107 transmits pump data whenever the hub 107 is connected to the pump 120 and both the hub 107 and the pump 120 are powered on. As described in detail herein, the hub 107 also allows comparison with pump settings on the order of pharmacy input. In a preferred embodiment, the hub 107 is connected to a drip pole that supports the pump 120, or the hub 107 is incorporated within the infusion pump 120 to create the integrated medical / communication device identified above. ..

An embodiment of the hub 107 is shown in FIG. 47. In this embodiment, the hub 107 includes a pump port indicator 411, a radio signal loss indicator 413, a low battery indicator 415, an alert mute key 417, an on / off key indicator 419, and a charging indicator 421 for up to four pumps. The pump port indicator 411 serves as a status indicator for each of the pump ports of the hub 107. The indicator light indicates that the corresponding pump port is communicating normally with the network 102. However, if the indicator light is not lit, this indicates that the corresponding pump port is not connected to pump 120 or that the port is not communicating from pump 120 to network 102. The radio signal loss indicator 413 indicates that the hub 107 cannot communicate with the network 102 by radio link. If a radio signal loss occurs, each of the pump port indicators 411 will also be turned off, indicating that the hub 107 is not communicating with the network 102. In the event of a radio signal loss, the hub 107 will propagate this event to the system network 102, the central computer system 108, and the server 109, and ultimately to the clinician 116. The alert mute key 417 allows the clinician 116 to temporarily mute all audible alerts from the hub 107. Alternative embodiments of the communication hub include a single dedicated wireless module physically within the pump, or a separate module for reaching both the pump and the server using wireless communication.

Further, in an alternative embodiment, the hub 107 can optionally be incorporated within the infusion pump 120 to create an integrated medical / communication device. Combination hubs / medical devices will continue to work exactly the same with each other.

(Access point for the entire system)
As shown in FIG. 3, a plurality of access points 114 in a medical facility serve as an interface between a wireless communication path and a wired communication system. Preferably, if the system network 102 is unavailable, the hub 107 stores the signal received from the pump 120 and then, once the system network becomes available, transmits the converted signal to the system network 102. In a preferred embodiment, communication between the hub 107 and the access point 114 is unidirectional from the hub 107 to the access point 114 and finally to the network 102. Therefore, in the present embodiment, the injection pump 120 can transmit data to the network 102, but the network 102 cannot transmit data to the injection pump 120. However, also in the alternative embodiments disclosed herein, it can be seen that the communication between the hub 107 and the access point 114 is bidirectional. Thus, in these embodiments, data and other information can be transmitted from the network 102 to the injection pump 120. In either case, the information transmitted between the network 102 and the hub 107 is encoded for security reasons.

(Central system server / computer for the entire system)
With reference to FIGS. 1 and 3, the central system 108 may include one or more servers or computers. Although the present disclosure refers to servers 109, 108a as a whole, it can be seen that these components may be non-server computers. It is not always necessary, but preferably the central system 108 can include a first central server or central computer 109 and a second central server or central computer 108a. In one embodiment, a separate communication system 103 can be provided for communication between the first central server 109 and the second central server 108a. In a preferred embodiment, the separate communication system 103 is an isolated point-to-point wired communication Ethernet® network. Since the communication system 103 is an isolated point-to-point system connection, the data communicated between the two servers 109 and 108a is usually not encrypted. Normally, a communication system between two servers 109 and 108a enables bidirectional communication.

As described in detail herein, a first central server or computer 109 is a set of first functional features associated with a first database and data and functions associated with a medical device and user interface. Has. The medical device 120 and the user interface 118 usually communicate directly with the first central computer 109. Further, as described in detail herein, the second central server or central computer 108a has a second database and a second set of functional features. The first central computer 109 is encrypted connected to the second computer 108a, and the medical device 120 and the user interface 118 do not communicate directly with the second central computer 108a. The user interface 118 can receive data via the first central computer 109 from a second database associated with a second set of functional features of the second central computer 108a.

The second central server 108a and its software subsystem typically interface with the pharmacy system to provide information about drugs, patients and provide standard workflows for nurses and other clinicians. The second central server 108a also interfaces with the first central server 109 to provide information about the association between the patient, nurse, clinician, order, and digital assistant 118 and the clinician. Some of the other functions of the second central server 108a can 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 retained with specific information for each visit and usually includes demographic data, allergies, admission dates, discharge dates, initial diagnosis, hospital rooms, beds, etc. In addition, information about each of the prescription, planning, and administered drug is retained by the second central server 108a. The functionality of the patient management function also includes pre-rejection testing, drug-drug interaction testing, duplicate therapy testing, dosage testing and drug / disease contraindications.

Item management refers to information about each drug available within the facility. This information is managed and retained within the second central server 108a. Such information includes the name, strength, efficacy classification, manufacturer, etc. of the drug. In addition, the second central server 108a holds the drug inventory and the continuous inventory of other smart warehouse item contents in real time. The second central server 108a assists in renewal when the warehouse is replenished and when the dose is administered or disposed of.

Facility management refers to the information provided for the entire facility. This information is managed and retained within the second central server 108a of the system 210. This information includes physical collapse into the facility's buildings, floors, departments, rooms and beds, a list of programs and services offered and where they are offered, storage departments where drugs and supplies are stored and Includes identification of where they are intended to be supplied.

Messaging refers to the function of a second central server 108a that provides a communication link between the pharmacist and the clinician. The second central server 108a allows for standardization of doses and special dose instructions and automatically sends dose shortage notifications. Reporting and graphing refer to the effectiveness of several business and management reports that can be performed on demand or in a planned manner by an authorized user of System 210.

The second central server 108a also has various interfaces such as an ADT interface, an invoicing interface, an individual result interface, a document result interface, a prescription collection interface, a pharmacy order interface, a point of care medication management interface and an inventory interface. .. These interfaces will be described in more detail later, but a brief description will be given directly below. The ADT interface refers to a facility admission, transfer, and discharge system (ADT). This system also typically manipulates pre-hospitalization permits and outpatient enrollment. The individual result interface refers to the interface with the inspection result. Normally, the inspection result and the accompanying order are input to an external inspection information system, and the individual result interface or the inspection room interface in the HL7 engine transfers this data to the second central server 108a. Once the test results are stored in the second central server 108a, the user observes them from the handheld device 118, the computerized physician order entry (CPOE) system, and the main application of the second central computer 108a. be able to. Laboratory interfaces are available for at least four interfaces: radiation laboratory interface, microbiological laboratory interface, biochemical laboratory interface, and pathology laboratory interface. These interfaces can be configured to operate on four different ports or on the same port. The document result interface typically refers to a second central server 108a to receive radiological examination reports and pathological reports. The prescription collection interface can typically refer to a second central server 108a to receive notifications from the master file and synchronize drug files in the external system. The change in the prescription collection will trigger a transmission transaction from the server 108a to the external third party system. The pharmacy order interface allows the medication order to be sent to an external third party system. The inventory interface accepts changes in pharmacy inventory from external third party systems. Further, it is possible to use the cart collection point interface together with the system 100. The second central server 108a stores the order and drug file changes in the server database and then sends this information to any third party cart interface. The third party cart interface in the HL7 engine processes this information into HL7MFN 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 a third party cart server. The HL7 engine also receives HL7 format DFT messages from a third party cart server. The DFT message contains billing information for drug 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 burden and send the invoice to the patient. The invoice issuing interface refers to the interface with the patient burden software. The invoice issuing interface accommodates the optional use of the invoice issuing algorithm to calculate the burden. The billing interface handles internal transactions as well as external inbound transactions from third party systems. The invoice issuing interface will be the HL7 interface between the second central server 108a and the hospital's third party financial system. The invoiced amount can be sent directly, or the patient's burden can be calculated in the invoice issuing interface and sent to the hospital's third party financial system. Information is transmitted in real time via HL7 messages. The Point of Care Interface consists of a web service communication that integrates information about Point of Care Dosing Management with non-injection related data. These data are communicated in real time so that the user interface can integrate dosing management for infusion-related and non-injection-related agents.

Conversely, the first central server 109 has software loaded and configured to reciprocate between multiple hubs 107, multiple digital assistants or user interfaces 118, and to send and receive data with the second central server 108a. .. As described in detail below, the first central server 109 is capable of comparing, but not limited to, the prescription parameters received from the server 108a with the corresponding programmed pump settings received from the hub 107 system. A function to relay notifications and messages to the digital assistant 118, a function to relay alarm information and alert information received from the hub 107 system to the appropriate digital assistant 118, and an appropriate digital assistant to relay the pharmacy information and patient information communicated from the server 108a. Several functions can be performed, including the function of relaying to 118 and the function of aggregating pump status data and alarm monitoring data and periodically relaying this data to server 108a. If requested, the work performed by the server 109 shall comply with the 1996 (August 21) Act on Portability of Medical Insurance, Public Law 104-191. Normally, the data resident in the first central computer or server 109 is an intersection with the data resident in the second central computer or server 108a. Server 109 includes a subset of the data contained within server 108a that is required to perform its functionality. Server 109 also includes data related to system network 102, hub 107 and injection pump 120, which are required to perform their functionality. As described above, such data is typically the data required for the functionality or performance of the digital assistant 118 and the medical device 120.

In one embodiment, the cost-effective integration of the medical device 120 or other device and functionality with the hospital information system in the first and second central computers 109, 108a is the above-mentioned total, such as patient safety-related information. It is also brought about by separating a subset of the data and putting such information and functionality in the validated / validated parts of the system. In this context, in the context of FDA regulation, validated 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. In this embodiment, the validated portion of the system is located within the first central computer 109. In one embodiment, the subset can include alarms and / or alerts generated by the infusion pump and / or programming or operating parameter information for the medical device 120 / infusion pump 120 / controller 120. This subset is separated and placed in the validated part of the system in the first central computer 109, and the rest of all the data is in the validity of the system in the second central computer 108a. Is retained in the database of the unconfirmed part. The validated database located on the first central computer 109 and the unvalidated database located on the second central computer 108a will be better understood by those skilled in the art from the details described below. It is kept synchronously using web service replication. An alternative embodiment is functionality separated by both validated and unvalidated parts of the system residing on one computer and a software firewall (eg, operating system mechanism or other OTS software). Can be included. As described below, "synchronization" is performed periodically based on time intervals, other predetermined times, and / or as needed when important data changes such as patient enrollment status occur. be able to. At intervals, a fresh new copy of the duplicated data is sent to another central computer, and the validated first central computer 109 replaces its local copy with the new copy. If the important information changes, the change is immediately propagated to the validated first central computer 109 and treated as a change rather than a replacement of the existing information. Therefore, as will be understood from the details described herein, some or all of the subsets placed in the database of the first central computer 109 are also present in the second central computer 108a. This process is better understood with reference to the details described 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 third-party unvalidated systems and The time-effectiveness and cost-effectiveness of integration with each data and information in the system is improved.

In one embodiment, the first central computer 109 is a validated server, server such as Compaq DLG-380 with Windows® 2003 Server OS that runs Active Directory for user and device authentication. It can be equipped with a certification authority for issuing certificates and client certificates, a SQL server 2000 for temporary data storage, and an Internet information server (IIS) for application hosting (web services and web pages). The second central computer 108a is an external hospital information connected via a dedicated Ethernet® TCP / IP connection 103 to access a data replication web service exposed by a validated server at the other end of the dedicated connection. A server that has not been validated, such as a system (HIS) server, can be provided. Alternatively, the second central computer 108a comprises software that performs one or more of the various functions described herein as a whole, such as a pharmacy system and other systems. Can be done. Thus, the second central computer can be equipped with these types of functions and can have an interface with other systems such as an external hospital information system (HIS) server. The first central computer (ie, server 109) includes a database containing a data storage package, i.e. a first database. In one embodiment, the first database may be located outside or inside the first central computer 109, but as shown in FIG. 54, the user of application 5412 loaded on the first central computer. It is preferable that it is accessible only to. The data tables in the first database are used within the use cases described further herein. The data table preferably includes tables related to medical devices, digital assistants, hubs, patients, clinicians, prescriptions, titrations, comparative information, alarms, and escalations. In addition, the medical device table can include tables related to pumps, pump channels, pump subchannels. Further, the alarm table can include a table related to a hub alarm, a pump alarm, a channel alarm, an alarm history log, and the like.

In one embodiment, each table can contain a key and the data in the table responds to the key. For example, a key to a table for a pump channel information log can prove the identity of the pump channel log, and in response to that key, channel identification, pump rate, dosing regimen, dosage, residual quantity. , Table data on primary injection volume, etc. are provided. In addition, the tables can be linked. For example, a patient table with patient information can be linked to a clinician table, which clinician table can be linked to a digital assistant table.

The patient medical system 100 of FIG. 3 is a hub subsystem, a first central computer subsystem or a first central server subsystem, a medical equipment subsystem or a 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 the first central computer subsystem are discussed in more detail herein. With respect to the medical device subsystem, this subsystem includes one or more medical devices 120, such as an infusion device that allows delivery of a drug to a patient, with state and infusion information for each infusion device, respectively. It is preferably transmitted periodically from the communication port associated with the device.

Typically, the second central computer subsystem is a server 108a that interfaces with the pharmacy system and has computer hardware and computer software to provide information about drugs, patients and standard nurse workflows. The server 108a can also have various other applications discussed earlier herein, such as an interface to a hospital information system (HIS). The second central computer interfaces with the first central computer subsystem and provides the first central computer with information about the association between the patient, nurse, order, and personal digital assistant and the nurse or clinician. It is preferable to provide.

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. The first database can have a first set of functional features associated with the particular data in it. In one embodiment, this set of functional features has functions associated with the medical device and the user interface for the medical device. The medical device and user interface communicate directly and securely with a validated environment. An unvalidated environment has a second operating system with a set of applications and a second database. The second database can have a second set of functional features associated with the particular data in it. There is usually a logical separation between a validated environment and a non-validated environment. The user interface can receive data from the non-validated part of the database related to the second functional feature through the validated part of the system. In one embodiment, the validation part is separated from the non-validation part by a logical separation or firewall that can be implemented in the 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 can be placed on the first central computer 109 and the non-validation portion can be placed 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, the central validation part of the central computer resides in the first server, and the second non-validation part of the central computer is the second. Resident on the server of.

Preferably, as described in detail elsewhere herein, the personal digital assistant subsystem injects clinicians and nurses 116 (FIG. 1), including relaying their patients, alarm information and alert information. Includes one or more small portable devices 118 that provide remote information about the status of the patient and the results of the injection comparison. As discussed herein, the first central computer is operably connected to one or more personal digital assistants 118 in the PDA subsystem. In one embodiment, the personal digital assistant is a WINDOWS® CE. Based on NET, it is used as a terminal device for clinical homes. Specifically, as described in more detail herein, the personal digital assistant may operably connect to a first central computer via an encrypted PKI-authenticated wireless LAN (802.1x) connection. can.

The hub subsystem receives data from the medical device 120, transmits pump data to the first central computer subsystem 109, and detects conditions capable of achieving data communication with one or more hubs. It is preferable to include components such as one or more hubs 107 for the purpose.

As mentioned earlier, in one embodiment, the hub 107 in the hub subsystem interfaces with up to four injection devices 120 via a one-way serial communication link 105, where the injection device pumps state information. A message (ie, a packet of data) containing the above is periodically transmitted to the hub. Alternatively, the packet 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 the received information to reject duplicate messages, stores the received information, and then, in one embodiment, uses a built-in wireless network transceiver to pump information. Transfer to one central computer subsystem. In one embodiment, pump information is not transferred unless the data received from the medical device has changed.

A transceiver built into hub 107 routes outgoing information to a wireless access point 114, which in turn uses a Wired Ethernet® subsystem 110 to transfer outgoing information to a first central computer. Route to 109. This outgoing information preferably includes XML-encoded data formatted as a SOAP message specially designed to be received by a web service-type software interface.

As will be appreciated by those skilled in the art, the term "XML" refers to a system for organizing and tagging elements of a web document, and for XML, generating custom tags and between applications and systems or between systems. It can enable the definition, transmission, validation, and interpretation of data between subsystems. Further, as used herein, the term "web service" refers to the integration of SOAP with a web-based service using XML, and the term "SOAP" is used in the request and response messages of the web service. Refers to a messaging protocol used to encode information before transmitting it over a network or communication path.

The first central computer subsystem is loaded and configured to travel to and from the second central computer subsystem with multiple hubs 107, multiple digital assistants 118, and servers 108a to send and receive data. It is preferably composed of a server 109 having a software application.

To illustrate this by moving to FIG. 54, the server 109 is preferably COMPAQ DLG-380 with MICROSOFT WINDOWS® 2003 server operating system 5414. In one embodiment, the software component loaded in the storage of the first central computer 109 is: First central computer or server application 5412 in NET Framework 5416, Active Direction Domain Service 5418 for user and device authentication, SQL server 5420 for temporary data storage (shown as a database), and Internet Information Services 22 for application hosting. including. .. NET Framework 5416 is available from Microsoft. NET Framework 1.1 or higher is preferred. The .NET Framework connects the application 5412 of the first central computer to the operating system, the Internet Information Server 5422, the SQL database 5420, and the Active Directory Domain Service 5418 component. As will be appreciated by those of skill in the art, the Active Direction Domain Service 5418 provides services utilized by the Windows® server operating system 5414 and the application 5412 of the first central computer, a genuine and authorized hub subsystem. Helps ensure that only users of the second central computer subsystem and personal digital assistant subsystem can access the first central computer and thus the application 5412 of the first central computer.

In one embodiment, the first central computer (ie, server 109 in FIG. 3) has 1) the corresponding programmed pump settings received from the hub subsystem of the prescription parameters received from the second central computer subsystem. Comparison with and / or comparison with the pump program 2) Relay of alarm and alert information received from the hub subsystem to the appropriate personal digital assistant 118 (Fig. 3) 3) Appropriate personal digital assistant Providing historical information on pump status and flow velocity to 118, 4) relaying pharmacy information and patient information communicated from a second central computer 108a (FIG. 3) to the appropriate personal digital assistant 118, and 5 ) Perform several functions, including compiling pump monitoring data and alarm monitoring data and periodically relaying this data to a 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 "received interfaces" that receive received 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 a DatabaseRefreshListener receiving interface, a DatabaseRefreshLister transmitting interface, a RoutePDA receiving interface and a RoutePDA transmitting interface, and a PumpDataListener receiving interface.

In one embodiment, four of the external software component interfaces are divided into two pairs, two distinguishable bidirectionals between the first central computer 109 and the second central computer 108a in FIG. Create a communication channel. The first channel includes both a DatabaseRefreshLister receive interface and a DatabaseRefreshListener transmit interface, both paired together. Therefore, as used herein, the first channel is referred to as the "DataRefreshListener" and is utilized by the second central computer 108a and the data in its database table is located in the database table of the first central computer. It is periodically synchronized with the data.

Using the DatabaseRefreshListener channel, the second central computer 108a sends XML-encoded data formatted as a SOAP message to the web service-type interface of the first central computer, thereby transmitting the XML-encoded data of the first central computer to the database table of the first central computer. To update. Similarly, the second central computer 108a updates its own database table by sending an XML coding request for the data to the web service type interface of the first central computer, which interface then becomes the second. The central computer 109 of 1 is made to respond with XML-encoded data.

As mentioned above, the receive interface portion of the DatabaseRefreshListener channel is utilized by the second central computer for updating the database table located within the first central computer with data from the database table of the second central computer. Will be done. In addition, the outgoing portion of the DatabaseRefreshListener channel is utilized by the second central computer for updating its own database with data from the database table of the first central computer.

The DatabaseRefreshListener receiving interface preferably includes several web service methods named "RefreshXXX" that correspond to the type of data to which "XXX" is transferred. In one embodiment, these methods receive a received HTTP request message containing XML-encoded data formatted according to the SOAP protocol. XML-coded data is a structured structure that corresponds to a row in a database table. For example, the method "Refreshes" receives a data structure consisting of a pair of usernames and user passwords corresponding to a row in a database table that includes a username field and a user password field.

As shown in FIG. 54, the received message is the Internet Information.
Server and. It is routed through the .NET Framework component to the application 5412 loaded on the first central computer (ie, server 109 in FIG. 3). The application 5412 of the first central computer utilizes Active Directory Domain Service 5418 to verify that the message of the second central computer is authentic, process the contents, and then SQL the obtained data. Stored in server database component 5420.

Then, the application 5412 loaded on the first central computer ... It responds to the second central computer by issuing an HTTP response method that is routed to the second central computer via the .NET Framework component 5416 and the Internet information server component 5422. This response message indicates the success or failure of data transfer and processing.

The DatabaseRefreshListener reception 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. In addition, the DatabaseRefreshListener reception interface can also include a web method used by the second central computer to periodically send a signal that the second central computer is functioning to the first central computer. ..

In contrast to the DatabaseRefreshListener receive interface, the DatabaseRefreshListener outgoing interface is utilized by the second central computer to update its own database with data from the database table of the first central computer. To ensure that the data was captured by the second central computer before it was permanently removed from the first central computer, the DatabaseRefreshListener outgoing interface uses a multi-step approach for data transfer, such as: .. 1) The second central computer checks the availability of the data 2) The second central computer requires the first central computer to send the data 3) The second central computer has the data Confirm that the data has been received 4) The 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 format "BeginGetXXXToArchive", which corresponds to the type of data for which "XXX" is required. For example, the method "BeginGetChannelDataToArchive" requests the availability of a time stamped pump channel record received from a pump by a first central computer via a hub subsystem.

The request message is Internet Information Services Component 5422 and. It is passed to the application loaded in the first central computer via the .NET Framework component 5416. The application 5412 loaded in the first central computer decodes the XML contained in the request message to determine what data is requested by the second central computer.

The application 5412 loaded in the first central computer checks the availability of the requested data in the SQL server database 5420. If the data is available, the application prepares an XML-coded response message indicating that the data is available. If the data cannot be retrieved, application 5412 prepares an XML-coded response message indicating that the data is unavailable.

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

If the data is available, the second central computer initiates the 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 "EndGetXXXToArcriv", where "XXX" is the same as that used above.

The application 5412 in the first central computer decodes the XML contained in the request message, determines what data should be returned to the second central computer, and transfers the data by the corresponding receiving interface. Place it in the appropriate XML-encoded response message configured in a format that corresponds to a row in the database table that matches the technique used.

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

If the data is 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 that 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 it should be sent to the second central computer for archiving. Issue a response message informing you that the data has been marked.

Second Central Computer In order to signal the success or failure of data storage in the 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", which is the same as that used above by "XXX".

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

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

The DatabaseRefreshListener outbound 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.

The second bidirectional channel between the first central computer 109 and the second central computer 108a is referred to herein as "Route PDA" and is both a paired Route PDA receiving interface and a Route PDA outgoing interface. 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 to receive the corresponding HTTP response message from the second central computer. , If applicable, then route back to the source personal digital assistant 118.

In the second channel (ie, RoutePDA), the message received from the personal digital assistant 118 or transmitted to the personal digital assistant 118 is a wired Ethernet® system 110 of a hospital or medical facility, a wireless access point 114, and each personal. It is preferably transmitted back and forth between the first central computer 109 via a wireless transceiver built into 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 109. The second central computer 108a then issues an HTTP response message containing information in XML format or information in HTML format. The HTML-formatted response message is routed to the personal digital assistant 118 through the first central computer 109 without further processing.

The XML-formatted response message 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 result page or a pump monitoring page. Used by a second central computer 108a. 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 transmitting personal digital assistant 118.

As mentioned above, the Route PDA channel routes the HTTP request message received from the PDA 118 to the second central computer, then receives the corresponding HTTP response replied by the second central computer and processes it, if applicable. And then used by the first central computer to route back to the transmitting PDA.

Therefore, the Route PDA receiving interface is used to communicate with the web browser located in the PDA 118. This interface receives incoming HTTP request messages containing data encoded as a name-value pair that matches the HTTP "GET" protocol and the HTTP "POST" protocol. Incoming messages are from Internet Information Services and. It is routed to the application 5412 loaded on the first central computer via the .NET Framework component. The application 5412 loaded on the first central computer is as discussed below. Incoming messages are routed to a second central computer using the NET Framework 5416 and RoutePDA outgoing interfaces.

When the HTTP response is received on the RoutePDA outgoing interface, the application 5412 loaded on the first central computer determines whether the response is in HTML format or XML format. The HTML-formatted response is unprocessed by the first central computer. It is routed to the PDA via the .NET Framework component 5416 and the Internet Information Services component 5422.

However, the XML-formatted response is to send a 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 result page or a pump monitoring page. Used by the central computer 108a of. The first central computer examines the XML response from the second central computer and processes it appropriately. HTML or XML format responses are issued to the appropriate PDA via the .NET Framework and Internet Information Services components. The RoutePDA interface is preferably essentially synchronous due to the inherent synchronization behavior of the web browser contained within the PDA.

In contrast to the Routing PDA receiving interface, the Routing PDA outgoing interface processes the HTTP request message received from the personal digital assistant subsystem by the application 5412 loaded on the first central computer to the second central computer. Used to route and then receive the corresponding HTTP response sent by the second central computer as a reply.

In both the Database Refresh Listener 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 to this purpose.

As mentioned above, in using the DatabaseReffreshListener channel, the first central computer publishes a dedicated web service on the dedicated link 103, and the dedicated web service is used and newly updated by the second central computer. 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, the data is provided from the second central computer to the first central computer.

In addition, in utilizing the RoutePDA channel at the end of the terminal device of the clinician, the first central computer 109 provides an HTTP-style web page and maintains a certified web session with the PDA device 118 NET IIS. Publish the Server interface. In other words, the clinician's terminal device (ie, the personal digital assistant 118) receives the authenticated web page from the first central computer 109.

At the first central computer side 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 the HTTP request from the PDA as it is being received by one central computer, mimicking a web browser for a second central computer. In other words, the first central computer relays requests requiring unvalidation to the second central computer through a dedicated connection 103 to the second central computer.

Therefore, when the information flows between the PDA 118 and the server system, the information or combination information transmitted from the second central computer side needs to be present, and the second central computer sends the XML SOAP packet to the second. Notifying the web service published on the dedicated link 103 by the central computer of 1, the first central computer uses XML data and performs a combination operation with the information transmitted from the first central computer side of the system. Is executed, the obtained result is converted into XML, and the HTML is then returned to the clinician's PDA device 118.

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

The PumpDataListener reception interface is used for receiving data from the hub subsystem. This interface preferably includes 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. XML-encoded data is organized in a hierarchical form so that data from several pumps and several channels at various different times can be combined into a single large message structure. To.

Incoming messages are from Internet Information Services and. It is routed through the .NET Framework component to the application 5412 loaded within the application of the first central computer. The application of the first central computer uses the Active Directory Domain Service component to verify that the message of the hub subsystem is authentic. The first central computer then processes the content and stores the resulting data in a SQL Server Database component. Finally, the application of the first central computer is. It issues an HTTP response message to the sending hub device via the .NET Framework and Internet Information Server components. This response message indicates the success or failure of data transfer and processing.

Data packets received from the hub 107 by the first central computer (ie, the server 109) are preferably stored in the 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. Often, or alternatively, the information is distributed when the first central computer enters the event into the database of the first central computer and is later requested by the appropriate clinician via its digital assistant. You may. As mentioned earlier, the first central computer 109 keeps a log of all clinicians logged on to its digital assistant 118, which is authenticated each time the clinician logs on to the system.

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

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

Communication between the central system 108 and the digital assistant 118 is preferably bidirectional. In addition, the digital assistant 118 has sufficient memory to store and execute modules or applications (not shown) for testing the integrity of the communication link between the digital assistant and the central system 108 or the wireless access point 114. It is also desirable to include processing power.

Although not necessarily so, the modules or applications deployed on Digital Assistant 118 can be run with or without clinician intervention, at high levels such as JAVA®. It is preferably a script or other computer instruction (ie, software code) written in the programming language of. The script can be automatically downloaded from the server 108a or 109 to the digital assistant 118 or the medical device 120 as a receiving function of the system. For example, one type of script that can be automatically downloaded from the server to the digital assistant periodically polls or monitors communications, including notifications and messaging, from the central system 108 or access point 114. This is a script that tests the integrity of communication links. In a preferred embodiment, the 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, it indicates that the module or application installed on the digital assistant 118 has generated a timeout, which has lost communication with the central system 108. Notification to the audible sound and / or display device 118a is provided. The notification on the display device 118a can be, for example, the activation of an information pop-up window notifying that the communication link is lost, or the change of the active icon display on the display device 118a. A timeout used herein and understood by one of ordinary skill in the art is an output produced by a module or application that indicates that the module or application has waited for input for some time but did not receive it. Is. Another type of script can be polled to determine if an alarm or alert has been triggered. Many other scripts can be executed at the same time. One advantage of running scripts downloaded from the system to the Digital Assistant is that there is no need to install custom code on each Digital Assistant 118. If any event (ie, message, notification, alarm, alert, etc.) is present, Digital Assistant 118 will automatically retrieve the event from the server and display it on the interface screen of Digital Assistant 118. Other additional advantages of this scripting approach are 1) the script code can be easily updated on the central server without requiring each digital assistant to update, 2) the functionality depends on the hardware. The script can be validated / validated relatively independently of the Digital Assistant's hardware platform because it does not, and therefore changes or upgrades to the Digital Assistant have very little impact on the behavior of the script. It is a point.

As mentioned earlier, 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 having a dedicated frame for displaying events. .. The dedicated frame can insert a JAVA® script for displaying events, which is the first central computer for new events such as pump alarms and pump alerts directed to 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 dedicated frame for displaying such events.

One type of notification provided on the Digital Assistant 118 informs 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, the digital assistant 118 can also be notified to provide real-time access to alerts or alarms when the digital assistant 118 is linked to the central system 108.

Other notifications normally communicated via script include, but are not limited to, pump "silence stop", pump injection limit changes, injection termination, blockage trend information, low battery, pre-blockage indicator, Overuse of bolus, alert to keep veins open, rapid medication notification, order correction, test results, radiodiagnosis results, updates, change of remote measurement data and / or vital sign information, attempt to contact nurse Includes doctors or pharmacies, patients seeking nurses, loss of communication, messages from other devices, new speeds for medical devices based on critical information, subsequent purge speeds, etc.

As mentioned earlier, clinicians in medical facilities can use a remote radio device 118 (ie, also known as a personal digital assistant (PDA) 118), or a tablet computer with an operably mounted bar code reader, or drip. Infusion alerts, via other computer devices wirelessly or wiredly connected to network 108, such as a laptop computer mounted on a pole with a bar code reader operably mounted on the computer. Access alarms and messages.

The infusion system 210 preferably provides clinicians and other users with the option of automating alert event driven messages. In addition, healthcare facility managers and other users can customize the type of automated messaging that appears via the remote radio device by message type or classification, anomaly severity, and time-based alerts. In addition, the infusion system provides clinicians and other users with the ability to set audible messages, visual messages, or both.

The messaging provided by the injection system 210 preferably includes a user-configurable rule engine, scheduler, and interface for connecting to the injection pump system. In addition, result-driven messaging should provide clinicians with real-time decision-making assistance in point of care via workstations, electronic tablets, wireless personal digital assistants, and the like.

Communication between the infusion pump 120 and the network 102, and also between the network 102 and the clinician's digital device 118, is in particular the pump setting in which the clinician 116 is programmed with the pharmacy input order compared by electronic means. Use this system as a method of comparative observation and / or programming of the pump and remote observation of pump alerts and alarms, remotely observing the pump status, viewing notifications, and viewing the change history of injection settings. Make it possible.

(Patient medical system)
Returning to FIG. 1, the patient medical system 100 preferably includes a computerized physician order entry module (CPOE), a ward pharmacy module, a wireless nurse clinical recording system, and an electronic patient chart module. In one embodiment, such a system and module is an application of a second central server or second central computer 108a. It is desirable that the patient medical system 100 provide a comprehensive patient safety solution for drug delivery. Within the patient medical system 100 is a software module that links existing patient medical systems together using an interface such as the HL7 interface known to those of skill in the art. The patient medical system 100 preferably operates on various computers and personal digital assistant products to transmit orders, update patient charts, and access alerts, alarms and messages.

The Computerized Physician Order Entry Module allows physicians to enter drug orders and access alerts, alarms, messages, alerts, vital signs and results. The pharmacy module checks the prescribed drug for documented patient allergies and for compatibility with other drugs and foods. The pharmacy module also provides real-time data for warehouse management. The Nurse Dosing Record Module is readily available at the patient's bedside and thus provides clinical information that guarantees drug and dose validation at the Point of Care.

The patient medical system 100 integrates the drug delivery product with the information needed to help ensure the safe and effective delivery of the drug. The clinical decision support and accompanying alerts, alarms, warnings, and messaging of the patient healthcare system 100 provide a safety net of support to the clinician as he manages the patient under increasing time and cost pressure. This information is preferably provided through a wireless network that provides data in a way that improves the clinician's workflow and makes it easier to perform treatment.

(Overview of injection system)
The infusion system 210, or medical system 210, within the patient medical system 100 provides computerized prescription and electronic medical records (eMAR), among other things. The infusion system 210 facilitates clinical recording, medication history management, inventory tracking, and messaging for clinicians. The patient medical system 100 combines barcoding and real-time technology to help ensure that the right patient receives the right drug and the right amount at the right time and over the right route. The infusion system 210 provides alerts, alarms, messages, and alerts such as, but not limited to, test 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 more detail herein, the infusion system 210 may be, at least in part, one or more such as a wireless remote personal digital assistant, workstation, physician order entry module, electronic tablet, processor controlled infusion pump and the like. Resident on more electronic calculators. The infusion system 210 can be configured to display alerts and alarms that can be set by a number of hospitals in various formats via one or more electronic calculators. In one embodiment, it provides time-based alerts to remind clinicians to perform patient management functions such as, but not necessarily limited to, infusion rate changes. In addition, it provides, but is not limited to, emergency alarms such as infusion disruptions. Furthermore, it provides less urgent messages such as, but not limited to, completion of infusion or closure of the line. In addition, the injection status can be viewed from anywhere in the medical facility via one or more wireless remote personal digital assistants or other electronic calculators.

As will be disclosed in more detail later, the system 210 will escalate the alarm or alert and will not indicate that the alarm or alert has been modified within a predetermined time period. The conditions that can trigger the escalation of an alarm or alert are preferably defined by the medical facility. Similarly, the time it takes for an alarm or alert to escalate can be defined by the medical facility. Therefore, a predefined alarm or alert that is not corrected by the clinician within a given time will result in an escalation of the associated alarm or alert. Therefore, it is preferable that the frequency with which the clinic is notified of an increase in alarms or alerts, which can be the volume of the associated audible sound, is increased.

As will be appreciated by those skilled in the art, the infusion system 210 assists in ensuring patient safety by checking the infusions made by the patient's order. As described in more detail herein, a barcoding method is used in which the infusion bag and patient ID are scanned. The infusion information is displayed on both the electronic calculator and the pump to help ensure that the correct infusion is given to the correct patient at the correct time, with the correct route and at the correct rate. In one embodiment, audible and visible alerts appear on the electronic device if the "rights" of the above-mentioned administrations do not match. In addition, if the clinician has set the infusion pump rate, if the programmed setting does not match the patient's infusion order, audible alerts and audible alerts on the electronic calculator through a comparison step described in more detail later. A visible alert appears. Further, at any given time, the clinician can check the setting value of the injection pump via an electronic device to see if the setting value matches the injection order contained in the central database 108b.

In one embodiment, the injection system 210 provides alerts and alarms with various tones or phrases via one or more electronic calculators, etc., for rapid identification of message severity or urgency. offer. Traditional infusion pump alerts and alarms are displayed, but not necessarily limited, on electronic calculators such as personal digital assistants to maintain infusion status reports to clinicians for all patients in charge. It is desirable to be able to save time to solve problems and improve workflow security.

In particular, it is preferred that all alarms and alerts be retrieved from the central system database for reporting purposes. Retrievable data can assist healthcare facilities in investigating and analyzing the number of times alarms, alerts and warnings have avoided mismedication.

Hearable alerts and alarms should be set to emit different sounds depending on the severity or urgency associated with the message or problem. Alarms that require first aid make a different sound than less urgent alerts. It is preferred that the visual text describing the problem be displayed by one or more electronic calculators. In one embodiment, an alert is sounded on the personal digital assistant when the infusion is nearing or is nearing completion. The personal digital assistant also displays the patient, location, type of infusion, and time remaining until the infusion bag is empty. The clinician can always access the infusion condition via a personal digital assistant and thus respond accordingly. In one embodiment, prior to visiting the hospital room, the clinician can view the injection status on a personal digital assistant and determine if another bag will be needed in the near future. If another infusion bag is needed, the clinician will save time by bringing a new bag on the first visit, rather than recognizing that a new bag is needed after arriving in the hospital room. be able to. Similarly, the pharmacy can observe the condition, including the remaining time, to plan the mixing and delivery of the next infusion bag.

If desired, and as will be appreciated by those of skill in the art, other alarms and alerts associated with the infusion pump may be made available on the electronic calculator at a location remote from the infusion pump. Patient information can be displayed on the electronic calculator, thus saving nursing time and steps to solve the problem. As mentioned above, if the pump is in an alarm or alert state, the clinician will be able to use the patient information, drug order, etc. on the personal digital assistant before going to the room to physically correct the alarm or alert state. You can view alarm messages or alert messages and collect the items you need.

In one embodiment, the infusion system 210 provides a configurable time-based alert to signal the clinician about a planned infusion order. Thus, with a tapering order to operate the NS at 200 ml / hour for 2 hours and then at 50 ml / hour, the infusion system 210 informs the nurse to slow down 2 hours after the start of infusion. In addition, it provides a post-alert to notify the clinician when the planned injection exceeds the time tolerance set by the facility. In addition, it produces time-based protocols such as alerts for assessing pain, such as after the initiation of epidural morphine infusion.

A configurable embodiment of the injection system 210 also includes an audible alert issued by an electronic computing device such as a personal digital assistant. It is preferable that the audible alert can be set by the medical facility within a specific department of the medical facility in order to satisfy the unique environment in the medical facility.

As mentioned above, a plurality of 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 messages. Colors, flashes, and bold text are desirable as display messaging options. In addition, hyperlinks can be provided when the message is generated. An icon can also be used on the display, and the emergency message can be set to interrupt the handheld electronic device or the like and immediately notify the clinician. In addition, alarm / alert escalation is provided by system 210. Alarms / alerts and their escalations will be described in detail later.

Again, as mentioned earlier, the infusion system 210 allows the clinician to observe all infusions or the patient in charge on an electronic computing device such as a personal digital assistant and thus move back and forth between the hospital rooms. It makes it possible to reduce the time spent on. In addition, prescription information is displayed on the electronic calculator for verification of drug amount, diluent, dose, and infusion rate. In addition, it is possible to see the real-time status of the infusion and display the duration of the infusion, the infusion amount, the remaining time, and the uninjected amount, such as the number of milliliters per hour. As mentioned earlier, the infusion state and flow velocity history can be viewed from anywhere in the medical facility via the electronic calculator.

As described in more detail herein, the infusion system 210 can calculate the dose 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 be performed at a dose other than the ordered dose. In addition, pediatric dose administration is available and is set up in the pediatric department within the medical facility.

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

If desired, the infusion system 210 allows the medical facility to specify an infusion limit for the system to warn the clinician programming the infusion to perform outside the set range. The warning can be set so that the clinician either disables the warning or prohibits redesignation. As will be appreciated by those skilled in the art, prohibiting redesignation for a particular infusion can prevent the patient from being inadvertently overdose.

The infusion system 210 can also be prepared for display of reference information related to the needs of each specialized department within the medical facility. In addition to specialized department policies and procedures, drug information can be viewed on electronic devices such as personal digital assistants. Protocols and standard orders can be configured to serve messages based on the patient's condition. For example, in one embodiment, the heparin infusion protocol is configured 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 slide-based protocol.

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

As mentioned earlier, the new injection order can be configured to provide the clinician with a message informing them of the new order. Messages can be audible and visual, such as text, color alerts, flashing hyperlinks, icons, and the like. Rapid and abort orders can be set as high priority messages to distinguish them from non-urgent messages.

It is preferred that the medical facility generate and set the educational message. For example, in one embodiment, an infusion that requires a particular tube set (eg, non-PVC) will display a message that provides knowledge to the clinician. In yet another embodiment, for example, injections requiring central venous administration will display a warning not to inject into peripheral veins.

In one embodiment, a scheduling message is generated to remind the user that the next task is being completed and displayed on one or more electronic calculators. For example, in the case of tapering injection, an alert to change the injection speed at the scheduled time is sent to the electronic calculator. In addition, protocols with time-based alerts, such as blood transfusion protocols, can be configured.

Returning to FIG. 1 again, and as mentioned above, the patient medical system 100 allows the dosing order, dispensing, and administration to be performed at the patient's bedside. Physicians can use wireless handheld devices to order simple and complex prescriptions, intravenous therapy and total parenteral nutrition therapy (TPN). The infusion system 210 checks not only the correct dosage, but also drug-drug interactions and other possible errors. The infusion system 210 then transmits this data in real time to the patient medical facility or local pharmacy, hospital nursing department, home care department, and / or clinic.

Clinicians can access the chart database using a handheld device. In one embodiment, the clinician scans the barcoded dosage regimen and the patient's barcoded bracelet to confirm the correct dosage, dosage, and time to administer any drug. The infusion system 210 updates medical records and dosing records, thereby eliminating, if not all, time-consuming paperwork. Therefore, the injection system 210 can reduce costs and improve efficiency while saving lives to the maximum extent possible. The patient medical system 100 may include access-controlled portable and stationary dosing methods and warehouses, including electronic patient charts and prescriptions, complete dispensing from point of care to pharmacies, and provision of inventory management. can.

As mentioned earlier, FIG. 1 is a schematic representation of the patient medical system 100. The patient medical system 100 includes a pharmacy computer 104, a central system 108, and a clinic 106 linked by a network 102. In one embodiment, the pharmacy computer 104 includes a processing device 104a, a keyboard 104b, a video display 104c, a printer 104d, a barcode reader 104e, and a mouse 104f. Although not shown in FIG. 1, the patient medical system 100 includes hospital management, nursing room subsystems, clinical information subsystems, hospital information subsystems, admission / exit (ADT) subsystems, billing subsystems, and billing subsystems. / Or other subsystems generally included in conventional patient health systems can also be included. Such a system generally works with a second central server 108a.

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

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

In one embodiment, the clinician 116 uses the digital assistant 118 to communicate with the wired communication system 110 of the network 102 via the first wireless communication path 126 during the treatment of the patient 112. The injection pump 120 has a function of communicating with the wired communication system 110 via the second wireless communication path 128. The drug cart 132 also has a function of communicating via a wireless communication path (not shown in FIG. 1). The wireless transceiver 114 serves as an interface for the wired communication system 110. The wireless communication system portion of the network is, but is not limited to, IEEE 802.11b "Wireless Ethernet®", local area network, wireless local area network, network with tree topography, ring topography ( Technologies well known to those skilled in the art such as networks with ring topography, wireless internet access point systems, Ethernet®, internet, wireless communications, infrared rays, optical fibers, and telephones can be used. Although shown as a wireless communication system in FIG. 1, the communication path may be a wired communication path instead.

In the patient medical system 100, the physician can order the drug 124 for the patient 112. In one embodiment, the order can be initiated by the clinician 116 at the clinic 106. Physicians and / or clinicians 116 can order medication 124 for patient 112 using a computerized physician order entry system (CPOE), medication cart 132 or similar device. Those of skill in the art are familiar with traditional computerized physician order entry systems. Regardless of its name, clinician 116 can use a computerized physician order entry system. If it is efficient to administer the agent 124 through the infusion pump 120, the infusion order contains information for generating operating parameters for the infusion pump 120. The operating parameter is a set of information and / or instructions required to program the injection pump 120 to operate according to the injection order.

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

As will be appreciated by those of skill in the art, the infusion bag can also be premixed and a non-patient barcode identifying the drug 124 will be affixed to the bag. In addition, the infusion bag can be mixed at the pharmacy or in the field and is affixed to the bag with a drug 124 and, if desired, a patient-specific barcode specifying when the drug should be administered to the patient.

At the treatment site, the agent 124 can be mounted on the infusion pump 120 along with an intravenous (IV) line 130 running from the infusion pump 120 to the patient 112. The injection pump 120 can include a pumping unit 120a, a keypad 120b, a display 120c, an injection pump ID 120d, and an antenna 120e. The prior art injection pump may be equipped with a wireless adapter (not shown) to fully implement the system 100. The wireless adapter can have its own battery if necessary to avoid battery life reduction of the prior art injection pump. Wireless adapters can also use intelligent data management techniques such as storage exchange data management and data compression to minimize power consumption and network traffic. The wireless adapter may also include the ability to communicate with the digital assistant 118 even when the network 102 is not functioning.

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

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

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

A major concern in the industry is that the right drug is given to the right patient. Therefore, the infusion system 210 includes features to help ensure that the correct drug is administered to the correct patient in an efficient manner. The injection system 210 can be implemented within software, firmware, hardware, or a combination thereof. In one form, the injection system 210 is implemented in software as an executable program, a personal computer (PC; IBM-compatible PC, Apple compatible PC, etc.), personal digital assistant, workstation, minicomputer, or mainframe. It is performed by one or more special purpose digital computers such as personal computers or general purpose digital computers. FIG. 2 shows an example of a general-purpose computer on which the injection system 210 can be implemented. The infusion system 210 can, but is not limited to, reside in or be resident in any computer such as a pharmacy computer 104, a central system 108, a dosing cart 132, and a digital assistant 118. It can have various parts that are resident. Therefore, the computer 200 of FIG. 2 represents either a computer in which the injection system 210 is resident internally or partially resident.

As shown in FIG. 2, in general, in terms of hardware architecture, a computer 200 has one or more input / outputs (I / O) communicably connected via a processor 202, a storage device 204, and a local interface 208. O) Includes device 206 (peripheral device). The local interface 208 can be, for example, but not limited to, one or more buses or other wired or wireless connections known in the art. The local interface 208 can have additional elements such as a control device, a buffer (cache), a driver, a repeater, and a receiver, which are omitted for simplification to enable communication. In addition, the local interface can include addresses, controls, and / or data connections to allow proper communication between other computer components.

The processor 202 is a hardware device for executing software, particularly software stored in the storage device 204. Processor 202 is any custom or commercial 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 general device for executing software instructions. Examples of suitable commercially available microprocessors are: PA-RISC series microprocessors provided by Hewlett-Packard Company, 80x86 or Pentium® series microprocessors provided by Intel Corporation, PowerPC microprocessors provided by IBM, Sun Microsystems. , Inc. The Spark microprocessor provided by Motorola Corporation, or the 68xxx series microprocessor provided by Motorola Corporation. Processor 202 can also represent, but is not limited to, distributed processing architectures such as SQL, Smalltalk, APL, KLisp, Snobol, Developer 200, MUMPS / Magic.

The storage device 204 may be any of volatile memory elements (eg, random access memory (RAM such as DRAM, SRAM, SRAM, etc.)) and non-volatile memory elements (eg, ROM, hard drive, tape, CDROM, etc.). Can include one or a combination thereof. Further, the storage device 204 can incorporate electronic, magnetic, optical and / or other types of storage media. The storage device 204 can have a decentralized architecture in which the various components are located distant from each other but are still accessed by the processor 202.

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

The injection system 210 can be any other entity comprising a source program, an executable program (object code), a script, or a set of instructions to be executed. In the case of a source program, the program is translated via a compiler, assembler, interpreter, etc., which may or may not be included in storage 204 to operate properly in relation to O / S212. To. Further, the injection system 210 is (a) an object-oriented programming language with classes of data and methods, or (b) a procedural programming language with routines, subroutines, and / or functions, but is not limited to, for example. It can be written as C, C ++, Pascal, Basic, Fortran, Cobol, Perl, Java®, and Ada. In one embodiment, the system program 210 is written in C ++. In another embodiment, the injection system 210 is created using PowerBuilder. The I / O device 206 is an input device, but is not limited to, for example, a keyboard, a mouse, a scanner, a microphone, a touch screen, an interface for various medical devices, a barcode reader, a stylus, a laser reader, a high frequency device reader, and the like. Can be included. Further, the I / O device 206 can also include, but is not limited to, an output device, such as a printer, a bar code printer, a display, and the like. The I / O device 206 is a device that communicates as both an input device and an output device, for example, but is not limited to, a modulator / demodulator (modem; for accessing another device, system, or network). ), High frequency (RF) transceivers or other transceivers, telephone interfaces, bridges, routers, etc. may be further included.

If the computer 200 is a PC, workstation, personal digital assistant, etc., the software in the storage device 204 may further include a basic input / output system (BIOS) (not shown in FIG. 2). The BIOS is a set of basic software routines that initialize and test the hardware at boot time, start the O / S212, and assist in the transfer of data between hardware devices. The BIOS is stored in the 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 in the storage device 204, communicates data back and forth between the storage devices 204, and operates the computer 200 as a whole according to the software. Set to control. The injection system 210 and O / S 212, in whole or in part, generally the latter, are read by processor 202, probably buffered within processor 202, and then executed.

As shown in FIG. 2, when the injection system 210 is implemented in software, the program of the injection system 210 can be used by or in connection with any computer-related system or method of any computer-readable medium. Can be stored on. Computer-readable media as used herein are electronic, magnetic, optical, or other electronic, magnetic, optical, or otherwise capable of containing or storing computer programs for use by or in connection with computer-related systems or methods. It is a physical device or means. The injection system 210 retrieves an instruction from an instruction execution system, an instruction execution device, or an instruction execution device and can execute the instruction, such as a computer-based system, a system including a processor, or another system. It can be implemented by or in any computer-readable medium for use by or in connection with a system, instruction execution device, or instruction execution device. In the context of this document, "computer-readable medium" is used to store, communicate, propagate, or transport programs for use by or in connection with an instruction execution system, instruction execution device, or instruction execution device. It can be any means that can be done. Computer-readable media can be, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, devices, or propagation media. More specific examples (non-exhaustive lists) of computer-readable media include: Electrical connection with one or more wires (electronic), portable computer diskette (magnetic), random access memory (RAM) (electronic), read-only memory (ROM) (electronic), erasable program Possible ROM (EPROM, EEPROM, or flash memory) (electronic), optical fiber (optical), and portable compact disk read-only memory (CDROM) (optical). The program is captured by electronic means, for example via optical scanning of paper or other medium, and if necessary, then compiled, translated or otherwise processed in an appropriate manner and then stored in computer memory. It should be noted that the computer readable medium can be the paper on which the program is printed or even another suitable medium.

In another embodiment in which the injection system 210 is implemented in hardware, the injection system 210 can be implemented with any or a combination of the following techniques known in the art, respectively. Discrete logic circuits with logic gates for executing logic functions on data signals, application-specific integrated circuits (ASICs) with appropriate combination 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. 3-11 is one or more executions to perform a particular logical function or step in the process. Represents a module, segment, or part of hardware, software, etc. that can contain possible instructions, and is shown in the figure, including in substantially parallel or reverse order, depending on the functionality involved. Alternatively, alternative implementations that can execute the functions in an order that deviates from those described are included within the scope of the embodiments of the present invention.

(Components of patient medical system)
FIG. 4 is a first block diagram showing the functional elements of the patient medical system 100 of FIG. As shown in FIG. 4, the patient medical system 100 can be implemented as a modular system in which the module represents various functions of the patient medical system 100 including the infusion system 210 (FIG. 2). The flexibility of the patient medical system 100 and the infusion system can be enhanced if the system is implemented as a modular system. The module of the infusion system 210 (FIG. 2) can be included in various parts of the patient medical system 100. In one embodiment, the functional components of the patient medical system 100 can include, among other things, a medication management module 302, a prescription creation module 304, a prescription activation module 306, and a prescription authentication module 308.

The dosing management module 302 can align the functions of other modules of the patient medical system 100 included in the management of medical therapy. The dosing management module 302 coordinates with other parts of the patient medical system 100 as a whole. The dosing management module 302 operates and / or interfaces with the CPOE, operates and / or communicates with them in the point of care module, and operates and / or communicates with them in the medical therapy comparison module. Can include submodules. FIG. 4 shows an entrance / exit transfer (ADT) interface 310, an invoice issuing interface 312, a laboratory interface 314, and a pharmacy interface 316. The ADT interface 310 is used to capture information such as patient demographic data, size, weight, and allergies. In a preferred embodiment, the ADT system uses an HL7 type interface to transfer events input to the hospital's ADT system into a second central computer 108a. HL7 is a protocol for formatting, transmitting and receiving data in a medical environment. It provides interoperability between medical information systems through messaging standards that allow heterogeneous medical applications, such as a variety of different third-party applications, to exchange clinical and management data keysets. Typically, in the system 100 of the present invention, the HL7 ADT interface consists of three applications: an HL7 ADT server, an HL7 ADT client, and an HL7 ADT viewer. The pharmacy interface 316 imports orders from pharmacies. The pharmacy interface 316 can be an HL7 type interface, and the HL7 type interface interfaces with another system and inputs an order such as CPOE. This feature reduces the need to enter data into the patient medical 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. The web service interface can make near real-time coordination between point-of-care dosing management systems that support oral drug administration, such as McKesson AdaminRx, Pyxis, Verif5, and infusion pump-related dosing management. Various other interfaces are also known to those of skill in the art, but are not shown in FIG.

The medication management module 302 has additional features such as adverse reactions due to drug-to-drug incompatibility, double drug administration, drug allergies, drug dose limits, drug dosing frequency limits, drug dosing duration limits, and the ability to check for contraindications due to drug-induced diseases. Can have. The interaction of food and alcohol can also be noted. Drug restrictions may include, but are not limited to, restrictions such as adults, children, infants, newborns, preterm births, the elderly, age classification, weight classification, height classification, and restrictions related to body surface area. can. In one embodiment, the medication management module 302 prevents input of the same prescription to the same patient from two different prescription sources within the patient medical system 100.

The dosing management module 302 can also include the function of producing a report. The report includes, but is not limited to, shift termination, titration information, patient event list, infusion history, pump operation history, pump position history, and pump maintenance history. The shift end report can include pump channel, start time, end time, primary infusion, piggyback infusion, drug, dose, rate, pump status, infusion volume, remaining amount, remaining time, and final completion. .. The infusion history report includes the drug and infusion volume.

The dosing management module 302 can include a medical device status database. The medical device status database contains data indicating the location of the medical device 332 within the patient medical system 100. The medical device status database can also include data indicating past operation of the medical device 332. The medical device status database may also include data indicating a maintenance schedule and / or history of the medical device 332.

The infusion prescription or infusion order is entered in prescription entry 324. Such orders can include, but are not limited to, prescriptions such as single dose, intermittent dose, continuous dose, sequential dose, titration, and alternate dose type. Infusion formulations can include complete parenteral nutritional mixtures (TPNs), chemotherapeutic continuous infusions, piggybacks, high volume parenteral medications, and other infusion formulations. The patient medical system 100 can function without an end date for the order. The patient medical system 100 uses a continuous schedule generator, which predicts a predetermined time and generates a mixing agent filling schedule for that time. The predetermined time can be set at the patient medical system 100 level, or at the subsystem level such as the clinical field level and the tissue level. The predetermined time can be adjusted by the clinician 116 who inputs the order. The schedule can be automatically extended as long as the order is active within the patient medical system 100.

The prescription creation module 304 creates a hard prescription and an electronic (E-copy) prescription. Hard prescriptions are usually made in three copies in a medical facility. The first hardcopy 318 is usually sent to the pharmacy, the second hardcopy 320 is usually kept for patient records, and the third hardcopy 322 is sent to the treatment site 106. The electronic prescription is transmitted to the medication management module 302.

The prescription creation module 304 can include a function for confirming operating parameters. The operating parameters can be based on information from the formulation entry module 324. The prescription preparation 304 can be performed, but is not limited to, in any of the patient medical systems 100 such as a pharmacy, a treatment place 106, and a nursing center.

A computerized physician order entry (CPOE) system or the like can be used to perform some or all functions of the prescription making module 304. Clinician 116 can enter data in a variety of ways, including, but not limited to, tablet wireless computers, personal digital assistants, treatment carts 132, and workstations. The dosing management module 302 can interface with more than one prescription generation module 304. The dosing management module can receive orders from anywhere within the patient medical system 100.

The pharmacy computer 104 can access the electronic copy from the medication management module 302. The prescription activation module 306 is a computer-aided system that coordinates prescription entry and labeling. Prescription entry and generation or placement of drug 124 from inventory is processed by the prescription activation module 306. In one embodiment, the entry step creates the drug label 124a, as opposed to the prescription activation step.

The patient medical system 100 can bypass the prescription activation module 306. This can be done if the ordering clinician 116, such as the patient's physician, has the authority to immediately activate the order. If the order is activated immediately, the dosing management module 302 can go straight to the entry and thus prescription labeling module 326.

At block 326, the patient medical system 100 prints the drug label 124a. Prescriptions can be printed remotely and are often printed by a pharmacy printer 104d. After block 326, patient medical system 100 goes to block 328. At block 328, the drug label 124a is affixed to the drug 124. Usually, the pharmacist visually verifies that the drug label 124a matches the first hard copy 318 of the prescription 334. FIG. 4 shows that the visual verification 334 is also associated with the prescription authorization module 308. The drug 124 can then be transported from the pharmacy to the treatment site 106. A portable medical cart 132 can be used for some of the routes from the pharmacy to the treatment site 106.

The drug label 124a can contain information for preparing an infusion bag. If not created within the patient medical system 100, the drug label 124a can be provided by the bulk drug supplier. When provided by the bulk pharmaceutical supplier, the patient medical system 100 collects information from the drug label 124a. Further, the patient medical system 100 can add information such as a patient identifier to the drug label 124a.

The drug labeling module 328 arranges the drug label 124a on the drug 124. This can be achieved manually. This can also be achieved using an automated prescription filling and packaging system (not shown). When an automatic prescription filling / packaging system is used, the drug labeling module 328 provides data for matching the labeling of the drug 124 with the filling / packaging system.

At the treatment site 106, the clinician 116 confirms and administers the drug 124 to the patient 112 using a radio device 330 such as a digital assistant 118 and / or a medical cart 132. The radio device 330 communicates with the medication management module 302 via a communication path such as the first communication path 126.

The clinician 116 identifies himself by scanning the badge 116a, identifies the patient 112 by scanning the wristband 112a, identifies the drug 124 by scanning the drug label 124a, and scans the label 120d. Thereby identifying a medical device 332 such as an infusion pump 120. The clinician 116 can also identify himself by providing the fingerprint and / or password described above and shown in the login screen 1903 of FIG. The medical device 332 can be a medical device capable of bidirectional communication with the medication management module 302. Alternatively, the medical device 332 may only be able to provide information to the medication management module 302. The infusion system 210 assists the clinician 116 in delivering and validating 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 can visually verify and confirm that the third copy 322 and / or MAR is consistent with the labeled agent 124. The scanner 338 can be used to input machine-readable information from the third copy 322 to the wireless device 330 and the medical device 332.

The patient medical system 100 can make adjustments and changes to the infusion order. Among other modules that can include the function of injecting adjustment are the prescription entry module 324, the prescription activation module 306, the prescription permission module 308, and the prescription modification module 336. Clinician 116 accesses the prescription modification module 336 and adjusts the order. The clinician 116 can access the prescription modification module 336 from anywhere in the patient medical system 100. However, one very informative place for clinician 116 to access the prescription modification module 336 is the treatment place 106.

In the prescription authorization module 308, the patient medical system 100 determines whether the clinician 116 alone has the authority to modify the infusion order. The clinician 116 can be recognized by the patient medical system 100 as having the authority to modify certain parts of the order alone. If the clinician 116 does not have the authority to modify the order on its own, the pharmacist or physician may be requested to approve the modification entered by the clinician 116.

In one embodiment of the patient medical system 100, the order is entered into the pharmacy's computer 104. This order includes a first patient identifier and driving parameters. The pharmacy computer 104 creates a drug label 124a affixed to the drug bag or container. The drug 124 is delivered to the treatment site 106. At the treatment site 106, the clinician 116 reads the clinician 116 badge 116a, the patient wristband 112a, and the drug label 124a with the digital assistant 118. The digital assistant 118 reports whether the drug label 124a and the wristband 112a correspond to the same patient 112, based on the determination made by the central system 108. The system 100 then sends the drug identifier to the pharmacy computer 104. The pharmacy computer 104 confirms the drug label 124a, identifies the patient with the same order, and sends the operating parameters to the infusion pump. The operating parameters can be sent directly to the injection pump 120. The infusion pump is then programmed with operating parameters to administer the drug 124 to the patient 112.

FIG. 5 is an exemplary block diagram of a computer screen 400 useful to perform various functions of the injection system 210 (FIG. 2). In addition to other functions, the computer screen 400 can be used to enter a new injection order to modify an existing injection order and to stop the injection order. The computer screen 400 preferably includes a processing area 402, a search area 404, a drug information area 406, a titration / tapering reference area 408, an instruction / note area 410, and a predictive solution area 412. Injectable drug order types include single doses, intermittent doses, continuous doses, sequential doses, and alternate doses. The computer screen 400 can be used with a digital assistant 118, a pharmacy computer 104, an injection pump 120, a CPOE system, and a medical cart 132. The computer screen 400, as a whole, is designed to have a computer screen look and feel accessible to the clinician throughout the patient medical system 100 of FIG. Some of the functions of the computer screen 400 are achieved by, but not limited to, database linkage techniques well known to those of skill in the art, such as hyperlinks, definition boxes, and drop-down menus.

The processing area 402 includes functions for triggering the creation of an injection order, the storage of an injection order, the modification of an injection order, and the cancellation of an injection order. The clinician 116 can customize the computer screen 400 to provide the clinician 116 with preferred order entry procedures. The processing area 402 includes an order status indicator. The processing area 402 also includes an area to indicate whether the PRN order (“as requested” or “as needed” order) can be performed by the clinician 116. The processing area 402 includes medical device 332 operating parameters, injection order path, injection line, injection site, injection order disclosure time, injection drug order type, injection flow rate tolerance, injection flow rate, injection duration and preparation location (pharmacy or remote). It also includes the ability to display and adjust (such as position). The processing area 402 is also an area for linking a medical order to another medical order or related clinical monitoring, such as linking a physician's infusion order to another medical order entered by another clinician 116. Can also be included. The processing area 402 may include, but is not limited to, a trigger for displaying the data in another area of the computer screen 400, such as the predictive solution area 412.

The search area 404 makes it possible to search for drugs, solutions and / or additives for the infusion order. A default diluent can be set on the order. If a default dose for a drug is defined within the patient healthcare system 100, the default dose will automatically appear with search results that include the drug. As a result of the search from the search area 404, the name of the drug, the route of administration, the cost, the package size, the dosage form, the generic name, the presence or absence of anesthesia of the drug, the presence or absence of drug management, whether or not it is a drug collection, and the drug. The place of manufacture can be displayed.

The drug information region 406 can be used to determine additives and solutions for infusion orders. The drug information region 406 can include a separate additive region and solution region. The solution area can include a label, "solution / diluent". The patient medical system 100 can read data about the drug 124, the solution, and the additive into the drug information area 406 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 the drug 124 and solution combination.

The titration / tapering reference region 408 is typically applied to continuous infusion orders. Titration defines specific parameters of the order, such as dose and / or flow rate. Dosage and flow rate can be entered as absolute. Also, for inputting information in the titration / tapering reference area 408, a single mathematical symbol such as, but not limited to, a larger ">", a smaller "<", and an equal "="". Or it can be used in combination. Data can also be entered into the titration / tapering reference area 408 using a calendar. Dosage and flow rate can also be entered as tolerances. The titration / tapering reference region 408 can be hidden when entering and / or modifying the non-sustained injection order. Titration criteria include, but are not limited to, various test results, vital signs, the ability to orally ingest fluid, fluid inflows and outflows, and other parameter values related to the patient's health. Can include.

The instruction / note area 410 includes the function of storing information such as a physician note regarding the patient 112 and / or the infusion order. The instruction / note area 410 may include a display and reference area for identifying the clinician 116 responsible for the patient 112, such as the patient's physician.

The predictive solution area 412 displays the resolution schedule and related factors for the patient 112 based on the current status of the order being processed. The estimated time can be the default for the patient medical system 100. The time can also be adjusted by the clinician 116. The predictive solution region 412 can include an adjustable display showing the time predicted by the patient medical system 100. The data displayed in the predicted solution area 412 is usually stored in the processing area 402 when the order save is triggered. The predicted solution area 412 can include a function of looking back on a certain period while modifying the previously input order. This allows clinician 116 to consider solutions that may have already been prepared according to the unmodified injection order.

(Components of injection system)
FIG. 6 is a block diagram showing the functional elements of the injection system 210 of FIG. Functional elements include block 502 for setting system parameters, injection order creation block 504, injection order preparation block 506, drug administration block 512, injection order modification block 514, and messaging block 520. FIG. 6 also includes a pharmacy permit block 508, a doctor permit block 510, an order stop block 516, and an inventory / invoice issuance block 518. FIG. 6 presents one description of the injection system. However, FIG. 6 does not define a series of steps required to execute this injection system. One of the advantages of this infusion system is that the clinician 116 can access and enter information from both physical and functional locations within the patient healthcare system 100. For example, infusion orders can be generated by a physician using CPOE, by a pharmacist using a pharmacy computer 106, by a clinician 116 using a digital assistant 118, and by a clinician using a medical cart 132. Is. In addition, patient vitals, test results, and other records can be checked from multiple locations within the medical facility, including, for example, ward pharmacies. Therefore, the user in the ward pharmacy 104 (FIG. 1) can browse the ward in the medical facility from the computer processing device 104c. When the user selects a ward, a patient list is provided, and the user can select a patient and related records from the list and display them on the computer processing device. Alternatively, the user can enter all or part of the patient's name in the computer, which provides the computer-related records for the user's choice. .. The record is displayed as soon as you make a selection.

In one embodiment, FIG. 6 shows, first, a block 502 that prepares the patient medical system 100 to receive an infusion order-a block 502 that sets system parameters; second, a block that creates an infusion order-an infusion order creation block 504. Third, block to dispense based on injection order-dispensing block 506; fourth, block to allow injection order-pharmacy permission block and doctor permission block 508 and 510; fifth, block to perform injection order-drug administration Block 512; 6. Inventory and replenishment of inventory used for dispensing based on infusion order and invoicing the patient to the infusion order Block-Inventory and Invoicing Block 518; 7th , Block to modify infusion order-Modified block 514; and eighth, infusion order progress, infusion, to ensure that the correct drug is efficiently dispensed and delivered to the correct patient in the correct amount at the correct time. Can be seen as a block-message block 520 that sends messages to various personnel and subsystems with respect to messages and the like to support. The modification block 514 can include a block-order stop block 516 that stops the order based on the information provided by the transfer interface 310.

Block 502, which sets the system parameters, includes a functional block that prepares the injection system 210 to create and process the injection order. The block 502 for setting the system parameters is not limited, but the block 542 for setting the allowable value, the block 544 for setting the default value, the block 546 for constructing the database, and the block 548 for defining the function. Includes a block 550 that determines system settings. The block 502 for setting the system parameters will be further described below with reference to FIG.

The injection order creation block 504 includes a functional block used to create an injection order. The infusion order creation block 504 includes functions similar to those described with reference to the prescription creation block 304 (FIG. 4). The injection order creation block 504 includes, but is not limited to, a block 560 for inputting information, a calculation block 562, a check block 564, and an override block 566 . The injection order creation will be further described below with reference to FIG. The result of creating the injection order is the injection order 702 (FIG. 8). The injection order 702 typically includes an injection schedule 704 (FIG. 8).

The infusion order can request the permissions described with reference to block 308 (FIG. 4). In FIG. 6, the prescription permission by the pharmacist and the prescription permission by the doctor are considered separately in the pharmacy permission function block 508 and the doctor permission function block 510. Physician permission 510 may not be required if the infusion order is initiated by the physician. Infusion orders typically require a pharmacy permit 508 and a physician permit 510 if the order is created by a clinician other than a pharmacist or physician at the treatment site 106. However, if drug 124 is needed immediately, the infusion system 210 allows the administering clinician to bypass prescription permission 508 and physician permission 510. In the case of an emergency order or a non-emergency order for routine dosing, the infusion system 210 will not store in the patient medical system 100 any medical related information that the clinician 116 wants to give to the patient 112. It can be determined. If the infusion system 210 recognizes that the clinician 116 has the authority to initiate the desired medical care, the system 210 allows the medical care to be performed without going to blocks 508 and 510. This permission is then obtained with the following medications:

Preparation 506 based on the infusion order can be achieved in several locations throughout the medical facility, such as, but not limited to, pharmacies, nursing centers, floors, and treatment locations 106. Preparation 506 includes a step of giving an instruction to dispense the drug 124 and a step of minimizing the possibility of error in dispensing the drug.

Drug administration 512 is performed at treatment site 106. The injection system 210 is designed to carry out the order 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, over the right route, with the right pump settings. When an alert, alarm, reminder, or other message is appropriate to assist the clinician in drug administration, the dosing management module provides state information output to the messaging module 520. In response to the state information output, the messaging module 520 transfers the associated text message, audible display enable, or both to one or more electronic calculators.

As is known to those of skill in the art, injection orders are frequently modified. The injection system 210 executes the modification 514 and describes the injection order modification. Modification 514 includes modification of injection duration, flow rate, injection site, and stop order 516. The modification block 514 also includes the functional blocks required to perform the injection order modification.

The infusion system 210 can include a patient medical system wide 100 that defines a stop order 516. Changes in the patient's condition can generate a message 520 for appropriate action. The infusion system 210, in cooperation with the transfer interface 310, automatically stops the order upon discharge or death.

The system 100 includes an inventory / invoice issuing module 518. The inventory and invoice issuing module 518 allows financial transactions related to patient care to proceed with minimal human intervention. Completion of dosing management 512 can trigger invoice issuance to the patient via the invoice issuing interface 312. The invoice issuing interface can include an HL7 interface. If the patient is billed on the basis of the completion of invoice order preparation 506, the inventory and invoice issuing system 210 includes a credit bookkeeping process. The credit bookkeeping process can be triggered when the infusion bag is returned for disposal or re-registration with the pharmacy's warehouse management system.

The infusion system 210 includes a message module 520 for communicating with the entity of the entire patient medical system 100. Specifically, the message module 520 sends a text message, audible display enable, or both to one or more electronic calculators in the patient medical system 100. The message is transmitted in response to the status information output provided by the medication management module or other infusion system module within the patient medical system 100. The message is associated with the status information output and therefore provides appropriate alerts, alarms, reminders, or other messages to assist the clinician in dosing management.

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

The system can present the clinician 116 with a personal computer display view. The personal computer display provides a view summarizing the unresolved clinical problems of the clinician's patient. The clinician 116 can quickly retrieve detailed information about the patient. The system 100 can also generate e-mails or pages to Digital Assistant 118 or other communication devices in the event of certain serious patient conditions.

FIG. 6 also shows some communication channels that occur in the patient medical system 100. The highlighted communication channel is provided to facilitate the description of the injection system 210. When a person skilled in the art implements the patient medical system 100 on a network, various functional blocks communicate with each other via the highlighted route of FIG. 6 and an alternative route not shown in FIG. You can see that you can. Block 502, which sets the system parameters, has a function of communicating data related to the system parameters to the injection order creation block 504 via the route 522, and / or receives data from the injection order creation block 504, and how the received data is. Includes the ability to provide data to notify the injection order creation block 504 of whether it is related to system parameters.

The injection order can be passed directly to the injection dispensing block 506 via the route 524. The infusion order can also be passed to the pharmacy-licensed block 508 via route 526 and / or to the physician-approved block via route 528 before being sent to dispensing block 506. Route 530 emphasizes delivery of drug 124 from the dispensing area to the treatment site 106. Delivery can be achieved using the medication treatment cart 132. Routes 532, 534, 536, and 538 are not limited to inventory and invoicing 518 transactions, but various other functions such as invoice ordering 504, preparation 506, drug administration 512, and modification 514. Emphasizes that it can be tied to. Routes 572, 574, and 576 emphasize that a larger number of functions and actors included in the patient medical system 100 can generate and receive information via the message 520 block. Route 582 emphasizes that the pharmacist can generate and / or modify the system default value 544. Route 580 also emphasizes that various functional units throughout the system 100 can utilize information such as injection orders.

FIG. 7 is a block diagram showing the functional elements for the system parameter setting 502 of FIG. The system parameter setting 502 includes, but is not limited to, a tolerance setting 542, a default value setting 544, a database construction 546, a function definition 548, and a system setting value determination 550. The permissible range 542 is, but is not limited to, a net dosing permissible range 542a, a flow rate permissible range 542b, an administration time permissible range 542c, an administration system duration 542d, an administration duration permissible range 542e, a site change permissible range 542f, and the like. Includes tolerance. The infusion system 210 may also include an order entry and a separate tolerance for modifications from the ordered tolerance. Identifying distinct tolerances, such as, but not limited to, dosing system duration 542d, maximum infusion duration override availability setting in order entry, and maximum infusion duration override availability setting in dosing. Can be done.

The net dosing tolerance 542a is the maximum concentration of drug that is safe to administer to the patient at a given time. The infusion system 210 associates the net dosing tolerance with the drug. The net dosing tolerance 542a can be defined in the drug identification file in the drug database. During the injection order creation 504, the injection system 210 has a flow rate of 560e, the number of injection bags required at a particular time 562a, the concentration of the main component in each injection bag, the time each injection bag will be administered, each injection. The total amount of bags can be determined. The flow rate can be adjusted manually or by 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 time 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 message the dosing clinician. Send 520. The dosing clinician can obtain permission to override the net dosing tolerance 542a. The infusion system 210 can 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 the medication. The flow rate tolerance 542b is optionally defined for all tissue levels of the patient medical system 100. The tolerance 542b can be for the entire patient medical system 100 or for a subsystem of the patient medical system 100. For example, different flow rate tolerances 542b can be applied to, but not limited to, subsystems such as neonatal, pediatric, psychiatric, and specific nursing departments, and specific patients. The flow velocity tolerance range 542b can be specified for the initially ordered flow velocity or for the immediately preceding flow velocity. Clinician 116 can also identify flow velocity tolerances specific to a particular order.

The infusion system 210 may include a predetermined indication as to whether the dosing clinician 116 is allowed to override the flow rate tolerance 542b without the need for a new order. This indication can be applied to the entire patient medical system 100, a subsystem, or an individual clinician 116.

The maximum infusion duration 542d can be set separately for different parts of the patient healthcare system 100. The maximum infusion duration 542d can also be specific for a particular agent 124. Maximum injection duration override 566 (FIG. 8) can be performed if it is permissible to override the maximum injection duration 542d at the time of order entry. Overriding the maximum infusion duration at dosing sets whether it is permissible to override the maximum infusion duration 542d at the time of dosing and which group of users is allowed to do so. Can be provided to do. Where it is permissible to override during order entry and / or administration, the infusion system 210 can define a subset of clinicians 116 who are authorized to override the maximum infusion duration 542d.

The default value 544 includes, but is not limited to, default values such as drug diluent default value 544a, diluent amount default value 544b, dose default value 544c, and measurement unit default value 544d. The unit of measurement (UOM) default value of 544d includes the ability to identify the optimal unit of measurement for various parts of the patient medical system 100. For example, a drug can be measured in different units by physicians, dosing clinicians, pharmacists, finance personnel, and drug sorters. Physician 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 input 560.

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

The pharmacy UOM is generally a value that reflects the physical shape in which the drug is formulated, such as "tab", "vial", "inhalator", and "jar". Pharmacy UOMs are used in preparation 506 and stockpiling / dispensing systems. Financial UOMs are commonly used to calculate financial figures that appear on invoices and invoices. The drug sorter UOM is commonly used in sorting drugs.

The default value of the measurement unit, 544d, can be specified using a check box table arranged within a table in which checkmarks associate various UOMs with UOM users. The injection system 210 can use the same UOM for more than one function. For example, a doctor's UOM can be the same as a pharmacist's UOM. The default value setting 544 contains the data necessary to adjust the various UOMs. For example, the UOM default value 544d can include the multipliers and divisors needed to generate a one-to-one correspondence between the various UOMs. The UOM default value of 544b can be modified to suit the needs of individual clinicians. However, a one-to-one correspondence must be maintained by the patient medical system 100. The infusion system 210 can be designed to maintain a history of dosing unit default values.

The infusion system 210 can also include a dosing measurement suffix. The dosing measurement suffix can take a default value during order entry. The dosing measurement suffix can be a common unit for dosing measurement and can also include units related to patient characteristics such as body surface area and body weight. The dosing measurement suffix can be specified for each drug, per order type, per dose, and per UOM.

Database construction 546 is a database and / or, but not limited to, dispensing region 546a, additive information 546b, solution 546c, premix definition 546d, preference 546e, timing override reason 546f, flow rate override reason 546g. , Conversion table 546h, flow velocity description 546i, device / routing information 546j, and message trigger 546k, etc.

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

The agent 124 and / or the infusion order can have a flow rate tolerance that includes a flow rate tolerance of the system 542b. The injection system 210 can include a flow rate override reason table of 546 g. The flow rate override reason 546g is a note that the clinician 116 can select and / or provide when the clinician needs to change the flow velocity beyond the limits set by the flow rate tolerance 542b. The infusion system 210 includes a predefined message trigger 546k to indicate whether the clinician 116 should send a message to the patient's physician if it overrides the flow rate tolerance defined by the order. The infusion system 210 also includes a predefined message trigger 546k indicating whether the message should be exchanged if the clinician 116 sets and overrides a tolerance such as flow velocity tolerance 542b at a non-order level. be able to.

The injection system 210 can include, but is not limited to, a conversion table 546h such as a flow rate conversion table, a variable component conversion table, and a variable flow rate conversion table. Flow velocity conversions are, but not limited to, doses / hours at specific concentrations, doses per unit of body weight / hour, doses per unit of body surface area / hour, and total doses and totals. Includes the step of converting the infusion order into a flow rate determined by quantity / time, if initially specified in a manner such as duration.

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

Variable flow rate conversion involves conversion of injection orders with various flow rates into flow rates for the solution currently being injected. Variable flow rate orders include, but are not limited to, bolus / basal, orders, dose order tapering and dose order modification.

The injection system 210 can include a predetermined injection flow rate 542b. The predetermined injection flow rate 542b allows selection from the drop-down list as a shortcut from the step of inputting the flow rate from the keyboard, which can be associated with the flow rate description 546i.

The defined function 548 includes, but is not limited to, a dispensing region function 548a, a bag duration function 548b, an override request validation function 548c, a duration vs. volume function 548d, a duration vs. stream function 548e, and a flow velocity vs. drip rate. Functions such as the function 548f are included. The injection system 210 can include a duration vs. volume function 548d for determining the amount to be injected for each injection order. The flow velocity vs. drip velocity function 548f converts the flow velocity into an infusion velocity using information about the medical device 330.

The determined setting 550 includes, but is not limited to, settings such as override permission 550a, flow rate accuracy 550b, quantity accuracy 550c, and time accuracy 550d. If desired, the injection system 210 can determine the total injection volume and the flow rate of the injection order. Once these values are determined, it is desirable to round the calculated values to a flow rate accuracy of 550b and a quantity accuracy of 550c that can be understood by clinicians 116 such as doctors, pharmacists, and nurses. The flow velocity display accuracy 550b can be set to display the flow velocity up to the decimal place of the set number. Various parts of the patient medical system 100 can independently determine the accuracy for the displayed flow rate. For example, the infusion system 210 can display up to one decimal place for an adult treatment site and up to three decimal places for a neonatal treatment site. The flow rate accuracy 550b reflects the department in which the clinician's patient is located. The flow rate of the injection order can be rounded to system-defined accuracy. The accuracy may be the same for all infusion orders and may depend on the patient's department.

Similarly, the amount display accuracy 550c can be set to display the injection amount up to the decimal place of the set number. The configurable time accuracy 550d can be used to calculate the duration of administration based on the flow rate when the infusion is a single infusion or an intermittent infusion. The calculated total volume of each infusion bag is rounded according to the volume accuracy of 550c. The dosing time is rounded by the infusion system 210 according to the set time accuracy of 550d. The time accuracy 550d may be the same for all infusion orders regardless of the patient's department, or may be department-specific.

(Create order)
FIG. 8 is a block diagram showing functional elements for the injection order creation 504 of FIG. The injection order creation 504 includes a functional block for creating an injection order. Injection order creation 504 includes information input 560, calculation 562, check 564, and override 566 . The information input 560 may include, but is not limited to, functions such as order type identification 560a, drug identification 560b, dose identification 560c, diluent identification 560d, flow rate identification 560e, and injection site identification 560f.

Injection order creation 504 is linked to infusion bag preparation 506, infusion bag delivery (route 530), drug administration 512, and infusion order modification 514. Infusion order type 560a includes, but is not limited to, order types such as single dose, load dose, intermittent dose, and continuous dose. Continuous injections include alternating injections, sequential injections, tapering injections, and titration injections. When the first drug 560b is selected in the infusion order, the format of the infusion order type 560a for the drug can take default values. The ordering clinician may have the option of choosing a different order type. Dosage 560c and measurement unit 544d can also take default values. The unit of measurement 544d can be correlated with the drug and / or the dose 544c. The infusion system 210 may include one default diluent or several default diluents for the agent. One default can be identified as the preferred diluent. The description can be associated with the diluent to help the ordering clinician decide which diluent should be selected. References can be included in the description of diluents to avoid the use of certain diluents if the patient has hypertension.

The injection system 210 can also enable additional injection order subtypes 560a based on the injection order types described above. Additional infusion order subtypes 560a may include, but are not limited to, TPN infusion orders, continuous chemotherapy infusion orders, piggyback infusion orders, and high volume parenteral infusion orders. Injection order subtypes can be accessed from various parts of the injection system 210, allowing the classification and filtering of injection orders by subtype. Special label formats for each infusion order subtype can also be defined to further customize the infusion order subtype order and associated pharmacy workflow.

While searching for the drug 124 during the infusion order preparation 504, the drug 124 can be flagged as an additive and / or solution to assist the clinician in injecting order preparation. This designation can be made in the drug identification file.

The dose of the drug 560c can be determined by some methods such as, but not limited to, depending on body weight, body surface area, etc., and can be input according to the speed. If no flow rate is entered, the infusion system 210 calculates the flow rate according to the specified dose and time. The ordering clinician can identify the diluent 560d and its amount. Pharmacies can provide default values for such parameters-see line 582 (Fig. 6). Check 564 can be performed to ensure that the net concentration 564a and the flow rate 564b for the agent 560b are appropriate.

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 velocity 560e is checked 564b for a flow velocity tolerance such as a flow velocity tolerance 542b of the system. The net concentration of the agent 124 can be checked 564a against a net concentration tolerance such as the system net concentration tolerance 542a.

In one embodiment, the flow rate 560e may also include a display of a description of the default flow rate to facilitate order input. For the flow velocity 560e, the flow velocity description database 546i can be referred to.

Calculation 562 can include calculation of the dose based on the patient's weight and / or height (perhaps provided by the ADT interface 310), drug amount, diluent amount, concentration, or rate. Calculation 562 is, but is not limited to, the flow velocity, the quantity of bags 562a or the number of infusion bags required at a particular time, if not specified in the prescription, the time each infusion bag will be administered, and. Each infusion based on the concentration of the component in the solution and the calculation of the total amount of each infusion bag can be included. The flow rate, amount and / or duration to be injected can be varied. If modified, the infusion system 210 will automatically calculate the amount dependent on the modification, and based on the calculation, if the maximum dose of the component at that concentration exceeds that specified in the drug file for that component. The patient medical infusion system 210 may alert the pharmacist and / or the clinician 116 and request a reason code for the adjustment.

Calculation 562 can include, but is not limited to, calculation of bag amount calculation 562a, conversion calculation 562b, duration vs. volume calculation 562c, flow velocity vs. drip velocity calculation 562d, and the like. Check 564 includes various checks that the injection order can receive. Checks include, but are not limited to, net concentration check 564a, flow rate check 564b, dosing time check 564c, duration check 564d, injection site check 564e and the like. If the infusion order gets caught in check 564, clinician 116 can disable the check. The override 566 can include, but is not limited to, overrides such as net concentration override 566a , flow rate override 566b , dosing time override 566c , duration override 566d , and injection site override 566e . Override 566 can generate a message to doctors and / or pharmacies 520. The infusion system 210 can distinguish between system-wide overrides and subsystem overrides in determining whether or not a message generation 520 is required.

Overriding can include an indication of whether the clinician has the authority to override the tolerance. For example, the flow rate override 566b can indicate whether the clinician entering the infusion order has the authority to override the flow rate tolerance 542b of the system. This indication can be applied to the patient medical system 100 or a subsystem. The duration override 566d can indicate whether the clinician 116 entering the infusion order has the authority to override the duration 542d of the system. This indication can be applied to the patient medical system 100 or a subsystem. The override 566 also includes an indication of the reason for the override 566f . Reason for override 566 f can be selected by clinician 116 from the drop-down menu.

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

(Preparation for order)
FIG. 9 is a block diagram showing the functional elements for the injection order preparation 506 of FIG. Injection preparation 506 includes a functional block for preparing injection order 702 (FIG. 8). Injection preparation 506 can include, but is not limited to, preparation location determination 506a, component scan 506b, bag duration check 506c, and barcode printing 506d for drug label 124a. The barcode printing 506d can include the above-mentioned functions with reference to the label printing 326 (FIG. 4).

After the injection order has been entered into the injection system 210, the preparation instructions are routed to the preparation location. The preparation location depends on the preparation program 506 of the injection system 210 and the injection element. The injection system 210 may include a tunable database such as a preparation area database 546a that identifies where the injection order will be prepared. The infusion order can be prepared in a pharmacy or in a remote location such as a floor or treatment site 106. The clinician 116 is guided through a preparatory step that includes barcode confirmation of the ingredients, using event management information that can be displayed on the digital assistant 118 or other device with a display.

The drug label 124a identifies a component and a component concentration. The drug label 124a can be printed at any position. The drug label 124a preferably comprises a barcode print 506d. Barcode printing 506d can include barcode label 124a printing for each infusion bag. Label 124a helps ensure that the correct drug is administered at the correct time and / or in the correct order. Alternate and sequential injection orders are particularly prone to out-of-order and over-timing. Barcode printing 506d can include printing a unique barcode label for each bag of injection order 702. Bar code printing 506d can also include printing a bar code label 124a that uniquely identifies the combination of components in the infusion bag and the concentration of those components. The drug 124 barcode can include a prefix, a suffix, and a National Pharmaceutical Code (NCD). In one embodiment, the barcode may also include lots and expired. Alternatively, separate barcodes may be provided, including lots and expired barcodes. Other embodiments of barcodes, including active RFID tags or passive RFID tags, magnetic bands, etc., may be used.

(Drug administration)
FIG. 10 is a block diagram showing the functional elements for drug administration 512 of FIG. Drug administration 512 comprises a functional block used to administer the drug to patient 112. The drug administration 512 includes reading the drug barcode 512a, reading the patient barcode 512b, executing the expiration date check 512c, titration notification 512d, displaying the flow velocity vs. infusion rate 512e, "as needed" injection start 512f, and downloading the operation parameter 512g. , And time monitoring 512h can be included. The infusion system 210 can also convert an order that may have one or more flow rates, such as tapering and alternating orders, into a flow rate for the infusion bag currently being administered. The infusion system 210 can also convert an order having an infusion bag containing different components such as sequential orders into a flow rate relative to the infusion bag currently being administered.

Simultaneously with the administration of the drug 124, the clinician 116 scans the drug label 124a. The injection system 210 includes scanning the bar-coded label 124a at the start of execution of the injection order, at the time of changing the flow rate, at the time of changing the bag, and / or at the time of stopping the injection order. The infusion system 210 confirms that an infusion bag with a bar coded label should be administered at that time and to the patient 112. A history of drug administration, including flow rate and dose administered, can be collected and maintained. Some infusion orders require the infusion bag to be suspended with the intention of administering a particular amount of a small portion of the infusion bag. The infusion system 210 allows the clinician 116 to order the administration of a certain amount of infusion bag. Most infusion pumps have the ability to determine the amount or flow rate and time to administer. Once this time has elapsed, the infusion pump will automatically prevent subsequent dosing. As a reminder to the dosing clinician, the infusion system 210 provides the drug label 124a with the message that it should be partially administered and an appropriate amount should be administered.

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

The infusion system 210 can include initiation 512f of PRN infusion or "as needed" infusion. The “as-needed” infusion start 512 results in the creation of a new active order and the dispensing of the PRN drug. This option includes encouraging the clinician 116 to select a PRN injection from the list of prior PRN orders made to the patient and setting the default value of the requested injection bag to 1. Can be done. Clinician 116 may have the authority to change the amount of infusion bag requested.

Downloading 512g of driving parameters comprises the step of determining whether the patient identifier associated with medical care and / or the patient identifier taken from the wristband 112a is the same as the patient identifier associated with medical care at the central position. Can be done. The determination is often made by a first computer, eg, a first central server 109. If the infusion system 210 determines that none of the different patient identifiers are identical, the system can generate 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 operating parameters to a medical device 332 such as an infusion pump 120.

One advantage of the system program 210 is that the driving parameters for the medical device 332 can be digital assistant 118 or any other computer at a remote location before the driving parameters can be used to program the medical device 332. The point is that you don't have to go through. Bypassing a remote computer eliminates a potential source of error in administering drug 124 to patient 112. Operating parameters for the medical device 332 can be sent "directly" to the medical device 332, assuming that various validations are achieved. In this context, "directly" means that driving 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 may include an additional block (not shown) in which the central computer receives a second drug identifier. The remote clinician 116 can enter a second drug identifier. The second drug identifier can be the revised first drug identifier. For example, the second drug identifier can be part of a prescription or electronic physician order that is the source of the first patient ID and driving parameters. The infusion system 210 can then confirm that the first and second drug IDs are equivalent before sending the operating parameters to the medical device. The second drug ID can be replaced with the revised first drug ID between the time the prescription is entered and the time the drug 124 arrives at the treatment site 106. Then, if the second drug identifier is not equivalent to the first drug identifier contained in the drug label 124a, the infusion system 210 will sound the alarm. In yet another embodiment, the injection system 210 may include additional blocks (not shown) whose operating parameters are used to program the medical device 332.

Various blocks of the infusion system 210, such as block 512, may include the ability to display treatment information on the digital assistant 118. This can include the function of displaying information that accurately reflects the information on the display 120c of the injection pump 120. The information on the display 120c of the infusion pump 120 can be complemented with information about the patient 112, the patient's location, and the infusion order. This information can include information about multiple channels of the injection pump 120. The information to be displayed may include, but is not limited to, information such as personality, prompt line, status display line, operation icon, and head display. Operation icons include dripping, stop sign, flow check piggyback, and delayed start. The lift indication includes information such as drug label and infusion rate. Those skilled in the art are familiar with the above-mentioned display information and operation icons.

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. If the clinician 116 uses the infusion system 210 to perform infusion orders, change flow rates, and check infusion conditions, the infusion system 210 calculates the time and amount remaining to administer, and the calculation results are bagged. If it is indicated that a part of the above will be used, it is indicated. For example, in the final bag of orders that should be stopped before the full dose is administered, and / or in the bag of the order that must be replaced before the full dose is administered, the clinician 116 may use the Digital Assistant 118 and / or Receive an alert on cart 132. The alert can include a message such as "administer only 150 ml".

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

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

(Documentation and modification of orders)
FIG. 11 is a block diagram showing the documentation of the injection order 1012 and the functional elements for the injection order modification 514 and messaging 520 of FIG. Modification 514 includes a functional block used to modify an existing injection order. Modification 514 can also be seen as creating a new order and updating an existing injection order. Modification 514 includes modification change 1002, usually 1004 with all ordering options available for new orders, recheck 1006, recheck override 1008, and new flow rate vs. new drip rate display 1010. be able to. Modifications to the injection order often lead to documentation 1012 and messaging 520. Modification 514 includes the functions described for the formulation modification module 336 (FIG. 4). However, modification 514 is also accessible from other parts of the patient medical system 100, such as, but not limited to, prescription entry 324, prescription activation 306, and prescription permission 308.

Modification 514 includes duration modification 1002a, flow rate modification 1002b, use of new injection site 1002c, modification reason identification 1002d, injection bag volume identification 1002e, and stop order processing 1002f. The clinician 116 may also change the infusion rate without order if the patient 112 is complaining of discomfort or if it promotes fluid balance, such as when the patient 112 is vomiting.

Modifications change 1002 include new duration identification 1002a, new flow velocity identification 1002b, new injection site identification 1002c, modification reason identification 1002d, remaining amount in injection bag identification 1002e, stop order 516. Is done. The ordering options available during the initial injection order creation 504 are usually also available for modification of the injection order. The ordering options available during the initial order creation 504 include those shown in FIG. The recheck 1006 and the recheck override 1008 are similar to the check 564 and override 566 described with reference to FIG. The new flow rate vs. new infusion rate display 1010 helps clinicians minimize the possibility of error during drug administration 512. The modified injection order can result in a modified injection schedule.

The flow rate is frequently modified at treatment site 106, for example to catch up with the delay without changing the dispensing schedule if the infusion is inadvertently stopped for a short period of time. With such modifications, it may not be necessary to contact the pharmacy with a new injection schedule 704. In other cases, the new schedule 704 must be able to contact the pharmacy or other dispensing staff. The flow rate modification 1002b triggers a rescheduling of the infusion order and / or a message 520 to the appropriate clinician 116.

When the clinician 116 inputs the flow rate modification 1002b into the infusion system 210 at the treatment site 106, the clinician 116 may also choose to recalculate the infusion schedule 704 and send it to the pharmacy. Clinician 116 has the option of requiring printing of the new drug label 124a with the barcode printing 506d module. The new drug label 124a contains data that reflects new information about any of the previously prepared infusion bags.

The infusion system 210 and / or the clinician 116 can request a modification of the infusion site 1002c. The site can be selected from the list of anatomical charts on the computer screen. Clinician 116 can be requested to identify the reason for the modification 1002d. Reasons stored in the database, such as, but not limited to, timing override reason 546f and flow rate override reason 546g, can be displayed for ease of identification by the clinician 116. There may be a separate hard-coded reason for the corrections ordered by the doctor. For modifications ordered by the physician, the clinician 116 can be requested to identify the physician.

1002e to identify the remaining amount in the current infusion bag before performing the modification. Clinician 116 may be offered the option of receiving an amount calculated from the unmodified flow rate and / or quantity display.

If desired, 1002f can be used to stop the current injection. If order stoppage is not required, for example, the same infusion bag can be used in conjunction with new flow rates and / or new additional agents, and old flow rates can be identified and compared to modified flow rates.

Any previously prepared injection bag can be checked for expiration based on the new injection schedule 704. When the injection order is resumed after a temporary suspension or order hold, an expiration check can be performed for the expired solution already prepared.

The new injection schedule 704 is used to control preparation 506 at pharmacies or other preparation sites. The system default value 544 can be set as to whether any prepared bags should be credited to patient 112 through the invoice issuing interface 312 and whether they should be credited to inventory. ..

The injection order change 1002 includes all ordering options 1004 available for the new order. The modified flow rate can be rechecked with respect to rules and tolerances such as, but not limited to, net concentration 1006a, flow rate 1006b, dosing time 1006c, duration 1006e, and injection site 1006f. Override 1008 can be made available for unacceptable modifications. The infusion system 210 can override and display the reason for the drug being administered at a time other than the time specified in the original order 10008f. Clinician 116 can be requested to identify the reason for the modification.

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

The modification results in confirmation of the infusion bag expiration by the infusion system 210 and provision of a message to clinician 116 if the infusion bag expires before the order is completed. The message can request clinician 116 to contact the pharmacy. Confirmation of the expiration of the infusion bag for solutions such as, but not limited to, premixed solutions and solutions made outside the infusion system 210 can include parsing the scan code.

The flow rate override 1008b can indicate whether the clinician 116 modifying the injection order has the authority to override the ordered limit without requesting approval for the new injection order. This indication can be applied to the patient medical system 100 or a subsystem.

Documentation 1012 captures injection order information in real time. Documentation includes multiple injections in progress at the same time, and, but is not limited to, 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 when changes are occurring. Clinician 116 can make the flow rate changes required in the infusion order, such as reducing the flow rate of morphine infusion from 4 ml to 2 ml. The infusion system 210 can recognize the change as a new order, but the infusion system 210 can be configured to avoid duplication so that the modified order does not result in the generation of a new bag.

Documentation 1012 includes, but is not limited to, the ability to document changes such as infusion pause, infusion discontinuation, and / or infusion resumption. Clinician 116 can stop the injection for various reasons, such as a defective injection site, missed injection, and / or heparin / saline injection to facilitate movement of patient 112. Can be locked. Injection can be resumed when the new site / injection is restored. However, the length of time that can be spent on this may be variable and is usually recorded by the infusion system 210.

Government regulations often require tracking of all outages in the infusion process. The infusion system 210 is a digital assistant 118 or other computer by the dosing clinician 116 scanning the drug label 124a and adjusting the flow rate 1002a based on a tolerance such as the tolerance generated by the tolerance setting 542. Allows you to document flow velocity corrections on the device. The flow rate modification 1002b responds in real time to the infusion schedule 704 of the relevant pharmacy, ensuring just-in-time infusion bag inventory control for the patient treatment area 106. Documentation 1012 can allow retroactive application of orders under certain circumstances.

The infusion system 210 includes the ability to document the infusion site 1012d and the combined infusion 1012e for multiple infusion sites. In many situations, patient 112 has multiple drug 124s and "unfinished" infusions such that some injectable drug flows into one site and another injectable drug is infused at another site. Can be, for example, morphine injection, antibiotics and saline injected into the right arm (site 1) and 2/3 & 1/3 flowing into the TPN and double luminal CVL (site 2). The infusion system 210 allows the clinician 116 to document through which site various fluids are infused. In a treatment area 106, such as an intensive care unit, many infusions of two or more can be flushed into one line or one lumen. Clinician 116 can indicate in which lumen of the CVL the infusion or drug is flowing.

The injection system 210 includes a site position 1012d for injection and the ability to document any site position changes. The injection site is frequently changed by obstruction or measures. Therefore, the clinician 116 must document the site location change if the infusion is removed and then resumed.

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

System configuration parameters can be defined for the first type of medical device. System configuration parameters are transmitted and received by a particular type 1 device unless the particular first type device has more specific configuration parameters that apply to that particular first type device. .. For example, the first plurality of first-class medical devices can be placed at the location of a general medical procedure. The second plurality of first type medical devices can be placed at the site of intensive medical treatment. The location of a general medical procedure may not have specific setting parameters, while the location of an intensive medical procedure does not have a specific treatment parameter. System configuration parameters apply to all first-class medical devices throughout the infusion system 210, ie, devices within the general medical procedure location, unless specific configuration parameters are applied, for example, to the location of the intensive medical procedure. Will be.

For each type of device, the parameters that apply to all devices of that type across the device divided into specific groups are the specific setting parameters if the specific device belongs to a group with such a definition. Overrides system configuration parameters unless is overridden to a more specific level within the injection system 210. A group may be defined as a clinical service, a nursing room, and / or a combination of a service and a nursing room.

For each type of device, the user can define a set of configuration parameters that apply to all types of devices used for operations with a specific range of attributes that override any other definition. In the hospital, the operation may consist of infusion order and attributes that may include the patient's weight, drug, patient's condition, and patient's severity.

A device can be associated with a particular patient by identifying it as a general group, part of a particular group, and / or by including the device address in a table in a database. Common or specific configuration parameters can then be sent to the device according to the device's identification information. The particular configuration parameter can then be read back to the injection system 210 and compared to the configuration parameter initially transmitted to ensure that the first configuration parameter was correctly received by the instrument 332. If the configuration parameters are not received correctly, the injection system 210 can provide message 520 identifying inconsistencies or communication failures.

The injection system 210 can detect changes to configuration parameters made in the device without going through a central computer and send messages and / or alerts 520. The injection system 210 can also poll the instrument for confirmation of their configuration parameters. As the system and / or certain configuration parameters change, the change can be propagated to all equipment 332 identified in the system as belonging to the group according to the grouping identified in the injection system 210.

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

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

Therefore, as further described in detail below, one use of the MEMS component is as an in-line MEMS pump 5314 schematically shown in FIG. 53. The MEMS pump 5314 can pump the fluid contained in the drip bag 5320 through the tube 5312 and from there through the access device 5324 into the patient's body. The MEMS component has a local electronic device element of the MEMS attached thereto, the electronic device element of the MEMS is connected to an external durable MEMS control device, wherein the MEMS control device is described herein. Like the infusion pump 120 of the invention described in the book, it can communicate with the system 210. In one embodiment of the MEMS pump 5314, it is preferred that the electronic device element 5332 of the MEMS is built into the MEMS pump 5314 and can store operational information of the MEMS parameters. The electronic device and the MEMS control device having the power supply can be physically or wirelessly connected to the electronic device element of the MEMS. In one embodiment, the parameter operating information can be loaded from the removable MEMS controller 5338. The pump element 5314 preferably creates a fluid flow through the tube 5312 based on information locally stored within the MEMS electronic device 5332. This information is preferably downloaded from the wiring but removable MEMS controller 5338. Further, the MEMS component can communicate with the system 210 by wireless communication. Further, the MEMS control device can transfer information to and from the system 210, fully automating the control and inquiry processing of the MEMS components in the system 210 over a wireless or wired communication path.

The use of MEMS or other emerging economical manufacturing techniques provides an opportunity to add MEMS elements to disposable line sets that provide additional functionality such as pumping, barbing, and sensing. Some or all of the auxiliary local electronics could be included in the disposable part of the line set. 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 as it eliminates the need for costly sterility of system components between each subsequent application.

(Pop-up window)
In one embodiment, the system can automatically provide the clinician with information related to one or more drugs via a pop-up window. The drug table is preferably entered in the central database 108b. The drug table can include generic names for one or more drugs, as well as any trade name associated therewith. Each drug in the drug table is linked to a message for display via a pop-up window. The message can be specified by the medical facility or predetermined by the system supplier. The messages associated with each drug are 1) drug-related risks, for example during handling or exposure, 2) how the drug is administered by the clinician, 3) physician reference information on the drug, and 4) appropriateness for drug infusion. It is preferable to be concerned with warnings regarding pump channels and 5) injection setting procedures such as opening the roller clamps for piggyback injection.

The pop-up window shows the drug in the calculator, such as when the drug is ordered by a doctor via CPOE, when the drug is being processed by a pharmacy, etc., or when the drug is being administered to a patient by a clinician. Displayed when selected or entered in. In one embodiment, upon completion of drug selection or input on the remote computing device, the database within the central system 108 is accessed and at least one of the pop-up window messages associated with the drug is remotely calculated. It is provided to the device and displayed to the clinician.

At least one of the pop-up window messages associated with the drug is preferably provided for display at the same time as the start of a particular step in the drug order, treatment, and administration procedure. For example, upon inputting a drug into a computing device such as a CPOE, a pop-up window with a message about physician reference information about the drug is displayed, and in one embodiment, another pop-up window about the danger associated with the drug is displayed. be able to. Then, during order processing by a pharmacy or the like, one or more pop-up windows are displayed on the arithmetic unit 104 in the pharmacy to provide general information about the drug and possible risks associated with the drug. .. Then, when the order is being performed by the clinician, the clinician is informed of information about the administration of the drug and, in one embodiment, the potential risks associated with the drug, such as how the drug is handled. One or more pop-up windows are displayed on the associated arithmetic unit (ie, handheld 118).

The pop-up window displayed on the computer is preferably specific to the drug order, treatment, and steps in the dosing procedure being performed by the clinician. For example, pop-up windows containing doctor reference information are preferably not displayed to the nurse via the handheld device 118. Nevertheless, in one embodiment, the user or hospital can determine when and when a pop-up window should be displayed when a drug is selected or entered into a particular computer.

It is also preferable for the pharmacy to determine when and when the pop-up window should be displayed. For example, pop-up windows are preferably not displayed for conventional medicines. Instead, the pop-up window is preferably displayed for drugs that the pharmacy or medical facility believes that additional information in the pop-up window will assist in ordering, dispensing, or administering the drug.

(Drug administration)
A method of administering the drug 124 by the infusion system 210 will be described below. The method includes the ability to modify the injection order. Modifications include flow rate, correction of injection site, temporary suspension of injection, resumption of injection, and suspension of new drug 124 container. The method comprises scanning the barcode 512b associated with the patient, scanning the barcode 512a associated with the drug, and confirming the expiration if the infusion is a mixture, and the reason for the modification. Includes step 1002d to select, and step 1002e to record the remaining amount of the infusion bag or receive a value calculated from the previous amount and flow velocity. Confirmation of expiration of the infusion bag 512c can include the use of a mixture table and / or barcode.

The reason for the modification can be selected from the predefined table 546g. Reasons for correction can also include hard-coded values for changes ordered by the physician. When selecting a hard-coded value, the clinician 116 is prompted to select a doctor from the list of doctors. The attending physician can be the default value in the list of physicians.

There may be a rapid selection function for stopping the administration of the drug 124, for example, stop order 1002f. If rapid selection is not selected, the following steps can be included. The process of recording the flow rate and / or receiving the previous value for the flow rate-the previous value is displayed on the display 118a of the digital assistant, on the display 120c of the infusion pump, and / or on the medical cart 132; order the previous flow rate. The step of comparing with the flow rate given-this comparison can be achieved using the rules and tolerances of the infusion system 210 or subsystem; the step of displaying the appropriate message; the conversion between the flow rate and the drip rate. The 1012-conversion that can be displayed can be calculated based on the drip rate conversion table 548f defined in the injection system 210. The infusion system 210 generally facilitates the clinician 116 to select the correct infusion rate conversion using tube-based descriptions.

The step of changing the flow rate triggers the step of the injection system 210 to confirm the expiration date of the injection bag based on the planned flow rate. If the solution expires before or during administration, a message such as "This solution expires during the scheduled dosing period. Contact the pharmacy" is sent to the clinician 116. If it is a premixed injection bag and / or a customized injection bag, the expiration date is confirmed by parsing the scan code, if possible. The pre-injection site is accepted or the location of the new injection site is selected from the list or graphical anatomical chart. The schedule 704 is then recalculated and the pharmacy inventory replenishment is performed. The infusion system 210 can include biometrics for identifying patients and clinicians 116.

Before allowing the clinician 116 to access the infusion system 210, the infusion system 210 accesses information related to the identification of the clinician 116. The infusion system 210 can identify the clinician 116 using a device such as a bar code reader for reading the clinician 116 badge 116a. The system also authorizes clinicians 116 to access parts of the infusion system 210, to ensure that the clinician 116 is identified, to ensure that the clinician is an authorized user of the system, and to ensure that the clinician 116 is an authorized user of the system. Biometrics can also be used to determine if it has. The infusion system 210 may request a combination of the clinician badge 116a, or other key, and a validated biometric match to authorize the clinician 116 to access the infusion system 210. The system is also configured to terminate access to the infusion system 210 when the clinician badge 116a has been removed from the vicinity of the clinician badge 116a, or other device used to read the key. You can also do it.

Biometrics is a technique and science that statistically analyzes measured biological data. One field of biometrics is a field for determining unique physical features such as fingerprints. Biometrics allow an individual to be identified against a digital system such as the infusion system 210. Digital figures are generated, making transactions and dialogues more convenient and secure. Biometric features for identification include, but are not limited to, features such as fingerprints, facial, iris and retinal scans, and voice identification. The biometric device includes a scanning device or a reading device, software for converting the scanned information into a digital format, and a storage device for storing the biometric information for comparison with the stored record. The software identifies specific coincidence points in the data processed by the algorithm and compares the data. Unlike passwords, PIN codes, and smart cards, the biometrics of the injection system 210 cannot be lost, forgotten, or stolen.

The biometric scanner can be associated with a device for reading the clinician 116 badge 116a. For example, the biometric scanner can be a thumb fingerprint reader on the handle of a barcode reader. In another embodiment, the biometric scanner and electronic key reader can be placed on a portable drug cart and / or medical device. When the clinician 116 places the electronic key within a certain distance from the medical device, the processor will identify the particular individual's electronic biometric identification file that it should seek. The infusion system 210 preferably encourages the clinician 116 to scan his biometric information. The biometric information is input to the injection system 210 by some kind of biometric reader or biometric scanning device. A one-to-one comparison is made between the scanned biometric information and the pre-stored electronic biometric identification file for a 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, clinician 116 is denied access.

Furthermore, in another embodiment, the medical device does not have a control device. For example, a medical device can be a pumping device that does not have a control device and, conversely, simply receives a control signal from a separate control device. In one embodiment, the control device for such a medical device can be a first central computer 109. Therefore, the first central computer 109 can directly transmit a control signal to the medical device to control the medical device.

In another embodiment, after the infusion system 210 grants access to the clinician 116, the infusion system 210 provides access to the biometric scanner, or when the electronic key is removed from the vicinity of the biometric scanner. finish. The neighborhood in which the electronic key must be held may be a predetermined and / or variable and programmable parameter of the injection system 210.

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

In another embodiment, a database containing biometric information can be maintained within a central system 108, a pharmacy computer 104, and / or a treatment site 106. At treatment site 106, this database can be maintained within the portable cart 132, digital assistant 118, and / or medical device 332. Such a distributed database allows access to remote devices even if the network 102 is unable to communicate between various locations. When network 102 communication is restored, the remote and central databases can be synchronized with any information modified elsewhere, thereby properly updating the databases of both injection systems 210.

The infusion system 210 provides a closed-loop infusion therapy management system. The closed loop begins at the clinician's order of 116. Among other methods, the clinician 116 can enter orders through the digital assistant 118 and / or the medical cart 132. The order will then be available in real time for pharmacy permit 508 and physician permit 510. Orders are available in real time as electronic drug administration records (eMAR). eMAR is available to clinicians 116 for performing infusions. The infusion system 210 automatically documents modifications 514 such as drug administration 512 and flow rate changes 1002b. Through the process of drug administration 512, the infusion system 210 simultaneously coordinates the invoice system 210 and / or the inventory / invoice issuance 518 of the subsystem. 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. The infusion system 210 typically operates in real time, but batch processing and other messaging can be used to coordinate various stages of the infusion system 210 process.

The closed-loop injection therapy management system includes injection order entry 560, order preparation 506, and availability of injection conditions. Injection order entry 560 is possible, but not limited to, through several means such as prescription entry module 324, prescription modification module 336, and pharmacy interface 316. The computer screen 400 can be used when inputting an injection order. The infusion condition provides patient 112 different infusion usage and informs the pharmacy of the need for an additional infusion bag.

(Dialogue with the clinician's injection system)
In addition, the infusion system 210 can use a login system to determine if the clinician 116 has access to the infusion system 210. An example of the interface screen of the login system for the injection system 210 is shown in the login screen 1903 of FIG. On the interface screen, Clinician 116 enters both the username and password and clicks the "Login" key. The system 210 checks to confirm that the username and password are valid for the system 210. If either the user name or the password is not valid, the system 210 will notify the clinician 116 that the login was not possible on the login screen 2005 shown in FIG. The 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, the clinician 116 will have access to the system 210. In addition, if the clinician 116 logs in to the digital assistant 118 but does not use it for a period of time, system 210 safety measures prevent the digital assistant 118 from being used any further until the clinician 116 logs in again. To.

The Chief Clinician can also log in to System 210. As described in detail herein, the chief clinician is usually the clinician's direct supervisor or specific person. In addition, the lead clinician can be someone who assists the clinician in workflow or monitors alarm or alert conditions. In general, the chief clinician retains a supervisory or responsible mission across at least one department. Therefore, the Chief Clinician must log in with the login and password described above and then select the department associated with the Chief Clinician.

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

Another management function that the clinician can perform is to select the clinician's shift. As shown in the shift selection screen interface 2211 of FIG. 22, the clinician 116 can select either a standard shift or a customized shift. For that input, several selectable standard shifts are provided in the drop-down menu 2107. However, if the clinician 116 chooses 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 into the area 2255 provided and then tap the enter key 4809.

The interface screen 2313 for viewing the patient is shown in FIG. On this screen 2313, after the shift is selected, the clinician 116 can see the patient associated with the clinician 116. Clinician 116 can also see work related to the clinician 116. Therefore, a list of "must do" can be provided based on the patient, the clinician's work, or both. Different levels of shading and / or coloring can be utilized to distinguish between the levels of emergency medical care required for a particular patient. In addition, various icons can be associated with the patient to help the clinician 116 quickly understand the medical care required by the patient. The interface screen 2313 for viewing the patient in FIG. 23 provides the clinician 116 with the ability to add more patients with the button 2315. When the clinician 116 selects the "add patient" key 2315, the clinician can be provided with a list of additional patients.

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

The system 210 can also provide a message to the clinician 116 that is specific to the patient assigned to the clinician shift. General messages can include items such as order profile changes and drug administration errors.

The patient information menu interface screen 2521 shown in FIG. 25 can also be used on this system. The patient information menu screen 2521 provides a small patient chart for the selected patient. The patient menu screen 2521 also links to clinician 116 patient-related items such as drug / infusion administration, infusion stop, infusion resumption, infusion titration, flow rate history, pump status, and removal of the patient from shifts. It also provides functionality. The patient menu screen 2521 also has tabs for allergies and Ht / Wt, medication history, and test 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-carte is first opened. It displays information about the patient's drug allergies and general allergies, as well as the latest records of the patient's height and weight. An example of the medication history interface screen 2521b is provided in FIG. 25B . Typically, this screen 2521b provides the clinician with the patient's medication history within the selected lookup period. The lookback period can be adjusted by the clinician. Finally, FIG. 25C shows an example of the inspection result interface screen 2521c. The test results will be available in system 210 through the laboratory interface. All available results are shown and displayed in new order.

The infusion schedule interface screen 2623 for the patient is shown in FIG. This screen 2623 shows the infusion schedule for the selected patient. By clicking on one of the identified orders, such as order 2625 for morphine sulfate on the infusion schedule screen 2623, the system 210 will be linked to the drug order interface screen 2627 shown in FIG. 26A . The drug order screen 2627 provides order details 2625 for a particular order (ie, morphine sulfate). As part of detail order 2625, treatment parameter 2629 is provided, as well as the ability to link to warning 2631 and additional information 2633.

FIG. 28 shows the patient profile injection schedule interface screen 2835 where one of the scheduled injections failed. As shown on screen 2835, a "dosing failure" icon 4837 is shown next to the scheduled morphine sulfate infusion order 2839. By clicking on the "dosing failure" icon 4837, the system 210 links the clinician 116 to the dosing failure interface screen 2941 shown in FIG. The dosing failure screen 2941 asks the clinician 116 to enter the reason for the dosing failure 2943 or select it in the drop-down menu. The medication failure interface screen 2941 also asks clinician 116 whether the medication schedule for order 2839 should be adjusted. To adjust the dosing schedule, clinician 116 selects selection box 2945 on the interface screen 2941. When the clinician 116 clicks on the drop-down menu and enters 2943 to select the reason why the medication failed, the drop-down menu expands as shown on the interface screen 3047 of FIG. Usually, when dosing is no longer needed, the clinician will choose the "not needed" reason 3045. When the clinician 116 selects the "not needed" reason 3045 for a dosing failure, the system 210 removes the dosing failure icon 4738 and the "not needed" icon as shown in the infusion schedule screen 3135 of FIG. Insert 4857.

When the clinician 116 is ready to administer a medication or order to the patient, the clinician 116 selects order 3225 in the schedule interface screen 3235, as shown in FIG. 32, and then "gets the item". You will scroll down to the key 3249. After the clinician 116 selects the "get item" key 3249 within the screen 3249 of FIG. 32, the system 210 displays the drug interface screen 3351 as shown in FIG. 33. On the drug screen 3351, the clinician 116 scans the drug selected from the drug store as shown by the icon 3353 that scans the "warehouse", or by selecting the "skip warehouse scan" key 3355. It has a function to skip scan blocks. When the clinician 116 scans the item, for example by scanning the barcode on the item, the item information is displayed on the clinician's PDA 118. An example of the scan screen 3465 is shown in FIG. For example, when clinician 116 scans a drug, prescription 3467 is displayed on the 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. As shown on the interface screen 3569, when a scanning error is detected, the clinician 116 will be provided with identification information of the request or item to be searched as shown on the screen 3569. If the barcode cannot be scanned, for example due to dirt or damage to the barcode label, the data required by the scan can be entered manually.

If the selected drug is in the same efficacy category as another drug recently administered to the patient, the clinician's Digital Assistant 118 will display a warning message. Similarly, if the item has already been retrieved by another clinician, Digital Assistant 118 will display a message indicating such an occurrence.

If the order to be removed is a mixture at the dosing site, the individual components will be identified on the Digital Assistant 118 and removed by the clinician 116. After the item is retrieved, the system 210 generates a bag ID and prompts 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.

Certain orders can be on-call or put on hold. These orders are displayed on a patient profile screen, such as the interface screen 2835 of FIG. On-call or hold orders are only available for viewing, not for retrieval. These orders will be invoked later as needed.

Scenarios may also occur in which clinician 116 has an item that includes a drug item that has not been used for the patient. With reference to the interface screen 3657 of FIG. 36, the clinician 116 has the ability to identify reasons for not administering the drug, such as unnecessary, inability to visit the patient, refusal of medication, etc., depending on the monitoring results. If the patient has not yet been identified within the screen 3657, the clinician 116 can select the patient 3661 by scanning the patient or entering the patient's name. Further, the clinician 116 can select to return to the drug item in the drug store by inputting using the "discard / return" selection key 3663. For certain narcotics and regulated drugs, two signatures (ie, generally in the form of login and password, second permission) for both the process of first obtaining the drug and the process of returning the drug to the warehouse. Signing) can be requested.

The 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 if the patient ID does not scan properly, the system 210 displays a message that the scan is invalid. In addition, if the clinician 116 is unable to administer the drug, the clinician will typically have to enter a reason for not administering the drug 3659, as shown in screen 3657 of FIG. Some reasons for not administering the drug are that the monitoring results indicate that the drug is not needed, the patient cannot be visited, or the drug is rejected by the patient.

After the clinician 116 has confirmed the patient and the item or drug, the route confirmation interface screen 3771 is displayed. As shown in FIG. 37, an example of the route confirmation screen 3771 assists the clinician 116 in confirming the route 3773, line 3775 and site 3777. Dosing therapy 3778 can also be provided on the route confirmation screen 3771. After the clinician has entered the pathways 3737, line 3775, and site 3777, the clinician 116 can select the comparison button 4817 and the system 210 will confirm that the entered data is correct.

The clinician 116 can then select the pump channel mode, as shown in the interface screen 3881 of FIG. The pump channel mode interface screen 3881 shows therapy 3882, and clinician 116 has the option to specify therapy 3882 or piggyback therapy 3883 as the first-line therapy 3884. Each channel of the pump has the function of performing first-line therapy in addition to piggyback therapy. After completing the pump channel mode selection, the clinician can perform a pump channel scan. FIG. 38A shows the pump channel scan interface screen 3885. On the pump scan screen 3885, the clinician 116 scans the medical device, for example by scanning the barcode corresponding to the pump channel 121 and then clicking the arrow key 4809.

Clinician 116 scans the patient (a), eg, on the interface screen 2313 of FIG. 23, (b) scans the drug, eg, on the interface screen 3465 of FIG. 34, and (c), for example, the interface screen 3885 of FIG. 38A . After scanning the pump channel, such as above, the clinician 116 can program the infusion pump and compare it to the parameters of the programmed infusion pump or the parameters of the pharmacy order of the set values.

(Comparison of device settings and orders)
An exemplary flow chart for comparison step 5200 is provided in FIG. This step can also be applied to the step of programming the injection set value remotely from the server. Referring to FIG. 52, comparison step 5200 is initiated at block 5202 after clinician 116 completes the scan of patient ID 112a, drug container ID or drug bag ID 124a, and pump channel 121 as shown above. By scanning patients, drug bags and pump channels, association of relevant baseline data is made, which allows system 210, more specifically server 109, to further analyze and compare this additional data. Can be done. However, first of all, the first central server 109 checks at block 5204 to ensure that the scanned or input data for the patient, drug bag and pump channel provide a valid association. If the three data items do not result in a valid association, the system 210 displays an error message in block 5206 and the clinician 116 rescans or rescans the code for each of the patient ID, bag ID and pump channel ID in block 5202. Request to re-enter. If the three data items result in a valid association in block 5204, the server 109 will determine if the identified pump channel 121 exists in the database of the server 109 and for it to utilize, as described below. A sequence will also be run to determine if it is available.

After the pump channel ID has been 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 determining pump channel invalidity are that the pump channel does not exist in the system, the selected pump channel is already in operation, and so on. If the check on pump channel 121 yields invalid results, an error message will be displayed and the clinician will be notified that the invalid channel has been selected. Comparison step 5200 is excluded and the system is unable to make comparisons, as shown in block 5214, until clinician 116 rescans the pump channels and recognizes valid channels in block 5208. However, if the result of the check confirms that the selected channel 121 is a valid channel, the system proceeds to block 5212 to establish an appropriate link, as described below.

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

At block 5212, the first central server 109 attempts to establish a link or association with the patient ID, order ID and pump channel 121. If the first central server 109 is unable to establish a link between the identified data in block 5212, the comparison step 5200 is excluded and, as shown in block 5214, the system 210 will proceed with that step. not allowed. In addition, the system 210 displays an error message that some data is missing or inaccurate and the system is unable to make a comparison. If the first central server 109 establishes an appropriate link between the identified data in block 5212, the system goes to block 5216 where the clinician 116 is required to press the compare button 4817 on the digital assistant 118. move on. An example of the screen sequence performed in block 5216 will be described below.

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

If the injection is a primary injection, you will be instructed to click the "Compare" button 4817 on the comparison interface screen 3896 and then wait for instructions before starting the pump channel. If the infusion is a piggyback infusion, an instruction is given to press the start key on the pump 120 and then click the "Compare" button 4817. In a piggyback infusion, if the clinician 116 presses the compare button 4817 on the block 5216 before pressing the start key on the pump, an interface screen 4287 as shown in FIG. 42 is usually displayed, giving the clinician an error instruction. Will be.

First, prior to 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, the comparison step 5200 proceeds. If the communication link is lost, the comparison process cannot proceed.

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

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

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

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

An example of the associated comparison interface screen when the pharmacy prescription parameters and the programmed pump settings do not match in block 5224 is shown in the mismatch comparison interface screen 4087 of FIG. 40 with the mismatch icon 4825 displayed. When this result occurs, system 210 requires clinician 116 to either accept the discrepancy identified in block 5228 or reprogram the infusion pump in block 5230 to make another comparison in block 5216. It will be. Normally, the parameter in which the mismatch has occurred will be displayed on the mismatch screen 4807. If a discrepancy is accepted, it is recorded in the system database 109 at block 5232. Further, if a discrepancy is accepted at block 5228, the server 108a directs the clinician to the appropriate screen.

FIG. 41 shows an example of a comparison interface screen 4187 in which the system 210 cannot make a comparison because part of the data is not available. Specifically, in the example of FIG. 41, the speed setting value of the pump is not input to the system 210. Therefore, in this example, the system 210 cannot make a comparison until additional data such as velocity is entered. Normally, if the infusion is already in progress, the system is unable to receive updated pump information, there is a system communication error, or data from either programmed channel information or pharmacy prescription information. If there is a gap, the system 210 will not be able to make the comparison. Finally, the comparison screen 4287 of FIG. 42 displays another scenario in which the system 210 cannot make a comparison until the further steps displayed are taken. Normally, this interface screen 4287 is a piggyback injection infusion, and the clinician 116 presses the start key on the infusion pump 120 before pressing the comparison button 4817, as indicated by the instructions in interface screen 3896 in FIG. It is provided when the comparison button 4817 in the interface screen 3896 of FIG. 39 is pressed without pressing.

After the infusion pump initiates treatment, the clinician 116 can see the pump status in the pump status interface screen 4391 shown in FIG. 43 on his or her digital assistant 118. The pump status display 4391 displays a list of all currently performing infusions for a given patient. Normally, 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 conjunction with the infusion in this screen. become. The pump status display 4391 is not updated in real time while the current screen is displayed, but the latest real-time pump status screen is displayed by tapping the refresh button 4819.

As shown in FIG. 44, the clinician 116 can view the flow velocity history interface screen 4493. The clinician 116 can move directly to the flow velocity history screen 4493 by clicking the flow velocity history link on the patient menu interface screen 2521 shown in FIG. The flow rate history shows the history of programmed flow rate history changes for the current injection on a given channel. Usually, the patient information associated with the channel is displayed along with the latest prescribing information about the channel. Further, after the clinician 116 logs in on the digital device 118, selects a shift, and selects a patient, the clinician 116 records, but is not limited to, the infusion performed, the infusion is stopped, or the infusion is resumed. Includes recording, infusion discontinuation recording, viewing of the pump flow rate history described above, viewing of the pump injection status described above, response to pump alarms and pump alerts described below, viewing of messages / notifications and response to messages / notifications. Various tasks can be performed on the digital device 118. Specifically, for records of infusions performed, after clinician 116 scanned the item barcode, patient barcode, and pump channel barcode, the clinician programmed as detailed above. The pump setting can be compared with the order entered by the pharmacy. Normally, the clinician 116 would then use the pump 120 to perform the injection and use the digital device 118 to record the injection.

To initiate an injection, the clinician 116 typically scans the patient's wristband barcode 112a and then the barcode label 124a on the injection bag. When prompted by the digital device 118, the clinician 116 inputs and compares lines, sites and routes for injection, as shown in interface screen 3771 of FIG. Next, on screen 3881 of FIG. 38, clinician 116 selects primary injection or piggyback injection and scans the pump channel at 3883. Clinician 116 then programs the pump as instructed by the physician 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 setting matches the pharmacy input order, an interface screen such as screen 4287 will indicate a match, and clinician 116 can tap the 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 result recording interface screen 4937 of FIG. 49, allowing the clinician 116 to enter the appropriate result from the options in the drop-down list. These steps can be repeated for additional patients and / or additional pumps or channels.

Before administering the drug, the clinician 116 can be prompted to enter the parameters being monitored, such as the heart rate before administration of digoxin , or the pain assessment before administration of 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 a 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 monitoring parameter link 5001 is selected, the monitoring parameter input interface screen 5003 as shown in FIG. 50A is displayed. There, the clinician 116 can enter the requested information into the system 210.

In addition, the system 210 may require the clinician 116 to monitor the cycle count, typically when removing the drug or regulated drug from the drug store. For example, when a warehouse drawer is opened to provide a drug or regulated drug, the Digital Assistant 118 can display the cycle count interface screen 5101 as shown in FIG. The interface screen 5101 prompts the clinician to count the units of the drug currently in the reservoir or storage location and prompts the clinician to enter this data in the provided field. System 210 then compares this amount to the expected count. If the cycle counts do not match, the digital assistant 118 displays a message indicating the mismatch and then displays the cycle count screen 5101 again. If the cycle counts do not match again, the system 210 will record the mismatch and appropriate action can be taken.

If desired, the clinician can discontinue the ongoing injection before it is finished. This can be done with or without a discontinuation order to discontinue injections within the system. The discontinued injection can be resumed as needed, for example if the order is being titrated. When both the discontinuation icon 4813 and the infusing icon 4807 are displayed on the digital assistant 118, the clinician 116 is to display a list of all in-flight infusions to the patient on the digital assistant 118. You will be instructed to move. An example of such an injection stop interface screen 2727a is shown in FIG. 27A . In FIG. 27A , the discontinued injection order will be highlighted and indicated as the discontinued injection order. The clinician 116 will then scan the barcode on the discontinued infusion solution container and then the patient's ID. Next, an interface screen 2727b as shown in FIG. 27B is provided on the clinician's digital assistant 118. On the interface screen 2727b, the clinician can enter the time when the infusion was discontinued and the reason for the discontinuation. The clinician can then physically stop the injection pump 120 by pressing the stop button on the injection pump 120.

The injection restart interface screen 2727c is provided in FIG. 27C . Injections that are recorded as discontinued can also be resumed without an order to discontinue. To resume injection, clinician 116 must first navigate to the appropriate interface screen on Digital Assistant 118. By tapping the infusion discontinuation icon 4811 in the patient menu, a list of all currently discontinued infusions for that patient will be displayed as shown in interface screen 2727c of FIG. 27C . The clinician is prompted to select an injection to resume. Clinician 116 then scans the barcode on the solution container for injection to be resumed. System 210 compares the scanned ID to the currently discontinued infusion for the patient. After the system 210 compares the ID to the patient's currently discontinued, the digital assistant 118 prompts the clinician 116 to scan the patient's ID. The system 210 then confirms that the scanned ID matches the patient's ID, after which the system 210 prescribes the scanned infusion onto the digital assistant 118, as shown in the interface screen 2727d of FIG. 27D . Will prompt the clinician 116 to select a facility-determined reason for resuming infusion. Once the reason is selected, the clinician 116 can resume the injection with the pump 120 and then tap the arrow 4809 to continue. The system 210 records that the injection has been resumed.

Various icons are used to assist the clinician 116, as shown in the various screen shots / interfaces to the digital assistant 118. Many of these icons are shown in FIG. The patient list button 4801 is a key that allows the clinician 116 to move directly to a patient list screen such as the patient list screen 2313 shown in FIG. 23 when tapped. The back button 4803 is a key to return the screen on the digital assistant 118 to the previous screen when tapped. The OK button 4805 is tapped to approve the data shown on the digital device 118. When you tap the OK button 4805, the following screen is usually displayed. The injecting in progress indicator button 4807 indicates that an infusion programmed for the selected pump 120 and channel is currently in progress. The infusion waiting indicator 4810 indicates that the infusion programmed for the selected patient, pump 120 and channel is in the waiting state. The infusion discontinuation indicator 4811 indicates that the programmed infusion for the selected patient, pump 120 and channel has been discontinued. The infusion discontinuation order indicator 4813 indicates that the infusion to the patient, pump 120 and channel selected by the pharmacy input order will be discontinued. The physician note indicator 4815 indicates the presence of a physician note for the selected patient, pump 120 and channel. Clinician 116 can tap the note indicator 4815 to see the note. The comparison button 4817 is provided on various screens and, when tapped, causes the system 210 to perform a comparison between the scanned item and the pharmacy input order, as well as additional comparisons. The refresh button 4819 is tapped to update the latest data and show it on the screen. The 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 and is tapped to approve and enter data selected from the options in the drop-down list or manually entered in the field. The comparison match indicator 4823 indicates that the programmed pump set value matches the pharmacy input order information. The comparison mismatch indicator 4825 indicates that the programmed pump settings do not match the pharmacy input order information. The incomparable indicator 4827 indicates that the system cannot compare the programmed pump settings with the pharmacy input order information. The pump alarm / alert indicator 4872 indicates that an alarm condition or an alert condition has occurred. When the alarm / alert indicator 4872 is tapped, the enlarged pump alarm / alert screen is displayed. On the alarm / alert screen, the red alarm / alert icon 4872 indicates the alarm status, and the yellow alarm / alert icon 4872 indicates the alert status. The alarm / alert mute button 4874 is tapped to temporarily mute the audible alert on the 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 be taken to resolve the issue. The wireless module low battery alert indicator 4835 indicates that the hub 107 is currently running on a spare battery with less than 30 minutes of remaining battery power.

The above disclosure of settings and usage of the Digital Assistant 118 has discussed clinicians 116 performing these functions. However, it is understood that these tasks can be performed by any administrative staff or staff of the hospital, whether or not the individual is a clinician 116.

(Emergency notification process)
Referring to FIG. 12, preferred embodiments of the emergency notification system 1200 are shown. The notifying party 1210 is communicating with the communication network 1220. Those skilled in the art will find that various communication networks including, but not limited to, Ethernet® networks, coaxial cable networks, wireless local area networks, and wireless wide area networks are operational. In addition, 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”) It can be used. Further, the communication network 1220 can operate as part of a larger communication network. For example, the communication network 1220 can be, for example, a wireless communication network communicating with an existing wired communication network in a hospital.

It is the notifying party 1210 that is communicating with the communication network 1220. 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. Further, the notifying party 1210 can be an automated process, such as a computer program or medical device. An automated process that acts as a notifying party 1210 can be programmed to broadcast emergency notifications throughout the communications network 1220 upon the occurrence of a particular condition or event. For example, the automated process can be programmed to broadcast an emergency notification at the same time as detecting the patient's condition.

Emergency notifications are received by one or more target parties 1230. The target party 1230 can be a clinician, such as a doctor, and a nurse. The target party 1230 can also be an emergency response personnel or security personnel, or an environmental disaster response team. The target party 1230 can be any individual communicating with the communication network 1220. Embodiments of the invention provide the notifying party 1210 with the option of sending an emergency notice to only one particular target party 1230 or multiple target parties 1230, or all target parties 1230. The present embodiment allows the notifying party 1210 to select which target party 1230 receives the emergency notification.

The target party 1230 and the notifying party 1210 communicate with each other through the communication network 1220. Those skilled in the art will find that various modes of communication 1240 that can be provided to the notifying party 1210 and the target party 1230 communicate with the communication network 1220. For example, communication mode 1240 can be a wired connection, such as a personal computer or a programmable control device. Communication mode 1240 can also be a wireless network connection enabled through a handheld computer or mobile phone.

Here, with reference to FIG. 13, the notification interface 1300 from the viewpoint of the notification party 1210 is shown. Those skilled in the art will appreciate various interfaces that authorize the notifying parties 1210 to broadcast emergency notifications over the communication network 1220. The notification interface can be an intranet or a website connected to the Internet. The notification interface can also be activated by a mobile phone or other phone, or by email. In one embodiment, the notification interface 1300 is a type of handheld computer found to be widely commercially available. For example, PalmOne, Inc. Palm device manufactured by PalmOne, Inc. Visor device manufactured by Hewlett-Packard, Inc. Jornada device manufactured by Dell, Inc. Axim device manufactured by Sony, Inc. The CLIE device manufactured by Toshiba, Inc. , Compaq and Pocket PC devices manufactured by Symbol are included.

In one embodiment, the notification interface 1300 comprises a menu 1330 listing one or more options 1340. For example, one notification option 1340 may allow the notification party 1210 to select a particular clinician or clinician type as the target party 1230 for emergency notification. Another notification option 1340 may allow the notifying party 1210 to choose to revoke the emergency notification if the emergency notification is erroneously transmitted. Additional notification options 1340 can include inputs for patient identification information, patient location, emergency type, and expected response time.

Here, with reference to FIG. 14, one embodiment of the receiving interface 1400 from the point of view of the target party 1230 is shown. Like the notification interface 1300, the reception interface 1400 can operate on a variety of different platforms and can continue to be feasible under the principles of the invention. In one embodiment shown in FIG. 13, the receiving interface 1400 is a handheld computer. Interface 1400 includes a screen 1420 for displaying configurable information 2350. Information 2350 can 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 set with hotkeys 1350 and 1460. For the notification interface 1300, the hotkey 1350 can be configured to send an emergency notification containing information automatically obtained from the notification interface 1300 itself. For example, by pressing the hotkey 1350 on the notification interface 1300, it can be set to automatically send an emergency notification including that information.

(Messages & notifications including alarm / alert notifications)
The system provides the ability to send notifications and messages. Notifications are, but are not limited to, patient status lists, alarms, alerts, infusion schedules, orders, overrides, warnings, treatment parameters, links to additional information, medication failures, route confirmation, comparisons, flow rate information, physician notes, Communication loss, low battery, administration 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 can also be provided to any one of a large number of clinicians and / or chief clinicians.

As mentioned above, one type of notification is an alarm / alert notification. In this system, notifications can be increased in stages. The escalation process for a particular alarm / alert is shown in FIG. Notification steps are typically provided to send notifications to any number of clinicians 116. The identified alarm / alert escalation step 1500 of FIG. 15 has the ability to notify a series of clinicians via the clinician's device 118 when an alarm or alert is active on a medical device such as the infusion pump 120. 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 or sound generator 118c. For illustration purposes only, the clinician's device will be referred to below as Digital Assistant 118 in this detailed description. Further, the alarm / alert escalation step 1500 provides an escalation step if the clinician does not respond to the alarm / alert notification on the digital assistant 118. When the escalation step is initiated, a notification is sent to another or second clinician's digital assistant 118 identified in the escalation step. Although alarm / alert notifications are sent to Digital Assistant 118, it is understood that normally pump alarms and alerts can only be resolved at the pump. As described herein, the muffling of alarms or alerts in the Digital Assistant 118 may or may not act on the pump, as in block 1580 of FIG.

The alarm / alert escalation step 1500 begins at block 1505 when at least one or both of the alarm states or alert states are triggered in the medical device 120. In the preferred embodiment shown in FIG. 3, following the triggering of an alarm or alert in the medical device 120, a signal containing the alarm state or data related to the alert state is generated and transmitted from the medical device 120 to the server 109 in block 1510. To. In a wireless environment, a medical device 120 having a wireless transmitter is provided, or a medical device 120 connected to a wireless hub 107 is provided. In the latter example shown in FIG. 3, the hub 107 receives a signal from the medical device 120 and converts the signal into a format suitable for transmission to the system network 102 via a wireless communication path or wireless communication link 128. .. Further, if the hub 107 recognizes that the alarm, alert or other notification is a duplicate notification, the hub 107 may discard the duplicate notification. The transmitted signal is received by the radio access point 114 in the medical environment. The wireless access point 114 serves as an interface between the wireless communication path (that is, the wireless communication path 128) and the wired communication path such as the wired communication path 110 shown in FIG.

After the server 109 receives the data related to the alarm state or alert state transmitted in block 1510, the server 109 performs a prerequisite check in block 1515. Prerequisite check 3030 associates an alarm or alert state in the medical device 120 with a particular patient and the patient with a primary clinician, also referred to as the first clinician (this association is the central system service device 108a). Can be done in) and can include associating a first clinician with the clinician's digital assistant 118. The server 109 uses the information obtained in its prerequisite check at block 1515 to use the medical device 120 (and certain channels 121 of the infusion pump 120 in one embodiment), the patient, the primary clinician or the first clinician. And establish a relationship with the first clinician's digital assistant 118. It is understood that there is a many-to-many relationship between patient 112 and clinician 116. Thus, a large number of first clinicians, a large number of second clinicians, and a large number of n-level clinicians can be associated with one particular patient. In addition, n-level escalation is also possible within the system.

Normally, the server 108a stores a patient-to-clinician many-to-many association and a patient-to-department association within it. The server 108a transmits these associations to the server 109, which stores these associations. Similarly, server 108a sends the chief 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, server 109 determines if the first clinician's digital assistant 118 is active. If the first clinician's digital assistant 118 is active, then the server 109 will generate a signal representing an existing alarm or alert state. This 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 the server 109 to the wireless access point 114. Then, at block 1525, the radio access point 114 transmits a signal associated with the alarm or alert state to the clinician's digital assistant 118 via wireless communication transmission.

Signals related to alarm or alert conditions can also be transmitted at block 1525 to the chief clinician, the subordinates of the first clinician, or the second clinician. Such signals can be transmitted via wireless or wired communication. In addition, the chief clinician may be using a digital assistant 118, a desktop computer, or any other electronic device. The chief clinician is generally the boss or any person to whom the clinician reports. In addition, the lead clinician can 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. In this block, the alarm status or alert status is displayed on the clinician's digital assistant 118. The display on the clinician's Digital Assistant 118 can be visible, audible, or both visible and audible. Further, the visible display may include one or more texts, icons, symbols and the like. Similarly, as mentioned above, the audible display can include different audible sounds at different decibel levels. Visible and audible indicators can be set by the hospital. FIG. 16A discloses a screen shot of a list screen 1662a of an exemplary alarm / alert interface on a clinician's digital assistant 118. The alarm / alert list interface 1662a contains a list of patients currently associated with the alarm / alert of the active channel. As shown in FIG. 16A , this clinician's digital assistant 118 currently has three active alarm / alert displays. There are alarm states for patients 1, 1664, alarm states for patients 2, 1666, and alert states for patients 3, 1668. As shown in FIG. 17, each patient name and corresponding alarm / alert icon are hyperlinked to the appropriate pump alarm detail interface screen. In one embodiment, the list of patients is filtered to include only those patients currently associated with the clinician 116 logged in to the digital assistant 118 displaying this interface screen. This clinician-to-patient association may be performed as a primary clinician or as a temporary care clinician. A second clinician can also be accessed through the escalation process. The alarm / alert list interface 1662 is generally accessed during the normal clinician workflow by clicking on the alarm / alert icon 4872 displayed on the clinician 116's digital assistant 118.

As mentioned above, if the alarm or alert state is displayed on the clinician's digital assistant 118 at block 1530, this display can be provided visually, audibly, or both. If the clinician's digital assistant 118 is provided with an audible display, an alarm icon 4872 appears on the clinician's digital assistant 118's display 118a. If an audible display is provided, the clinician may have the ability to mute the audible display even if the clinician is not responding to an alarm or alert condition. If the clinician mute the alarm, the server 109 will activate the mute timer. The visible display will remain even if the audible display sound is muted. As shown in FIG. 16A , an alarm / alert provides an audible display to the clinician's digital assistant 118, but if the clinician's mute has muted the sound, an alarm / alert mute icon 4874 is provided. To. Further, if the clinician does not respond to the alarm within the time limit of the timer at the same time as the alarm / alert state increases, the mute of the audible display can be canceled. An alternative embodiment of the audible display can be a vibration alert.

Further, it is understood that the times of multiple alarm / alert states can occur simultaneously or at the same time. Accordingly, simultaneous signals or partially overlapping signals containing data related to a particular alarm state or alert state are generated and transmitted from the medical device 120 to the server 109 in block 1510. The alarm / alert signal can be generated from the same medical device 120 or different medical devices 120. In addition, alarm / alert signals can be associated with the same patient or different patients. However, each of the alarm / alert signals is individually routed to the alarm / alert escalation step 1500 described herein for each alarm / alert state. As shown in FIG. 16A , a particular clinician may have numerous alarm / alert displays on his / her digital assistant 118. Another example of the alarm / alert screen is shown on the interface screen 1662b of FIG. 16B . As is common in the system, the line referenced as 1676 in the interface screen 1662b of FIG. 16B is the end of the list, specifically the alarm / alert display list for a particular clinician in this interface. Is shown.

FIG. 17 is detailed after selecting to view one of the alarm / alert displays for a hyperlink to a patient on the clinician's digital assistant 118 from Listing 1662a in the interface of FIG. 16A . The patient alarm / alert interface 1765 is shown. Here, the clinician has selected alarm display for patients 1, 1664. The alarm / alert detail screen 1765 provides the clinician with a message detailing the reason for the alarm / alert. The clinician can click the refresh button 4819 to update the current information displayed on the screen 1765. As shown on interface 1867 in FIG. 18, there may be multiple alarms or alerts 1878, 1882 for the same patient. This alarm / alert interface 1867 provides a list of alarms / alerts for all active pumps currently associated with a given patient. The alarms / alerts for these active pumps can be from multiple channels 121 and / or pumps 120 and can even 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 transmitted to the clinician's digital assistant at block 1525 and received by the principal clinician's digital assistant 118 at block 1530, a timer is triggered 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 can be set by the hospital. At block 1540, the system determines if an alert or alarm has been responded to within the timer's time limit. 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 about whether the medical device 120 has an acknowledgment or response to an alarm / alert state. The alarm / alert process is then escalated at block 1545 if the primary clinician's digital assistant 118, or medical device 120, or even the principal clinician has not responded.

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

When the alarm is escalated, server 109 performs another prerequisite check at block 1550 . This precondition check 1550 involves associating the patient with a second clinician (this association can be made with the central system service device 108a) and the second clinician with the second clinician's device or second. 2 may include 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 check 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 if the second clinician's digital assistant 118 is active. If the second clinician's digital assistant 118 is active, the server 109 then generates an escalated signal that represents an existing alarm or alert state. This escalated signal also includes data such as patient name, patient location, room identification, bed identification, alarm or alert type, status description, time, date, clinician identification and / or prescription. In a preferred embodiment, the escalated signal is transmitted from the server 109 to the wireless access point 114. The wireless access point 114 then, at block 1555, transmits an escalated signal associated with an alarm or alert condition to a second clinician's digital assistant 118 via wireless communication transmission.

The escalated signal associated with the alarm or alert condition can also be transmitted to the chief clinician at block 1555. Such escalated signals can be via wireless or wired communication. In addition, the chief clinician can use a digital assistant, desktop computer, or any other electronic device. As mentioned above, the chief clinician is usually the person who assists the clinician in the workflow to the direct supervisor or specific person, or the clinician, or monitors the alarm or alert state.

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

After the secondary signal is transmitted 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 (first clinician and / or chief). There are at least two devices with active alarm / alert status (clinician). Thus, as shown in blocks 1540 and 1565, any of these clinicians can respond to alarm / alert conditions. 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 chief clinician's computer or device, or the medical device 120. Become.

Referring to block 1520, if server 109 determines that the primary clinician's digital assistant 118 is not active, and if server 109 determines that an alarm / alert condition still exists in block 1545, server 109 discusses above. Proceed to block 1550 to determine the appropriate second or chief clinician to send the alarm / alert signal. Further, it is understood that the block 1520 can occur at any time during the alarm / alert escalation step 1500. One reason the clinician's Digital Assistant 118 is inactive may be the loss of signal from the server 109. As shown in the communication loss interface screen 4501 of FIGS. 45A and 45B , if the signal is lost, the digital assistant 118 provides the clinician 116 with a screen 4501 indicating the signal loss and / or an audible / vibration display. .. The communication loss screen 4501 also informs the clinician 116 which patient's signal was lost. On screen 4501, the system 210 also provides the clinician 116 with troubleshooting information for regaining the signal. When the hub 107 or digital assistant 118 is out of radio range, pump alarms and alerts cannot be received by digital assistant 118.

Other reasons why the Digital Assistant 118 is not active may be a low battery in the Digital Assistant 118, a low battery in the wireless hub 107, or a signal loss in the Digital Assistant due to the access point 114. .. The system 210 provides the clinician 116 with a low battery screen. As shown in the interface screen 4603 of FIG. 46, one type of low battery screen is a screen that warns the clinician that a low battery condition is present in the wireless hub 107 connected to the patient's injection pump. When a low battery screen is provided, the screen contains a list of patients whose infusion is associated with that particular hub 107. The list of patients is typically only those who are currently associated with the clinician logged in to Digital Assistant 118 displaying screen 4603, and 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 a first clinician or a second clinician throughout 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, step 1500 may proceed to block 1550 so that the signal can be sent to the second clinician and / or the chief clinician. can. Further, as described above with respect to the timeout feature and other features of the present disclosure, if the communication signal from the server 109 or the medical device 120 is lost, the signal loss on the digital assistant 118, as shown in FIGS. 45A and 45B . Can provide a message.

At any time during the alarm / alert process, the primary clinician may respond to the alarm / alert signal. If the primary clinician responds to the alarm / alert signal at block 1540, the escalated process will be avoided. However, if the escalated process at block 1550 is initiated, at block 1565 the attending physician or second clinician can respond to the alarm / alert signal. Similarly, the alarm / alert condition can be resolved at any time before or during the alarm / alert escalation process at the medical device 120 or by the chief clinician. At block 1540 or block 1565, the audible alarm of the medical device 120 and the clinician's digital assistant 118 will be terminated after the alarm / alert condition has been cleared on the medical device 120 or by the chief clinician. Become.

At block 1585, server 109 records all alarm / alert states as events. The process of recording an event includes recording information about the alarm / alert status, recording the clinician who responded to the alarm / alert status, and recording the start time of the alarm / alert status (see block 1505). And the step of recording the time when the alarm / alert status is corrected. Further, at block 1590, the server 109 will reset the timer and update the medical device alarm list. The alarm / alert status can also be recorded in the pump event history.

(Example use case)
55A-62 are flowcharts of exemplary operations that can be performed using the systems described herein. Exemplary operations include performing a new injection, scanning the pump channel, changing the channel to which the pump is assigned, stopping / stopping the injection, restarting the injection, and removing the pump. In general, each of these operations has information indicating the operation to be performed, information identifying which patient 112 will be affected (eg, patient ID), and which agent 124 for that patient 112. Receives an input from an electronic device such as the Digital Assistant 118 that includes information (eg, RxID) that identifies whether the patient will be affected. This information is then transmitted to the first central server 109, which confirms that the channel identification information matches the injection order information and that the correct injection operation was performed. ..

(Injection implementation process)
FIG. 55A shows an example of the injection implementation step 5500. Part of the injection implementation step 5500 is an alternative embodiment of the comparative procedure 5200 outlined above. Injection performing step 5500 can be used to initiate a new injection. In general, the infusion step 5500 is information indicating that the infusion step will be performed, information identifying which patient 112 is affected (eg, patient ID), and which agent 124 for that patient 112. Receives an input from an electronic device such as the Digital Assistant 118 that includes information (eg, RxID) that identifies whether the injection will be initiated. Then, step 5500 transmits this information to the first central server 109, the first central server 109 confirms that the channel identification information matches the injection order information, and the correct injection is started. To confirm.

More specifically, this exemplary injection implementation step 5500 begins at block 5502 when the second central server 108a causes the 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 the patient 112 associated with the user (eg, clinician 116) logged in to the digital assistant 118 at that time. Once the user has selected patient 112, information identifying the selection and / or 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 can be via any suitable communication path 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 a list of operations. FIG. 25 shows an example of the digital assistant display 118a showing a list of operations. The list of movements is preferably limited to the movements associated with the selected patient 112. For example, the "injection performed" operation will only be available if at least one infusion is currently associated with the selected patient 112.

When the user selects the "injection performed" operation from the operation list, information identifying the selected operation is transmitted to the second central server 108a. In response, at block 5506, the second central server 108a displays to the digital assistant 118 a screen prompting the user to select the drug 124 to be injected from the list of drugs displayed on the digital assistant 118. Let me. FIG. 26 shows an example of a digital assistant display 118a showing a list of agents. The list of agents 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 infusion or one infusion. Data indicating the selected agent 124 is then transmitted to the second central server 108a.

Next, at block 5508, 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 patient 112. FIG. 36 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with patient 112. The user can scan the barcode label on the patient's wristband 112a using the scanner of Digital Assistant 118. Alternatively, the user can manually enter the patient identifier in Digital Assistant 118. Then, at block 5510, the patient identifier is transmitted to a second central server 108a for verification. The second central server 108a then attempts to retrieve the patient identifier in the 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 the patient invalidation notification. Once the user accepts the patient invalidation 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) is present as a valid patient identifier in the database, at block 5514, the second central server 108a provides the machine-readable identifier associated with the agent 124 to be administered. Display a screen on the Digital Assistant 118 that prompts the user to scan. FIG. 34 shows an example of a digital assistant display 118a that prompts the user to scan the machine-readable identifier associated with the agent 124. The user can use the scanner of the digital assistant 118 to scan the drug label 124a (eg, the barcode on the infusion bag) on the bag of the drug 124. Alternatively, the user can manually enter the drug identifier in Digital Assistant 118. Then, at block 5516, the drug identifier is transmitted to a second central server 108a for verification. The second central server 108a attempts to retrieve the drug identifier in the database. If the drug identifier (eg, bag ID) does not exist as a valid drug identifier in the database, at block 5518, the second central server 108a causes the digital assistant 118 to display the item invalidation notification. Once the user accepts the item invalidation notification (or the notification times out), at block 5514, the digital assistant 118 redisplays the screen prompting the user to scan and resume the machine-readable identifier associated with the drug 124. indicate.

Once a valid drug identifier is obtained, the second central server 108a uses the drug identifier to search for patient identifiers in the database. Then, in block 5520, the patient identifier from the database was compared to the scanned (or manually entered) patient identifier, and the scanned (or manually entered) drug 124 was scanned (or manually entered). ) It is determined whether it belongs to the 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 the item invalidation notification.

If the two patient identifiers match (ie, this patient 112 matches this drug 124), at block 5522, the second central server 108a prompts the user to enter a route, line, and site. Display on Digital Assistant 118. FIG. 37 shows an example of a digital assistant display 118a that prompts the user to enter a route, line, and site. Then, at block 5524, data indicating routes, lines, and sites are transmitted to a second central server 108a for verification. When a route mismatch occurs, at block 5526, the second central server 108a causes the digital assistant 118 to display the route mismatch notification. FIG. 40 shows an example of the digital assistant display 118a having a discrepancy notification. Once the user accepts the route mismatch notification (or the notification times out), at block 5522, the digital assistant 118 redisplays the screen prompting the user to enter the route, line, and location. If no route mismatch occurs, at block 5528, the second central server 108a causes the digital assistant 118 to display a screen asking the user to make a choice between manual prescription comparison and automatic prescription comparison. If manual prescription comparison is selected in block 5530, in block 5532, the second central server 108a causes the digital assistant 118 to display parameters that the user will manually validate.

Subsequently, at block 5534, the second central server 108a determines if there are more items (eg, dosing) to be performed for this patient 112. For example, the injection order selected in block 5506 may require a primary injection and a piggyback injection. If there are more items to be performed (eg, dosing) for this patient 112, at block 5514, the second central server 108a is asked to scan the machine-readable identifier associated with the drug 124 to be administered. Display the prompting screen on the digital assistant 118. FIG. 34 shows an example of a digital assistant display 118a that prompts the user to scan the machine-readable identifier associated with the agent 124. If there are no more items (eg, medications) to perform for this patient 112, at block 5536, the second central server 108a causes the digital assistant 118 to display a screen showing the results of the procedure. FIG. 57 shows an example of the digital assistant display 118a showing the implementation result.

The implementation result is also passed to the first central server 109. For example, the implementation result can be passed as a form variable to the first central server 109 (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. In the absence of failure, at block 5540, the first central server 109 commits all new channel-patient-drug relationships to the database of the first central server 109. Then, in block 5542, the first central server 109 returns to control of the second central server 108a by moving to a predetermined URL associated with the second central server 108a. If there is one or more failures, at block 5544, the first central server 109 discards the channel-patient-drug relationship associated with the error and the channel-patient-drug relationship associated with success. Commit to the database on the first central server 109. Failures can be associated with a second central server 108a and / or a first central server 109. Therefore, when the first central server 109 returns to the control of the second central server 108a by moving the first central server 109 to a predetermined URL associated with the second central server 108a in the block 5546. In addition, it is preferable to return the failure associated with the first central server 109 (for example, maintenance failure) 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. The "prescription comparison" XML document includes a patient identifier (eg, wristband ID), a drug identifier (eg, bag ID), a completion URL, and a cancellation URL. The completion URL is a network address used when a prescription match is found. The cancellation URL is a network address used when 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 asks the first central server 109 whether the "prescription comparison" XML document is valid. To judge. For example, the first central server 109 can check whether the expected data in the normally "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 user that the first central server 109 was unable to perform the "prescription comparison" operation. Display the error message shown in (1) on Digital Assistant 118. This indication can include reasons such as which data is missing from the "prescription comparison" XML document. After the user presses the "OK" button to accept the error message, at block 5552, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the first central server 109 determines that the "prescription comparison" XML document is valid, the first central server 109 initiates the channel scan step 5554. Typically, the channel scan step 5554 scans the machine-readable identifier associated with the "new" pump channel (eg, pump channel 103a) and assigns to any patient 112 whether the scanned channel is available (eg, any patient 112). It prompts the user to determine (not, assigned to the current patient 112 but not used, assigned to another patient 112 and overwritten, etc.). If the scanned channel is not available, the "inject" operation is canceled. In such a case, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL. If the scanned channel is available, a new channel-patient-drug relationship will be created. The channel scan step 5554 will be described in more detail below with reference to FIG.

If the channel scan step 5554 determines that the scanned channel is valid and available, at block 5556, the first central server 109 digitally assists the user with a screen prompting the user to program the pump channel. Display on 118. The 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5560, the first central server 109 determines if communication with the pump channel is functioning normally. For example, if the state information is not received from the channel within a predetermined time, the first central server 109 can determine that communication with the pump channel is not functioning normally.

At block 5562, if communication with the pump channel is not functioning properly, the first central server 109 displays a screen on the digital assistant 118 indicating that the prescription comparison cannot be made due to the loss of communication with the pump channel. Display. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5560, the first central server 109 rechecks if communication with the pump channel is functioning normally.

If communication with the pump channel is functioning normally, at block 5564, the first central server 109 determines if any data associated with this channel is missing. For example, if the expected serial number is missing in the status information received from the channel, the first central server 109 can determine that the data associated with this channel is missing. If the 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 made due to the lack of channel data. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5560, the first central server 109 rechecks if communication with the pump channel is functioning normally.

If no channel data is missing, at block 5568, the first central server 109 determines if the channel is already up and running. For example, the first central server 109 can determine whether the pump channel is in operation by reading the state information received from the channel. If the channel is already up and running, at block 5570, the first central server 109 causes the digital assistant 118 to display a screen indicating that the prescription comparison cannot be made because the channel is already up and running. FIG. 42 shows an example of the digital assistant display 118a showing that the prescription comparison cannot be performed. The digital assistant display 118a can also indicate that the user must press a particular key (eg, start) on the pump 120. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5571, the first central server 109 rechecks if communication with the pump channel is functioning normally.

At block 5574, if communication with the pump channel is not functioning properly, the first central server 109 displays a screen on the digital assistant 118 indicating that the prescription comparison cannot be made due to the loss of communication with the pump channel. Display. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5574, the first central server 109 rechecks if communication with the pump channel is functioning normally. At block 5576, the first central server 109 performs the requested prescription comparison if communication with the pump channel is functioning normally.

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 velocity information. If the pump channel is not configured to send speed information, at block 5580, the first central server 109 will not be able to make a prescription comparison because the channel is not sending speed information. Is displayed on the digital assistant 118. FIG. 41 shows an example of the digital assistant display 118a showing that the prescription comparison cannot be performed. The digital assistant display 118a can also indicate that the user must press a particular key (eg, speed) on the pump 120. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5571, the first central server 109 rechecks if communication with the pump channel is functioning normally. At block 5576, the first central server 109 performs the requested prescription comparison when the pump channel is configured to transmit velocity information.

As part of the prescription comparison, the first central server 109 uses the channel identifier acquired by the channel scan step 5554 and the patient identifier transmitted by the second central server 108a to use one drug identifier in the database ( Alternatively, if both the primary drug 124 and the piggyback drug 124 are associated with this channel, the two drug identifiers) are searched. At block 5582, one or more drug identifiers from the database are then compared to the scanned (or manually entered) drug identifier. If one or more drug identifiers from the database do not match the scanned (or manually entered) drug identifier, at block 5584, the first central server 109 causes the digital assistant 118 to display a drug invalidation notification. .. For example, Digital Assistant 118 displays a message that the scanned drug 124 is not associated with the scanned channel, and the actual drug 124 assigned to the scanned channel (primary and piggy, if applicable). Both back) can be shown. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5571, the first central server 109 rechecks if communication with the pump channel is functioning normally.

As an additional part of the prescription comparison, the first central server 109 uses the channel identifier acquired by the channel scan step 5554 and the patient identifier transmitted by the second central server 108a to retrieve the dosing rate in the database. .. At block 5584, the dosing rate from the database is then compared to the actual rate received from the pump channel. If the dosing 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 speed mismatch notification. FIG. 40 shows an example of the digital assistant display 118a having a discrepancy notification. For example, the digital assistant 118 may display a message indicating that the speed of the channel should be adjusted and indicate the correct value. Again, the 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 in block 5558 and a second cancel code in block 5552 via the cancel URL. It will be returned to the central server 108a. If the user presses the "Compare" button, at block 5571, the first central server 109 rechecks if communication with the pump channel is functioning normally.

In addition, the digital assistant display 118a may include an "accept mismatch" button. If the user presses the "accept mismatch" button, at block 5588, the first central server 109 returns the mismatch code and the unmatched speed to the second central server 108a via the completion URL. If at block 5584 the dosing 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. FIG. 39 shows an example of the digital assistant display 118a having a match notification. 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 scan process (for injection implementation process))
FIG. 56 shows an example of the channel scan step 5554 used above with reference to FIG. 55. Typically, the channel scan step 5554 scans the machine-readable identifier associated with the pump channel to determine if the scanned channel is available (eg, assigned to the current patient 112 but not used). Encourage the user to make a decision. If the scanned channel is not available, the "inject" operation is canceled. In such a case, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL. If the scanned channel is available, a new channel-patient-drug relationship will be created.

More specifically, exemplary channel scanning step 5554 first presents a screen prompting the user to select a subchannel (eg, primary or piggyback) at block 5602 and scan the machine-readable identifier associated with the channel. Starts when the central server 109 of the is displayed on the digital assistant 118. FIG. 38 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with a channel. For example, the user can use the scanner of Digital Assistant 118 to scan the barcode label associated with the channel. Alternatively, the user can manually enter the channel identifier in Digital Assistant 118. Further, the user may choose to omit the scanning step that causes the return to the second central server 108a via the completion URL, and may choose to omit the return to the second central server 108a via the cancellation URL. You may choose to cancel the scan that causes the.

Then, at block 5604, the channel identifier is sent to the first central server 109 for verification. The first central server 109 then attempts to retrieve the channel identifier in the database. If the channel identifier does not exist as a valid channel identifier in the database (eg, not properly formatted, not set in the first central server 109, etc.), at block 5606, the first central server 109 , Display the channel invalidation notification on the digital assistant 118. For example, the digital assistant 118 can display a message that the channel is not set in the first central server 109 and allows the user to rescan the channel identifier or cancel the operation. Can be included. If the user chooses to cancel the operation, it is preferred that in block 5608, the first central server 109 sends the 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 search the database for the patient identifier. 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 (ie, the channels are assigned to patients 112 with different channels), at block 5612, the first central server 109 checks the database. And check if the channel is up (in primary and / or piggyback mode).

If the channel is up, at block 5614, the first central server 109 is associated with a channel that has a different patient 112 scanned and is "non-overwritable" to indicate that the channel is currently up. Display the error message on Digital Assistant 118. The message can also include data indicating patient 112 (eg, patient's name), primary agent 124, and / or piggyback agent 124 associated with the scanned channel. The user is preferably given the option to undo or rescan. If the user chooses to cancel the operation, in block 5608, the first central server 109 sends the 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 will select a subchannel (eg, primary or piggyback) and scan the machine-readable identifier associated with that channel. Display the screen prompting the user on the digital assistant 118.

If the channel is not up, at block 5616, the first central server 109 has an "overwrite continue" warning indicating that a different patient 112 is associated with the scanned channel but that channel is not currently up. Display the message on Digital Assistant 118. This warning message preferably indicates that continuation will overwrite existing data (eg, disassociate with another patient 112). The warning message can also include data indicating patient 112 (eg, patient's name), primary agent 124 and / or piggyback agent 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, in block 5608, the first central server 109 sends the 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 will select a subchannel (eg, primary or piggyback) and scan the machine-readable identifier associated with that channel. Display the screen prompting the user on the digital assistant 118. FIG. 38 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with a channel. If the user chooses to continue, at block 5618, the first central server 109 will generate a new channel-patient-drug relationship and the new channel-patient-drug relationship will be updated with the latest "web session". Store in. If this new channel-patient-drug relationship is ultimately retained, as detailed above, in block 5540 of FIG. 55, the first central server 109 will have the new channel-patient-drug relationship. Commits to the database of the first central server 109.

If a valid patient identifier exists in the database and the two patient identifiers match in block 5620 (ie, that channel is assigned to this patient 112), the first central server 109 is in block 5622. , Check the database to see if the subchannel is free. In other words, the first central server 109 checks that there is no primary injection associated with this channel if the primary subchannel is selected in block 5602, and the piggyback subchannel is selected in block 5602. Check for no piggyback injection associated with this channel if done. If the subchannel is free, at block 5618, the first central server 109 creates a new channel-patient-drug relationship and the new channel-patient-drug relationship in the latest "web session". Store in. If the subchannel is not free, at block 5624, the first central server 109 checks the database to see if the subchannel is up (in primary and / or piggyback mode).

If this subchannel is up, at block 5626, the first central server 109 indicates that this patient 112 is already associated with the scan channel and that the selected subchannel is currently up. Display the "Cannot Overwrite" error message on Digital Assistant 118. The error message may also include data indicating patient 112 (eg, patient's name), primary agent 124, and / or piggyback agent 124. The user is preferably given the option to undo or rescan. If the user chooses to cancel the operation, in block 5608, the first central server 109 sends the 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 will select a subchannel (eg, primary or piggyback) and scan the machine-readable identifier associated with that channel. Display the screen prompting the user on the digital assistant 118.

If the subchannel is not up, at block 5628, the first central server 109 indicates that this patient 112 is associated with the scanned channel but the selected subchannel is not currently up. Display the "Continue" message on Digital Assistant 118. The error message may also include data indicating patient 112 (eg, patient's name), primary agent 124, and / or piggyback agent 124. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, in block 5608, the first central server 109 sends the 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 will select a subchannel (eg, primary or piggyback) and scan the machine-readable identifier associated with that channel. Display the screen prompting the user on the digital assistant 118. If the user chooses to continue, at block 5618, the first central server 109 creates a new channel-patient-drug relationship and the new channel-patient-drug relationship is the latest "web session". Store in. When the user presses Continue again, the first central server 109 returns control to the latest operation (eg, injection execution).

(Pump channel change process)
FIG. 57A shows an example of the pump channel changing step 5700. The pump channel change step 5700 can be used to change an infusion from one pump channel to another (eg, by a nurse) without losing the channel-patient-drug relationship in the database. Typically, the pump channel change step 5700 is information indicating that the pump channel change step will be performed, information identifying which patient 112 will be affected (eg, patient ID), and the patient 112 thereof. An input containing information (eg, RxID) identifying which agent 124 for which is to be affected is received from an electronic device such as the Digital Assistant 118. Then, step 5700 transmits this information to the first central server 109, and the first central server 109 confirms that the channel identifier information matches the pump channel change order information.

More specifically, the exemplary pump channel change step 5700 begins at block 5702 when the second central server 108a causes the digital assistant 118 to display a list of patients for selection. FIG. 24 shows an example of a digital assistant display 118a showing a list of patients. The list of patients is preferably limited to the patients associated with the user (eg, clinician 116) logged in to the digital assistant 118 at that time. Once the user has selected patient 112, information identifying the selection and / or 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 can be via any suitable communication channel such as the wireless / wired network 102 described above. Then, at block 5704, the second central server 108a causes the digital assistant 118 to display a list of operations. FIG. 25 shows an example of the digital assistant display 118a showing a list of operations. The list of movements is preferably limited to the movements associated with the selected patient 112. For example, the "change pump channel" operation could only be performed if the injection 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 digitally assists the user with a screen prompting the user to scan the machine-readable identifier associated with the agent 124 affected by this "change pump channel" operation. Display on 118. FIG. 34 shows an example of a digital assistant display 118a that prompts the user to scan the machine-readable identifier associated with the agent 124. The user can use the scan of the digital assistant 118 to scan the drug label 124a (eg, the barcode on the infusion bag) on the bag of the drug 124. Alternatively, the user can manually enter the drug identifier in Digital Assistant 118.

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

If the drug identifier (eg, bag ID) is present in the database as a valid drug identifier in block 5708, the second central server 108a transmits an XML document "changing the pump channel" to the first central server 109. .. The "changing pump channel" XML document includes a patient identifier (eg selected from the list of blocks 5702), a drug identifier (eg bag ID), a completion URL, and a cancellation URL. The completion URL is a network address used when the "change pump channel" operation is attempted. The cancellation URL is a network address used when the operation of "changing the pump channel" fails.

Once the first central server 109 receives the "pump channel change" XML document, at block 5724, the first central server 109 determines if the "pump channel change" XML document is valid. For example, the first central server 109 can check if any data normally expected in the "pump channel change" XML document is missing from the received "pump channel change" XML document. If the first central server 109 determines that the "pump channel change" XML document is not valid, at block 5726, the first central server 109 was unable to perform the "pump channel change" operation. Display the error message shown to the user on Digital Assistant 118. This display can include reasons such as which 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 the failure code to the second central server 108a via the cancellation URL.

If the first central server 109 determines that the "change pump channel" XML document is valid, the first central server 109 initiates the channel scan step 5730. This channel scanning step 5730 is associated with the "old" channel (ie, the user is trying to move from the "old" channel to the "new" channel). Typically, the channel scanning step 5730 prompts the user to scan the machine-readable identifier associated with the "old" pump channel and determines if the scanned channel is associated with the patient and drug identifiers (FIG. 58). As described in more detail below). If the scanned channel is not associated with a patient identifier and a patient identifier, the "change pump channel" action is canceled. In such a case, at block 5728, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the old channel is valid), at block 5732, the first central server 109 will see the patient 112, the old channel of the primary infusion, and the piggyback infusion. Display a message indicating the old channel of the digital assistant 118. The digital assistant 118 preferably displays a "continue" button and a "cancel" button as well as a message indicating that both injections (primary and piggyback) have been moved by this operation. When the user presses the "Cancel" button, at block 5728, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the user presses the "Continue" button, the first central server 109 initiates another channel scan step 5734. This channel scanning step 5734 is associated with the "new" channel (ie, the user is trying to move from the "old" channel to the "new"). Normally, channel scanning step 5734 prompts the user to scan the machine-readable identifier associated with the "new" pump channel and whether the scanned channel is available (eg, assigned to any patient 112). No, assigned to the current patient 112 but not used, assigned to another patient 112 and overwritten, etc.). If the scanned channel is not available, the "change pump channel" action is canceled. In such a case, at block 5728, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL. The channel scan step 5734 will be described in more detail below with reference to FIG. 59.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, a new channel is valid), at block 5736, the first central server 109 is currently in this new infusion of any other. Determine if it is not associated with any channel. If another injection is already associated with the new channel, at block 5738, the first central server 109 will send a message to the user indicating that another injection is currently associated with the new channel. Have Digital Assistant 118 display a message asking if she wants to overwrite the current injection. This message preferably includes a "Yes" button, a "No" button, and a "Cancel" button. When the user presses the "Cancel" button, at block 5728, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL. If the user presses the "No" button, the first central server 109 initiates another channel scan step 5834.

If the user presses the "No" button, at block 5740, the first central server 109 attempts to break the channel-patient-drug relationship in the database for this new channel. If at block 5742 the attempt to break the channel-patient-drug relationship in the database for the new channel was unsuccessful, at block 5744 the first central server 109 associates the patient identifier, the unmoved primary infusion. Causes Digital Assistant 118 to display a "change pump channel" error message containing the drug identifier (if applicable) that was used and the drug identifier (if applicable) associated with the piggyback infusion that was not moved. .. Once the user accepts the "Pump Channel Change" error message by pressing the "OK" button, at block 5746, the first central server 109 sends a failure code to the second central server 108a via the completion URL. Return to.

At block 5748, if another infusion was not already associated with the new channel at block 5736, or if the attempt to break the channel-patient-drug relationship in the database for the new channel at block 5742 was successful. 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 to move the channel-patient-drug relationship in the database from the old channel to the new channel is unsuccessful at block 5750, the first central server 109 displays a "pump channel change" error message to the digital assistant 118. Let me.

If the attempt to move the channel-patient-drug relationship in the database from the old channel to the new channel is successful at block 5750, at block 5725 the first central server 109 is associated with the patient identifier, the moved primary infusion. Display the Digital Assistant 118 with a "change pump channel" success message containing the drug identifier (if applicable) and the drug identifier associated with the moved piggyback infusion (if applicable). This display preferably also includes a message to the user to move the tube to a new channel. Once the user accepts the "pump channel change" success message by pressing the "OK" button, at block 5746, the first central server 109 has a success code to the second central server 108a via the completion URL. Will be returned.

(Channel scan process)
FIG. 58 shows an example of the channel scan step 5730 used above with reference to FIG. 57. Typically, the channel scanning step 5730 prompts the user to scan the machine-readable identifier associated with the pump channel and determines if the scanned channel is associated with a pre-scanned patient and drug identifier. If the scanned channel is not associated with these patient and drug identifiers, the current action (eg, stop, stop, restart, channel change, pump removal, etc.) is canceled.

More specifically, in the exemplary channel scanning step 5730, when 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 at block 5802. To start. FIG. 38 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with a channel. For example, the user can use the scanner of Digital Assistant 118 to scan the barcode label associated with the channel. Alternatively, the user can manually enter the channel identifier in Digital Assistant 118.

Then, at block 5804, the channel identifier is sent to the first central server 109 for verification. The first central server 109 then attempts to retrieve the channel identifier in the database. If the channel identifier does not exist as a valid channel identifier in the database (eg, not properly formatted, not set in the first central server 109, etc.), then in block 5806, the first central server 109 , Display the channel invalidation notification on the digital assistant 118. For example, the digital assistant 118 can display a message that the channel is not set in the first central server 109 and allows the user to rescan the channel identifier or cancel the operation. Can be included. If the user chooses to cancel the operation, it is preferred that in block 5808, the first central server 109 sends the 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 search the database for the patient identifier. At block 5810, the patient identifier from the database is then 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 invalidation notification. For example, the digital assistant 118 may display a message that the scanned patient 112 is not associated with the scanned channel, indicating the actual patient 112 assigned to the scanned channel. Again, the PDA display can include a button that allows the user to rescan the channel identifier or undo the operation. If the user chooses to cancel the operation, it is preferred that in block 5808, the first central server 109 sends the 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 have one drug identifier (or both the primary drug 124 and the piggyback drug 124) in the database. If associated with this channel, search for two drug identifiers). Then, in block 5814, one or more drug identifiers from the database are compared to the scanned (or manually entered) drug identifier. 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 invalidation notification. .. For example, Digital Assistant 118 displays a message that the scanned drug 124 is not associated with the scanned channel and the actual drug 124 assigned to the scanned channel (primary and piggyback, if applicable). Both) can be shown. Again, the PDA display can include a button that allows the user to rescan the channel identifier or undo the operation. If the user chooses to cancel the operation, it is preferred that in block 5808, the first central server 109 sends the cancellation code to the second central server 108a via the cancellation URL.

If a valid channel-patient-drug relationship is established, at block 5818, the first central server 109 indicates that a valid channel scan was performed without issuing an additional display on the digital assistant 118. , Return control to the latest operation (eg dosing, stopping, discontinuing, resuming, channel change, pump removal, etc.).

(Channel scan process (new channel))
FIG. 59 shows an example of the channel scan step 5734 used above with reference to FIG. 57. Typically, channel scanning step 5734 prompts the user to scan the machine-readable identifier associated with the pump channel and the scanned channel is available (eg, assigned to current patient 112 but used). No) is determined. If the scanned channel is not available, the current action (eg channel change) is canceled.

More specifically, when the exemplary channel scanning step 5734 causes the digital assistant 118 to display a screen at block 5902 prompting the user to scan the machine-readable identifier associated with the channel by the first central server 109. To start. FIG. 38 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with a channel. For example, the user can use the scanner of Digital Assistant 118 to scan the barcode label associated with the channel. Alternatively, the user can manually enter the channel identifier in Digital Assistant 118.

Then, at block 5904, the channel identifier is sent to the first central server 109 for verification. The first central server 109 then attempts to retrieve the channel identifier in the database. If this channel identifier does not exist as a valid channel identifier in the database (eg, not properly formatted, not set in the first central server 109, etc.), then in block 5906, the first central server 109 Displays a channel invalidation notification on the digital assistant 118. For example, the digital assistant 118 can display a message that the channel is not set in the first central server 109 and allows the user to rescan the channel identifier or cancel the operation. Can be included. If the user chooses to cancel the operation, it is preferred that in block 5908 the first central server 109 sends the 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 search the database for the patient identifier. 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 (ie, the channels are assigned to patients 112 with different channels), at block 5912, the first central server 109 checks the database. Check if this channel is up (in primary and / or piggyback mode).

If the channel is up, at block 5914, the first central server 109 will indicate that a different patient 112 is associated with the scanned channel and that the channel is currently up. Display an error message on Digital Assistant 118. The error message can also include data indicating the patient 112 associated with the scanned channel (eg, patient name), primary agent 124, and / or piggyback agent 124. The user is preferably given the option to undo or rescan. If the user chooses to cancel the operation, in block 5908, the first central server 109 sends the 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 up, at block 5916, the first central server 109 has an "overwrite continue" warning indicating that a different patient 112 is associated with the scanned channel but that channel is not currently up. Display the message on Digital Assistant 118. This warning message preferably indicates that continuing will overwrite existing data (eg, disassociate with another patient 112). The warning message can also include data indicating the patient 112 associated with the scanned channel (eg, patient name), primary agent 124, and / or piggyback agent 124. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, in block 5908, the first central server 109 sends the 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 permits the use of the selected channel. When the user presses "continue", the first central server 109 returns control to the latest operation (eg, dosing, channel change, etc.) without issuing additional indications to the digital assistant 118.

If a valid patient identifier exists in the database at block 5920 and the two patient identifiers match (ie, the channel is assigned to this patient 112), the first central server 109 is at block 5922. Check the database to see if the channel is free (eg, neither primary injection nor piggyback injection is 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 permits the use of 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 up (in primary and / or piggyback mode).

If this channel is up, at block 5926, the first central server 109 will "overwrite" to indicate that this patient 112 is associated with a channel that has already been scanned and that the channel is currently up. Display the "impossible" error message on Digital Assistant 118. The error message may also include data indicating patient 112 (eg, patient's name), primary agent 124, and / or piggyback agent 124. The user is preferably given the option to undo or rescan. If the user chooses to cancel the operation, in block 5908, the first central server 109 sends the 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 up, at block 5928, the first central server 109 will indicate a "continue" message that this patient 112 is associated with the scanned channel but that channel is not currently up. Is displayed on the digital assistant 118. The message may also include data indicating patient 112 (eg, patient's name), primary agent 124, and / or piggyback agent 124. The user is preferably given the option to cancel, rescan, or continue. If the user chooses to cancel the operation, in block 5908, the first central server 109 sends the 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 permits the use of the selected channel. When the user presses Continue again, the first central server 109 returns control to the latest operation (eg, channel change) without issuing an additional display to the digital assistant 118.

(Injection stop / stop process)
FIG. 60 shows an example of the injection stop / stop step 6000. The injection stop / stop step 6000 can be used to temporarily stop (ie stop) the injection or completely stop (ie end) the injection step. Typically, the infusion stop / stop step 6000 is information about whether the stop or stop will be performed, information identifying which patient 112 will be affected (eg, patient ID), and the patient thereof. An input containing information (eg, RxID) identifying which agent 124 for 112 will be stopped or discontinued is received from an electronic device such as the Digital Assistant 118. Step 6000 then sends this information to the first central server 109, which confirms that the channel identification information matches the stop / stop order information, and the correct injection is stopped. Or confirm that it will be canceled.

More specifically, the exemplary injection stop / stop step 6000 begins at block 6002 when the second central server 108a causes the digital assistant 118 to display a list of patients. FIG. 24 shows an example of a digital assistant display 118a showing a list of patients. The list of patients is preferably limited to the patients associated with the user (eg, clinician 116) logged in to the digital assistant 118 at that time. Once the user has selected patient 112, information identifying the selection and / or 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 can be via any suitable communication channel such as the wireless / wired network 102 described above. Then, at block 6004, the second central server 108a causes the digital assistant 118 to display a list of operations. FIG. 25 shows an example of the digital assistant display 118a showing a list of operations. The list of movements is preferably limited to the movements associated with the selected patient 112. For example, the "stop injecting" and "stop injecting" actions will only be available if the infusion associated with this patient 112 is currently in the running state.

When the user selects an "injection stop" operation or an "injection stop" operation from the list of operations, information identifying the selected operation is transmitted to the second central server 108a. In response, at block 6006, the second central server 108a should describe all in-flight infusions for that patient 112 and scan the machine-readable identifier associated with the drug 124 to be stopped or discontinued. Display a screen prompting the user on the digital assistant 118. FIG. 34 shows an example of a digital assistant display 118a that prompts the user to scan the machine-readable identifier associated with the agent 124. The user can use the scanner of the digital assistant 118 to scan the drug label 124a (eg, the barcode on the infusion bag) on the bag of the drug 124. Alternatively, the user can manually enter the drug identifier into Digital Assistant 118.

Then, in block 6008, the drug identifier is transmitted to a second central server 108a for verification. The second central server 108a attempts to retrieve the drug identifier in the database. If the drug identifier (eg, bag ID) does not exist as a valid drug identifier in the database, at block 6010, the second central server 108a causes the digital assistant 118 to display the item invalidation notification. Once the user accepts the item invalidation notification (or the notification times out), at block 6006, the digital assistant 118 prompts the user to scan the machine-readable identifier associated with the drug 124 to be stopped or discontinued. Redisplay.

If the drug identifier (eg, bag ID) is present in the database as a valid drug identifier in block 6008, the second central server 108a is to scan the user at block 6012 for the machine-readable identifier associated with patient 112. Display a screen prompting the digital assistant 118. FIG. 36 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with patient 112. The user can use the scanner of Digital Assistant 118 to scan the barcode label on the patient's wristband 112a. Alternatively, the user can manually enter the patient identifier in Digital Assistant 118. Then, at block 6014, the patient identifier is transmitted to a second central server 108a for verification. The second central server 108a then attempts to retrieve the patient identifier in the database. If the patient identifier (eg, wristband ID) does not exist as a valid patient identifier in the database, at block 6016, the second central server 108a causes the digital assistant 118 to display the patient invalidation notification. Once the user accepts the patient invalidation 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.

If a patient identifier (eg, wristband ID) is present in the database as a valid patient identifier in block 6014, the second central server 108a is directed against a code indicating the reason for the "stop infusion" or "stop infusion" action. Can also encourage users. If this reason code is not provided, the system preferably displays a message to the user that the reason code must be provided. Further, the second central server 108a can time stamp the order and / or prompt the user for the time when this operation should be performed. Further, it is preferable that the second central server 108a checks the state of the injection order and determines whether the injection order is active or decommissioned.

If the injection order is active, at block 6018, is the second central server 108a attempting to issue a "stop injection" or "stop injection" action based on the user selection from block 6004? Judge whether or not. If the user is attempting to issue an "injection stop" operation, at block 6020, the second central server 108a sets "DCFlag" in the "injection stop" XML document to "FALSE". If the user is attempting to issue an "injection stop" operation, at block 6022, the second central server 108a sets "DCFlag" in the "injection stop" XML document to "TRUE". Of course, any well-known method of displaying the state of a variable can be used.

An "injection stop" XML document containing a patient identifier (eg, wristband ID), drug identifier (eg, bag ID), completion URL, cancellation URL, and DCFlag (indicating stop vs. stop) is then centered first. It is transmitted to the server 109. The completion URL is a network address used when the injection is successfully stopped or stopped. The cancellation URL is a network address used when the "injection stop" operation or the "injection stop" operation fails or is canceled.

Once the first central server 109 receives the "stop injection" XML document, at block 6024, the first central server 109 determines if the "stop injection" XML document is valid. For example, the first central server 109 can check if any data normally expected in an "injection stop" XML document is missing from the received "injection stop" XML document. If the first central server 109 determines that the "injection stop" XML document is not valid, at block 6026, the first central server 109 may perform an "injection stop" or "injection stop" operation. Display an error message to the user indicating that the failure was not possible in Digital Assistant 118. This indication can include reasons such as which data was missing from the "stop injection" XML document. After the user presses the "OK" button to accept the error message, at block 6028, the first central server 109 returns the failure code to the second central server 108a via the cancellation URL.

If the first central server 109 determines that the "stop injection" XML document is valid, the first central server 109 initiates the channel scan step 5730. Typically, the channel scan step 5730 prompts the user to scan the machine-readable identifier associated with the pump channel that is currently performing the infusion that will be stopped or stopped, and the scanned channel becomes the patient and drug identifier. Determine if they are associated (as detailed above with reference to FIG. 58). If the scanned channel is not associated with a patient identifier and a drug identifier, the "stop infusion" or "stop infusion" action is canceled. In such a case, in block 6028, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the channel is valid), at block 6032, the first central server 109 will have the patient 112 and the drug 124 and drug 124 to be stopped. Display the Digital Assistant 118 with a message indicating the injection to be stopped, including details of the existing channel. The PDA display preferably also includes a "continue" button and a "cancel" button. In this way, the user can manually stop the displayed injection and then press the "Continue" button to check if the correct injection was actually stopped or stopped. Can be notified to. Alternatively, the user can also press the "Cancel" button, at which point the first central server 109 returns the cancellation code to the second central server 108a at block 6028 via the cancellation URL. do.

If the user presses the "Continue" button, at block 6034, the first central server 109 will read the state information sent by the pump 120 to the first central server 109 to determine if the injection has been stopped. to decide. If the pump 120 is unable to communicate with the first central server 109, the first central server 109 will generate a loss of communication events for that channel. If communication with a channel is lost, the state of injection on that channel cannot be changed to "stop" or "stop" until communication with that channel is restored. If communication is functioning normally but the infusion is not stopped, at block 6036, the first central server 109 indicates that the infusion was not stopped and a warning message indicating patient 112 and the infusion to be stopped. 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 injection was actually stopped or stopped. When the user presses the "Cancel" button, at block 6028, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If injection is stopped at block 6034, at block 6038 the first central server 109 checks whether this is an "injection stop" or "injection stop" operation. For example, the first central server 109 can check the status of flags such as DCFlag set by block 6020 or block 6022. If this is an "injection stop" operation (ie, injection pause), at block 6044, the first central server 109 sends the success code and DCFlag- = FALSE to the second central server 108a via the completion URL. I will send it back.

Instead, if this is a "stop infusion" action (ie, end of infusion), at block 6040, the first central server 109 is a patient identifier, drug for infusions that are temporary or piggyback infusions, but not preferably both. It is preferable to try to break the database association between the identifier and the channel identifier. If the user wants to stop or stop both the primary and piggyback injections running on one channel, the user performs two "stop injection" or "stop injection" operations, once for each injection. Can be executed. If the first central server 109 is unsuccessful in disassociating the database in block 6042, in block 6028 the first central server 109 sends the failure code to the second central via the revocation URL. It will be returned to the server 108a. If the first central server 109 succeeds in disassociating the database in block 6042, then in block 6044 the first central server 109 sets the success code and DCFlag = TRUE to the second via the completion URL. It is returned to the central server 108a of.

The first central server 109 disassociates between the patient identifier, drug identifier, and channel identifier for the selected injection only if the "injection discontinuation" operation is successful. In all other cases, this association is maintained. For example, if the "stop infusion" operation succeeds or the "stop infusion" operation fails, the patient identifier, drug identifier, and association between channels are maintained. Similarly, the second central server 108a only receives the success code from the first central server 109 and at the same time updates the injection status to "stopped" or "stopped". Any other result (eg, cancellation code or failure code) causes the second central server 108a to keep the injection in its previous state. At any time in step 6000, the user preferably has the option of canceling step 6000. The stop / stop step can be used to document that the infusion has been resumed for MAR purposes.

(Injection restart process)
FIG. 61 shows an example of the injection restart step 6100. The injection restart step 6100 can be used to restart a stopped (ie, paused) injection step. However, the injection resumption step 6100 cannot be used to resume the aborted (ie, terminated) injection process. Typically, the infusion resumption step 6100 is information indicating that the resumption step will be performed, information identifying which patient 112 will be affected (eg, patient ID), and which for that patient 112. An input containing information (eg, RxID) identifying whether the agent 124 will be restarted is received from an electronic device such as the Digital Assistant 118. Step 6100 then sends this information to the first central server 109, which confirms that the channel identification information matches the resume order information, and the correct injection is resumed. Make sure that.

More specifically, the exemplary injection resumption step 6100 begins at block 6102 when the second central server 108a causes the digital assistant 118 to display a list of patients. FIG. 24 shows an example of a digital assistant display 118a showing a list of patients. The list of patients is preferably limited to the patients associated with the user (eg, clinician 116) logged in to the digital assistant 118 at that time. Once the user has selected patient 112, information identifying the selection and / or 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 can be via any suitable communication channel such as the wireless / wired network 102 described above. Then, at block 6104, the second central server 108a causes the digital assistant 118 to display a list of operations. FIG. 25 shows an example of the digital assistant display 118a showing a list of operations. The list of movements is preferably limited to the movements associated with the selected patient 112. For example, the "restart injection" operation will only be available if the injection associated with this patient 112 is currently in a stopped state.

When the user selects the "injection resume" 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 drug 124 to be restarted. FIG. 34 shows an example of a digital assistant display 118a that prompts the user to scan the machine-readable identifier associated with the agent 124. The user can use the scanner of the digital assistant 118 to scan the drug label 124a (eg, the barcode on the infusion bag) on the bag of the drug 124. Alternatively, the user can manually enter the drug identifier in Digital Assistant 118.

Then, in block 6108, the drug identifier is transmitted to a second central server 108a for verification. The second central server 108a attempts to retrieve the drug identifier in the database. If the drug identifier (eg, bag ID) does not exist as a valid drug identifier in the database, at block 6110, the second central server 108a causes the digital assistant 118 to display the item invalidation notification. Once the user accepts the item invalidation notification (or the notification times out), at block 6106, the digital assistant 118 redisplays the screen prompting the user to scan and resume the machine-readable identifier associated with the drug 124. indicate. If the user scans the machine-readable identifier associated with the drug 124 to be resumed but the drug 124 has been discontinued, the second central server 108a may resume the drug 124 due to its discontinued state. It is preferable to display a message to the user indicating that the digital assistant 118 cannot be used.

If in block 6108 a drug identifier (eg, bag ID) is present as a valid drug identifier in the database but has not been discontinued, in block 6112 the second central server 108a has a machine-readable identifier associated with patient 112. Display a screen on the Digital Assistant 118 that prompts the user to scan. FIG. 36 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with patient 112. The user can use the scanner of Digital Assistant 118 to scan the barcode label on the patient's wristband 112a. Alternatively, the user can manually enter the patient identifier in Digital Assistant 118. Then, at block 6114, the patient identifier is transmitted to the second central server 108a for verification. The second central server 108a then attempts to retrieve the patient identifier in the 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 the patient invalidation notification. Once the user accepts the patient invalidation 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 a patient identifier (eg, wristband ID) is present as a valid patient identifier in the database, the second central server 108a prompts the user for a code indicating the reason for the "restart injection" operation. You can also. If the reason code is not provided, the system preferably displays a message to the user that the reason code must be provided. Further, the second central server 108a can time stamp the order and / or prompt the user for the time when the operation should be performed. Further, it is preferable that the second central server 108a checks the state of the injection order and determines whether the injection order is active or decommissioned.

When the injection order is active, the second central server 108a transmits the "injection resume" XML document to the first central server 109. The "injection resume" XML document includes a patient identifier (eg, wristband ID), a drug identifier (eg, bag ID), a completion URL, and a cancellation URL. The completion URL is a network address used when the injection is successfully restarted. The cancel URL is a network address used when the "restart injection" operation fails or is cancelled.

Once the first central server 109 receives the "injection resume" XML document, at block 6124, the first central server 109 determines if the "injection resume" XML document is valid. For example, the first central server 109 can check if any of the data normally expected in the "injection resume" XML document is missing from the received "injection resume" XML document. If the first central server 109 determines that the "injection resume" XML document is not valid, then in block 6126, the user indicates that the first central server 109 was unable to perform the "injection resume" operation. Is displayed on the digital assistant 118. This display can include reasons such as which data was missing from the "restart" XML document. After the user presses the "OK" button to understand the error message, at block 6128, the first central server 109 returns the failure code to the second central server 108a via the cancellation URL.

If the first central server 109 determines that the "injection resume" XML document is valid, the first central server 109 initiates the channel scan step 5730. Typically, channel scanning step 5730 prompts the user to scan the machine-readable identifier associated with the pump channel currently associated with the infusion to be resumed, and is the scanned channel associated with the patient and drug identifiers? Determine if (as detailed above with reference to FIG. 58). If the scanned channel is not associated with the patient and drug identifiers, the "restart infusion" operation is canceled. In such a case, in block 6128, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the channel is valid), at block 6132, the first central server 109 digitally assists the patient 112 and a message indicating the infusion to be resumed. Display on 118. The PDA display preferably also includes a "continue" button and a "cancel" button. In this method, the user can manually resume the displayed injection and then press the "Continue" button to notify the first central server 109 to check if the correct injection was actually resumed. Alternatively, the user can also press the "Cancel" button, at which point the first central server 109 returns the cancellation code to the second central server 108a at block 6128 via the cancellation URL. do.

If the user presses the "Continue" button, at block 6134, the first central server 109 will read the state information sent by the pump 120 to the first central server 109 to determine if the injection has resumed. judge. If the pump 120 is unable to communicate with the first central server 109, the first central server 109 will generate a communication loss event for that channel. If communication with a channel is lost, the injection state for that channel cannot be changed to "restarted" until communication with that channel is restored. If communication is functioning normally but the infusion is not resumed, at block 6136, the first central server 109 indicates that the infusion was not resumed and a warning message indicating patient 112 and the infusion to be resumed. Is displayed on the digital assistant 118. This 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 injection was actually resumed. When the user presses the "Cancel" button, at block 6128, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If injection is resumed in block 6134, in block 6144 the first central server 109 returns the success code to the second central server 108a via the completion URL. The first central server 109 maintains an association between the patient identifier, drug identifier, and channel identifier for the selected injection . The second central server 108a only updates the injection status to "running" at the same time as receiving the success code from the first central server 109. Any other result (eg, cancellation code or failure code) causes the second central server 108a to keep the injection in its previous state. Preferably, if the user wishes to resume both the primary and piggyback injections running on one channel, the user will perform the "restart injection" operation twice, once for each injection. can do. The resumption step can be used to document that the infusion has been resumed for the purposes of MAR.

(Pump removal process)
FIG. 62 shows an example of the pump removing step 6200. The pump removal step 6200 performs the channel-patient-drug relationship in the database of the first central server 109 independently of the existing infusion stop order in the pharmacy database and without going through the infusion stop / stop step 6000 described above. Can be used to terminate. Typically, the pump removal step 6200 is for information indicating that the pump removal step will be performed, information identifying which patient 112 will be affected (eg, patient ID), and for that patient 112. An input containing information (eg, RxID) indicating which agent 124 will be affected is received from an electronic device such as the Digital Assistant 118. Step 6200 then sends this information to the first central server 109, where the first central server 109 confirms that the channel identification information matches the pump removal order information, and the correct pump 120 removes. Make sure it is done.

More specifically, the exemplary pump removal step 6200 begins at block 6202 when the second central server 108a causes the digital assistant 118 to display a list of patients for selection. FIG. 24 shows an example of a digital assistant display 118a showing a list of patients. The list of patients is preferably limited to the patients associated with the user (eg, clinician 116) logged in to the digital assistant 118 at that time. Once the user has selected patient 112, information identifying the selection and / or 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 can be via any suitable communication channel such as the wireless / wired network 102 described above. Then, at block 6204, the second central server 108a causes the digital assistant 118 to display a list of operations. FIG. 25 shows an example of the digital assistant display 118a showing a list of operations. The list of movements is preferably limited to the movements associated with the selected patient 112. For example, the "pump removal" operation will only be available if the infusion associated with this patient 112 is currently listed in the database of first central server 109.

When the user selects a "pump removal" operation from the list of operations, information identifying the selected operation is sent to the second central server 108a. In response, at block 6206, the second central server 108a prompts the user to scan the machine-readable identifier associated with the agent 124 affected by this "pump removal" operation Digital Assistant 118. To display. FIG. 34 shows an example of a digital assistant display 118a that prompts the user to scan the machine-readable identifier associated with the agent 124. The user can use the scanner of the digital assistant 118 to scan the drug label 124a (eg, the barcode on the infusion bag) on the bag of the drug 124. Alternatively, the user can manually enter the drug identifier in Digital Assistant 118.

Then, at block 6208, the drug identifier is transmitted to a second central server 108a for verification. The second central server 108a (or digital assistant 118) checks if a properly formatted drug identifier has been received. Since the purpose of the "pump removal" operation is to remove from the database of the first central server 109 the associations that do not have a corresponding injection in the database of the second central server 108a, the second central server 108a It is preferable that it is not necessary to check if the drug identifier matches the current infusion in the database of the second central server 108a.

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

If the drug identifier (eg, bag ID) was properly formatted in block 6208, in block 6212 the second central server 108a prompts the user to scan the machine-readable identifier associated with patient 112. Display on Digital Assistant 118. FIG. 36 shows an example of a digital assistant display 118a that prompts the user to scan a machine-readable identifier associated with patient 112. The user can use the scanner of Digital Assistant 118 to scan the barcode label on the patient's wristband 112a. Alternatively, the user can manually enter the patient identifier in Digital Assistant 118. Then, at block 6214, the patient identifier is transmitted to the second central server 108a for verification. A second central server 108a (or digital assistant 118) then checks to see if a properly formatted patient identifier has been received. Since the purpose of the "pump removal" operation is to remove from the database of the first central server 109 the associations that do not have a corresponding injection in the database of the second central server 108a, the second central server 108a It is preferable that it is not necessary to check if the patient identifier matches the current infusion in the database of the second central server 108a. However, the second central server 108a (or digital assistant 118) can check if the patient identifier matches the patient 112 selected in 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 in block 6202, at block 6216, the second central server 108a will issue a patient invalidation notification. Display on Digital Assistant 118. Once the user accepts the patient invalidation 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 the patient identifier (eg, wristband ID) is properly formatted in block 6214 and matches the patient 112 selected in block 6202, then in block 6217 the second central server 108a is in the "alarm routing stop" XML. The document is transmitted to the first central server 109. The "alarm routing stop" XML document includes a patient identifier (eg, wristband ID), a drug identifier (eg, bag ID), a completion URL, and a cancellation URL. The completion URL is a network address used when the removal of the pump 120 is successful. The cancel URL is a network address used when the "pump removal" operation fails or is cancelled.

Once the first central server 109 receives the "alarm routing stop" XML document, at block 6224, the first central server 109 determines if the "alarm routing stop" XML document is valid. For example, the first central server 109 can check if any data normally expected in the "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 was unable to perform the "stop alarm routing" operation. Display an error message to the user in Digital Assistant 118. This display can include reasons such as which data was missing from the "alarm routing stop" XML document. After the user presses the "OK" button to accept the error message, at block 6228, the first central server 109 returns the failure code to the second central server 108a via the cancellation URL.

If the first central server 109 determines that the "alarm routing stop" XML document is valid, the first central server 109 initiates the channel scan step 5730. Typically, channel scanning step 5730 prompts the user to scan the machine-readable identifier associated with the pump channel currently associated with the pump 120 to be removed, and is the scanned channel associated with the patient 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 a drug identifier, the "pump removal" operation is canceled. In such a case, at block 6228, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the scanned channel is associated with a patient identifier and a drug identifier (ie, the channel is valid), at block 6232, the first central server 109 indicates the patient 112 and the infusion associated with this behavior. Display the message on Digital Assistant 118. The PDA display preferably also includes a "continue" button and a "cancel" button. In this way, the user can manually stop the displayed injection and then notify the first central server 109 to check if the correct injection was actually stopped by pressing the "Continue" button. .. Alternatively, the user can also press the "Cancel" button, at which point the first central server 109 sends the cancellation code to the second central server 108a at block 6228 via the cancellation URL. I will send it back.

If the user presses the "Continue" button, at block 6234, the first central server 109 will read the state information sent by the pump 120 to the first central server 109 to determine if the injection has been stopped. judge. If the injection was not stopped, at block 6236, the first central server 109 causes the digital assistant 118 to display a warning message indicating that the injection was not stopped. This display preferably also includes a "continue" button and a "cancel" button. When the user presses the "Cancel" button, at block 6228, the first central server 109 returns the cancellation code to the second central server 108a via the cancellation URL.

If the user presses the "Continue" button, in block 6240, the first central server 109 is preferably a patient identifier, a drug identifier, and a channel identifier for a primary or piggyback infusion, but not for both. Attempts to break the database association between identifiers. If the user wishes to stop the alarm routing associated with both the primary and piggyback injections running on one channel, the user performs a "pump removal" operation twice for each injection. It can be executed once. If the first central server 109 does not succeed in breaking the database association in block 6242, in block 6228 the first central server 109 sends a failure code to the second central server 108a via the cancellation URL. I will send it back. If the first central server 109 succeeds in breaking the database association in block 6242, in block 6244 the first central server 109 returns the 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 injection only if the "pump removal" operation is successful. Otherwise, this association is maintained. The second central server 108a does not need to update the state of the injection that was "released" when it received the success code from the first central server 109.

(Encrypted communication process)
As mentioned above, the system can include a plurality of digital assistants 118 and a plurality of medical devices (eg, an injection pump 120) communicating over a wired or wireless network. Since some of the transmitted data is confidential medical data, it is preferred that the data be communicated only to encrypted and authorized users and devices in a free environment. A start-up phase of the certification process can be performed to set up a new digital assistant 118 or medical device 120. Each time a commissioned device is strengthened, it is preferable to perform an authentication process to verify that communication with the authorized device and / or user is taking place. Once authorized by the device and / or user, it is encrypted to send parameters, instructions, data, alarms, status information, and any other kind of information between digital assistants, medical devices, and / or servers. One-way communication and / or two-way communication can be performed.

Referring to FIG. 63, the digital assistant use start stage (that is, the server registration stage) of the encrypted communication step 6300 starts when the first central server 109 generates the digital assistant user account (block 6302). For example, a digital assistant user account can be set up in a well-known way using Microsoft Active Directory. Then, at block 6304, the first central server 109 generates a digital certificate for the digital assistant 118. Digital certificates can be generated in any way. For example, a digital certificate can be generated by a well-known method on the first central server 109 using Microsoft Digital Certificate Services. The digital certificate preferably contains the public key of the digital assistant digitally signed with the private key of the first central server. In other words, the first central server 109 functions as a certification authority (CA) for the digital certificate of the digital assistant. 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 certificate of the digital assistant and the private key of the digital assistant are transmitted by the first central server 109 to the digital assistant 118 of block 6310. The digital certificate of the digital assistant and the private key of the digital assistant are preferably transmitted to the digital assistant 118 via an encrypted connection. For example, an RS-232 cable that is not connected to any other device can be used. Further, the digital certificate of the first central server is transmitted by the first central server 109 to the digital assistant 118 of block 6314 at block 6312. Again, the digital certificate of the first central server is preferably sent to the Digital Assistant 118 over 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 put into use (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. Further, each digital assistant 118 can have the same private key with different identification codes used to distinguish the digital assistants 118 from each other.

Each time the digital assistant 118 is powered on, the digital assistant 118 and the first central server 109 move from an unsecured wireless connection to an encrypted wireless connection. The certification process must be performed. In the illustrated example, the digital assistant 118 establishes an unencrypted 802.11 (Wireless Ethernet®) connection with the first central server 109 at blocks 6316 and 6318. Of course, any type of connection can be used, such as a wired connection or a connection using another protocol.

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

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

Then, 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. Digital assistant 118 receives a request from the first central server at block 6416. Digital Assistant 118 responds to a request to establish an encrypted connection at block 6418 by sending a copy of the Digital Assistant's digital certificate to the first central server 109. At block 6420, the first central server 109 receives the digital certificate of the digital assistant.

At block 6422, the first central server 109 authenticates the digital assistant 118 with the digital certificate of the digital assistant. The first central server 109 now knows that it is talking to the digital assistant 118 that is in use and can communicate with the digital assistant 118. Further moving to FIG. 65, the first central server 109 maps the sessions for the digital assistant's user account to the active directory in block 6502 to allow the digital assistant 118 to access the files. confirm.

Now that the Digital Assistant 118 is communicating with the first central server 109 over an encrypted connection, the Digital Assistant 118 is allowed to access certain files on the first central server 109. At block 6504, the digital assistant 118 can establish an encrypted communication session with the first central server 109 by accessing the URL retrieved from the digital certificate of the first central server. The first central server 109 also establishes an encrypted communication session at block 6506. Further, at block 6508, the application on the first central server 109 verifies that the digital assistant 118 belongs to the appropriate Active Directory.

The digital assistant 118 can now authenticate, but 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 may only be sent to certain users. Therefore, the application on the first central server 109 can request a username and password from the user of the digital assistant 118 at block 6510. Once the digital assistant 118 receives a request for a username and password in block 6512, in block 6514 the digital assistant 118 retrieves the username and password from the user via a prompt on the digital assistant display 118a. The username and password are then transmitted by the digital assistant 118 at block 6516 and received by the first central server 109 at block 6518. Then, at block 6520, the application on the first central server 109 can authenticate the user.

Once a user is authenticated on a server (eg, first central server 109), the credentials are used to automatically authenticate the digital assistant 118 on another server (eg, second central server 108a). Can be done. In one example, a user can only authenticate if the user is authenticated by both the first central server 109 and the second central server 108a. Therefore, whenever a username or password is generated or modified, it is preferred that the username and password be synchronized between the first central server 109 and the second central server 108a.

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

Moving on to FIG. 66, the medical device use start stage (ie, server registration stage) of step 6300 begins at block 6602 when the first central server 109 creates a medical device user account. For example, a user account for a medical device can be set up in a well-known manner using Microsoft Active Directory. Then, at block 6604, the first central server 109 generates a digital certificate for the medical device 120. Digital certificates can be generated in any way. For example, a digital certificate can be generated on a first central server 109 using Microsoft Digital Certificate Services in a well-known manner. The digital certificate preferably contains the public key of the medical device digitally signed with the private key of the first central server. In other words, the first central server 109 functions as a certification body (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 digital certificate of the medical device and the private key of the medical device are transmitted by the first central server 109 to the medical device 120 of the block 6610. The digital certificate of the medical device and the private key of the medical device are preferably transmitted to the medical device 120 via an encrypted connection such as an RS-232 cable that is not connected to any other device. Further, the digital certificate of the first central server 109 is transmitted by the first central server 109 to the medical device 120 of the block 6614 at the block 6612. Again, the digital certificate of the first central server is preferably transmitted to the 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 begins to be used (ie, registered with the server).

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

Each time the medical device 120 is turned on, the medical device 120 and the first central server 109 perform an authentication process to move from the unencrypted wireless connection to the 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 type 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 establish an encrypted connection to the first central server 109. The first central server 109, at block 6708, receives a medical device request to establish an encrypted connection. The first central server 109 is to establish an encrypted connection at block 6710 by sending a copy of the digital certificate of the first central server to the medical device 120 over the unencrypted connection. Respond to requests. At block 6712, the medical device 120 receives the digital certificate of the first central server.

At block 6714, the medical device 120 authenticates the first central server 109 with the digital certificate of the first central server. Further, at block 6716, the medical device 120 retrieves a unique resource locator (URL) associated with the embedded first central server 109 using the digital certificate of the first central server. The medical device 120 now knows that it is talking to a genuine 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 a request from the first central server at block 6720. The medical device 120 responds to a request to establish an 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 digital certificate of the medical device.

Moving to FIG. 68, at block 6802, the first central server 109 authenticates the medical device 120 using the digital certificate of the medical device. The first central server 109 now knows that it is talking to the medical device 120 that is in use and can communicate with the medical device 120. Further, the first central server 109 confirms the files that the medical device 120 is allowed to access by mapping the session for the medical device user account to the active directory in block 6804.

Since the medical device 120 is now communicating with the first central server 109 via an encrypted connection, the medical device 120 is allowed to access a particular file on the first central server 109. At block 6806, the medical device 120 can establish an encrypted communication session with the first central server 109 by accessing the URL retrieved from the digital certificate of the first central server. The first central server 109 also establishes an encrypted communication session at block 6808. Further, at block 6810, the application on the first central server 109 verifies that the medical device 120 belongs to the appropriate Active Directory.

The medical device 120 can now be authenticated, but 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 the medical device 120. This can be important for some applications, as some users may have different access rights than others. In addition, medical devices can have different "roles". For example, a medical device can have a role of "one-way communication" or a role of "two-way communication". In this way, the medical device 120 capable of bidirectional communication can be placed in a system that requires only one-way communication equipment. Similarly, a system capable of supporting both one-way and two-way communication devices may need to be notified of the type of device to be connected.

Therefore, the application on the first central server 109 can request a user name and password from the user of the medical device 120 at block 6812. Once the medical device 120 receives a request for a 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. Extract the password. The username and password are then transmitted 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. Then, at block 6906, the application on the first central server 109 can authenticate the user.

Once a user is authenticated on a server (eg, first central server 109), the credentials can be used to automatically authenticate the user on another server (eg, second central server 108a). .. In one example, a user can only authenticate if the user is authenticated by both the first central server 109 and the second central server 108a. Therefore, whenever a username or password is generated or modified, it is preferred that the username and password be synchronized between the first central server 109 and the second central server 108a.

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

Encrypted one-way communication can now be transmitted from the medical device 120 to the digital assistant 118. For example, the medical device 120 can report set values, generate alarms, and the like. In the illustrated example, the medical device 120 determines at block 6908 the data to be transmitted to the digital assistant 118 via the first central server 109. This data is then transmitted to the first central server 109 in block 6910 and received by the first central server 109 in block 6912. Then, in block 6914, the first central server 109 determines which users are authorized to receive this data, and in block 6916, determines which digital assistant 118 they are currently associated with. Can be done. For example, a reference table stored in the database of the first central server 109 can be used.

Then, in block 6918, the first central server 109 sends the data to the appropriate digital assistant 118, and in block 6920, the digital assistant 118 receives and displays the data. In addition, encrypted bidirectional communication can be achieved. For example, the digital assistant 118 and / or the first central server 109 can send data, instructions, configuration information, or any other kind of information to the medical device 120.

It should be emphasized that the above embodiments of the invention, in particular any "favorable" embodiment, are possible embodiments and are only described for a clear understanding of the principles of the invention. Many modifications and modifications can be made to each of the above embodiments of the invention without substantially departing from the spirit and principles of the invention. All such modifications are intended to be included within the scope of this disclosure herein, and the invention is protected by the claims below.

Claims (20)

A pharmacy system configured to print an instruction set on a drug label to program a medical device, said system.
With memory configured to store instructions for programming medical devices,
With a label printer configured to print drug labels for drug containers,
It is equipped with the memory and a pharmacy computer communicatively connected to the label printer.
The medical device includes an injection pump.
The pharmacy computer
Receiving an electronic drug order corresponding to a drug given intravenously to a patient,
At least one of the instructions and one or more therapy-specific driving parameters for the medical device for administering the drug corresponding to the electronic drug order to the patient based on the electronic drug order. To generate and
To generate an instruction set for programming the medical device according to the one or more therapy-specific operating parameters, the instruction set for programming the infusion pump to operate according to the electronic drug order. Being configured to be used ,
Print the instruction set on a drug label in a machine-readable format to allow the medical device to be programmed by a medical professional to administer the drug corresponding to the electronic drug order to the patient. A system configured to instruct and execute the label printer. The system of claim 1, wherein at least one of the instructions comprises the instruction set. The system of claim 1, wherein the one or more therapy-specific operating parameters include the amount and rate of injection that will be injected. The pharmacy computer
Determining the medical device to administer the drug corresponding to the electronic drug order and
i) To generate the one or more therapy-specific driving parameters based further on at least one of the determined medical device and ii) the determined medical device type. The system according to claim 1. The memory is configured to store instructions for programming a plurality of medical devices, and the pharmacy computer is specified from among the plurality of medical devices to administer the drug to the patient. The system according to claim 1, which is configured to determine the medical device. The pharmacy computer instructs the label printer to print the one or more therapy-specific operating parameters as a barcode read by the medical device's bar code reader to automatically program the medical device. The system according to claim 1, which is configured in 1. The system of claim 1, wherein the pharmacy computer is configured to receive the electronic drug order as an HL7 drug order message. The system according to claim 1, wherein the label printer is configured to attach the drug label to a drug container. The pharmacy computer is configured to instruct the label printer to print at least one of the identifier for the patient, the identifier for the medical device, or the expiration date of the drug on the drug label. , The system according to claim 1. Further including an RF (Radio Frequency) writer, the pharmacy computer wirelessly writes the therapy-specific operating parameters and information related to the electronic drug order to the RF device connected to the drug label. The system of claim 1, configured to instruct a writer. The system of claim 1, wherein the electronic drug order is received from a computerized physician order entry (CPOE) system. The electronic drug order may be (a) a dose of the drug at a particular concentration, (b) an amount of the drug per unit body weight, (c) a dose of the drug per unit body surface area, or (d). The system of claim 1, wherein at least one of the total dose and duration is specified. 12. The system of claim 12, wherein the drug order identifies at least one of (a)-(d) over a period of time. A method for printing an instruction set on a drug label to program a medical device, said method.
Receiving an electronic drug order corresponding to a drug given intravenously to a patient on a pharmacy computer communicatively connected to a memory device.
For a medical device for administering the drug corresponding to the electronic drug order to the patient based on at least one instruction stored in the memory device and the electronic drug order via the pharmacy computer. To generate one or more therapy-specific operating parameters of the medical device, the medical device comprises an infusion pump .
Through the pharmacy computer, the instruction set for programming the medical device according to the one or more therapy-specific operating parameters is to generate the instruction set to operate according to the electronic drug order. Being configured to be used to program an infusion pump ,
The drug on the drug label in a machine-readable format to allow the medical device to be programmed by a medical professional to administer the drug corresponding to the electronic drug order to the patient via the pharmacy computer. A method that includes instructing a label printer to print an instruction set. 14. The method of claim 14, further comprising storing the at least one instruction for programming the medical device in the memory device. Determining the medical device to administer the drug corresponding to the electronic drug order via the pharmacy computer.
Through the pharmacy computer, i) generate the one or more therapy-specific driving parameters based further on at least one of the determined medical device and ii) the type of the determined medical device. The method of claim 14, further comprising: Instructing the label printer to print the one or more therapy-specific operating parameters as a barcode read by the medical device's bar code reader to automatically program the medical device via the pharmacy computer. 14. The method of claim 14, further comprising: Further instructing the label printer to print at least one of the identifier for the patient, the identifier for the medical device, or the expiration date of the drug on the drug label via the pharmacy computer. The method of claim 14, including. 14. The method of claim 14, wherein the at least one instruction comprises the instruction set. 14. The method of claim 14, wherein the one or more therapy-specific driving parameters include the amount and rate of injection that will be injected.

Images