CN116648755A

CN116648755A - Synchronization of patient-associated data across a healthcare organization network

Info

Publication number: CN116648755A
Application number: CN202180085233.4A
Authority: CN
Inventors: 迈克尔·K·沃克曼; 丽莎·迪格特
Original assignee: CareFusion 303 Inc
Current assignee: CareFusion 303 Inc
Priority date: 2020-12-18
Filing date: 2021-12-17
Publication date: 2023-08-25

Abstract

An infusion device includes a pump and a control unit. The control unit is configured to provide an infusion of the medication to the current patient, send infusion information to the remote recording system during the infusion, receive a confirmation of the infusion information from the recording system, the infusion information including an association between the infusion and the patient or pump, receive an indication of a change in the infusion, compare the change to the association information received from the system, determine that the association received from the system is no longer suitable for the infusion based on the comparison, update a representation of the status displayed on the display screen to indicate that the association information received from the system is no longer suitable for the infusion, and send a message to the system indicating that the infusion device has determined that the association information is no longer suitable for the changed infusion.

Description

Synchronization of patient-associated data across a healthcare organization network

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional application Ser. No. 63/127,970, entitled "SYNCHRONIZATION OF PATIENT ASSOCIATION DATA ACROSS A HEALTHCARE ORGANIZATION NETWORK", filed on month 12 and 18 of 2020, and claims the benefit of U.S. provisional application Ser. No. 63/171,056, entitled "SYNCHRONIZATION OF PATIENT ASSOCIATION DATA ACROSS A HEALTHCARE ORGANIZATION NETWORK", filed on month 4 and 5 of 2021, each of which is incorporated herein by reference in its entirety.

Background

The present disclosure relates generally to systems and methods of identifying, associating, and disassociating medical devices with patients.

A hospital or other care administration facility records and tracks the treatment administered to the patient. One method commonly used is to record and maintain an electronic medication administration record, commonly referred to as eMAR (electronic medication administration record), containing details of each medication administration to a patient in the institution, including the medication administered and the device used for the administration. Although reference is made herein and below to storing records in eMAR, other health information management systems (e.g., patient data management systems (patient data management system, PDMS)) may create or store drug administration records for patients. eMAR is a file that, in order to be useful, must be accurate and contain a complete record of the patient's treatment.

A server connected to the medical device may then maintain a medication administration record in its own memory or database, or may also communicate relevant information to a hospital system, such as an eMAR system, for recording in the patient's eMAR. The eMAR system may include a medication administration records database that stores electronic medication administration (eMAR) records of patients. It will be immediately apparent to those skilled in the art that the order number is critical to maintaining an accurate and complete record of the drug delivered to the patient. All drug administrations are identified by a unique drug order identification number, which is then associated with the patient.

However, one problem that arises is that after the initial start of infusion is recorded in the eMAR, the infusion protocol may be altered. In some situations, such as in an emergency room, a medical device may quickly switch from one patient to another, or quickly provide medication to a patient without a formal medication order. Furthermore, for the benefit of another patient, the device module may be disconnected from the medical device and moved to a different medical device. This change should be recorded in the patient's eMAR to ensure a complete record of the drug administered to the patient. However, existing systems have not been able to communicate changes in the field to the eMAR system. In this regard, the server and/or eMAR system may continue to store the current association between the device module and the first patient, but may not be notified of the use of the second patient.

Further, in this case, the pharmacy generated medication order identification number may not be assigned and the disconnection from the first patient may not be accurately communicated to and stored in the eMAR system.

Since eMAR is typically a true record of clinical decisions and automated medical device control, these technical problems related to the association and disassociation of devices and patients can affect life-critical decisions.

Disclosure of Invention

To increase patient safety while eliminating at least some of the time-consuming steps of manually scanning the bar code to identify one or more of the patient, caregiver, medication or medical device, it is advantageous to provide for association of the patient with the medical device and medications or other medical substances physically proximate to them. Furthermore, as medical devices such as infusion pumps are incorporated into hospital systems, the need to efficiently and accurately record the care provided by these devices becomes an important factor. An important area is to ensure that the basic record of events accurately reflects the medication or other treatment provided to the patient. For example, consider the case in which an infusion pump is associated with a first drug infused to a first patient. The infusion device is disconnected and used to provide a second, different patient with a different medication. Systems involving managing care for first and second patients may not be aware that the same device is being used and inaccurately attribute administration of the first or second drug to the wrong patient.

The subject technology described herein solves the problems of existing approaches while providing the efficiency and accuracy required by modern medical environments and organizations. In this regard, the subject technology includes an infusion device that includes a pump and a control unit. The control unit is configured to use the pump to provide an intravenous infusion of a drug to a patient currently suffering from the infusion, display a representation of a status of the intravenous infusion on the display screen while the infusion is being provided by the pump, send infusion information to the remote recording system during the infusion, the infusion information including a patient identifier and an order identifier of the infusion currently being provided by the pump, receive a confirmation of the infusion information from the remote recording system including association information representing an association between the infusion and the current patient or pump, receive an indication of a change in the infusion currently being provided by the pump at the infusion device, compare the change to the association information received from the remote recording system, determine that the association received from the remote recording system is no longer suitable for the changed infusion based on the comparison of the change to the association information received from the remote recording system, update the representation of the status displayed on the display screen to indicate that the association information received from the remote recording system is no longer suitable for the intravenous infusion, and send a message to the remote recording system indicating that the infusion device has determined that the association information is no longer suitable for the changed infusion. Other aspects include corresponding systems, apparatus, methods, and computer program products for implementing the foregoing features.

The methods and features may be implemented in whole or in part by a medical device, such as an infusion pump or an electronic health information system, such as an EMR or device management server.

It is to be understood that other configurations of the subject technology will become apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

Drawings

The accompanying drawings, which are included to provide a further understanding and are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and together with the description serve to explain the principles of the disclosed embodiments. In the drawings:

FIG. 1 depicts an example flow chart of data association between a patient, one or more pharmacy orders, and an infusion pump in accordance with aspects of the subject technology.

FIG. 2 depicts an example flow chart of unassociated data for a patient, one or more pharmacy orders, and an infusion pump in accordance with aspects of the subject technology.

Fig. 3A and 3B are data flow diagrams depicting example data flows from an infusion device to a healthcare information system for associating patient identifiers in accordance with aspects of the subject technology.

Fig. 4A and 4B are data flow diagrams depicting example data flows from an infusion device to a healthcare information system for associating a device identifier in accordance with aspects of the subject technology.

Fig. 5 depicts an example data flow diagram for sharing an association between an infusion device and a healthcare information system, in accordance with aspects of the subject technology.

Fig. 6 depicts an example diagram of an institutional patient care system 100 of a healthcare organization in accordance with aspects of the subject technology.

FIG. 7 depicts an example process flow for automatically associating or disassociating an infusion with a patient or medication in accordance with an aspect of the subject technology.

FIG. 8 depicts an example process for associating or disassociating infusion initiated by an infusion device with a patient or medication in accordance with an aspect of the subject technology.

FIG. 9 depicts an example process flow for server initiated association or disassociation of an infusion with a patient or medication in accordance with an aspect of the subject technology.

Fig. 10 is a conceptual diagram illustrating an example electronic system 400 for automatically associating or disassociating an infusion with a patient or medication in accordance with aspects of the subject technology.

Detailed Description

The disclosed methods and systems provide for synchronization of associating and de-associating healthcare system elements across a healthcare organization network and ensure proper association between elements is recorded at the eMAR system. These elements include one or more of a patient, medical device, medication or medical substance, and any nurse, doctor, or other care-giver. Once these items are associated, one or more of the elements may be configured according to the association with other elements, privileges may be granted based on the identity of caregivers present in the physical area, and a record of the actions and events that occurred is maintained. Furthermore, the record of the association is updated and/or validated across the entire healthcare organization's system to ensure that the appropriate patient is receiving treatment from the appropriate device and/or medication.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that embodiments of the present disclosure may be practiced without some of the specific details. In other instances, well-known structures and techniques have not been shown in detail in order not to obscure the disclosure.

The methods and systems disclosed herein are presented in terms of administering a drug as IV fluid to a patient in a hospital using an IV pump. However, the method and system are equally applicable to other medical settings (such as outpatient clinics) and non-medical applications where it is desirable to associate various elements based on co-existence within a defined physical space. Nothing in this disclosure should be construed as limiting the application of any of the methods or systems disclosed herein to a medical or hospital environment unless specifically indicated as such.

It would be advantageous to have a care management system that combines all of the various medication orders and administration services of a healthcare facility into an integrated automated system that inspects and records the delivery of therapeutic and other medications to patients. Such a system would prevent inappropriate medication from being administered to a patient by checking the medication against a database of known allergic reactions and/or side effects of the medication against the patient's medical history. The integrated system should also provide the doctor, nurse and other caregivers with up-to-date patient information at the bedside, notify the facility's pharmacy when additional medications are needed, or when the planned treatment falls behind the plan, and automatically update the facility's accounting database each time a medication or other care is administered.

FIG. 1 depicts an example flowchart 100 of data correlation between a patient, one or more pharmacy orders, and an infusion pump, in accordance with aspects of the subject technology. According to various aspects, medical element association includes a process of associating a patient, one or more orders, and infusion information from an infusion device, as described herein. The medical information server and/or eMAR system (acting as a medical information "consumer" 102) is responsible for recording and maintaining patient and order information, as well as maintaining associations between this information for all patients and infusion devices used across the hospital network. In this regard, each infusion device, when connected to the network, reports infusion data regarding the progress of the infusion it performs.

In some embodiments, the infusion device (acting as a "reporter" 104) is configured to support automatic recording by providing event data to the consumer. The auto-recording function is typically owned and executed by the consumer device. In many healthcare environments, consumers may be responsible for establishing a connection between pump infusion data and order information within the consumer's patient and consumer application (e.g., in an eMAR system).

FIG. 2 depicts an example flowchart 200 of unassociated data for a patient, one or more pharmacy orders, and an infusion pump in accordance with aspects of the subject technology. In the depicted example, no association between consumer 102 and reporter 104 is maintained or recorded. Without correlation, infusion data cannot flow into the patient chart.

Fig. 3A and 3B depict example data flows 300, 302 from an infusion device to a healthcare information system for associating patient identifiers in accordance with aspects of the subject technology. Infusion devices (including, for example, pumps or pump modules) (acting as reporter 104) may be stationary and may typically be inserted into a device rack or patient care unit assigned to a patient bed or room. A location Identifier (ID) or proxy ID is issued by the infusion device within infusion data sent by the device over the hospital information network. The ID may then be mapped to the patient ID by consumer 102 (e.g., eMAR system). Such allocation has several advantages, including ease of automation of location ID, no need for additional hardware scanners or workflows, and association and disassociation of the patient with infusion data can be automated by a reporter (e.g., infusion device).

According to some implementations, a mobile device may be implemented in an associated workflow. In this regard, the patient identifier is scanned (e.g., using a bar code or RFID scanner) or programmed on the reporter device as an input. The association and disassociation events may be issued by the mobile device and report the patient identifier with the infusion data to associate the infusion data with the patient. The use of a mobile device to interact with infusion data reporting is further described in U.S. patent No. 10,275,571, which is incorporated herein by reference in its entirety for this and related purposes.

The configuration shown in fig. 3A and 3B provides features to create an association between an infusion device in a consumer system and a patient. However, this configuration may not provide sufficient correlation. For example, the association in FIG. 3A is premised on an accurate report of patient identifiers. In the case where an infusion pump is rapidly reprogrammed for a new patient, a patient identifier may be used to associate an event with a record of a different patient. As another example, if a newly admitted patient (e.g., in an emergency room) has not had a patient identifier, an infusion event may be reported to the consumer, but the consumer may not have a mechanism to attribute the event to a particular record. The final association challenges may occur based on the nature of the medical device. For example, some infusion pumps are modular infusion devices whereby multiple pumps may be controlled by a central patient care unit (patient care unit, PCU). For such devices, it may be desirable to correlate events for a particular module to ensure that the volume of a first drug infused by one module is not incorrectly counted as the volume infused by a second, different module.

Another consideration of the configuration shown in fig. 3A and 3B is that the solution may depend on accurate location identification. When a device is attached to a fixed location (e.g., a network location), the location may serve as an accurate association indicator. However, if the medical device is mobile (e.g., wirelessly connected to a hospital network), the medical device location may vary and, in some instances, have no relationship with nearby patients.

Fig. 4A and 4B are data flow diagrams 400, 402 depicting example data flows from an infusion device to a healthcare information system for associating a device identifier in accordance with aspects of the subject technology. In some embodiments, the patient is associated with the order and infusion data by the device ID of the infusion device. This may occur at the consumer side 102 (e.g., eMAR) and may not be visible to the reporter 104 (e.g., infusion device).

According to one example, the device ID is scanned as part of the input of the consumer 102 (e.g., eMAR application). The device ID is selected from a list of possible devices known to the consumer application. A complete correlation may then be made between the infusion data provided by the infusion device and the patient and order information, allowing the infusion data to immediately flow into the patient's medical chart for a given order. This may have minimal impact on the clinical workflow within the consumer application. However, continued manual action by the user may occur to affect the state of synchronization between the reporter and the infusion device. For example, a clinician may need to monitor data flowing from a medical device and manually compare the data to a patient record. As another example, if the medical device completes infusion of a first patient, and the device is immediately used for a second patient. If the clinician forgets to re-associate the device with the second patient, the second patient's data will be recorded in the first patient's record. This association should be made for each infusion device on the remote consumer system. In some systems, manual synchronization should be consistent to avoid incomplete recording of patient medical records.

As with the configuration shown in fig. 3A, the configurations shown in fig. 4A and 4B provide a level of synchronization between the reporter and the consumer. One key factor in the synchronization is to properly link the device ID to the patient. As discussed, if the device is quickly re-altered in intent or assigned to a patient without an identifier, the event reported by the infusion device may be irrelevant. Another situation that may occur in systems that rely on patient identifiers is how disassociation occurs when a patient is discharged from a hospital. In some cases, the pump may be properly associated with the patient using the device ID that the consumer links to the patient identifier. After the patient is discharged from the care facility, a new infusion may be started to a different patient using the same pump. Whether wrong or intentional (e.g., transferring medication), the user may initiate infusion using the identifier of the discharge patient. Only after an infusion reporting event will the consumer detect that such an infusion should not occur. However, if the system is synchronized, infusion initiation may be prevented until associated with the current patient.

Fig. 5 depicts an example dataflow diagram 500 for sharing an association between an infusion device and a healthcare information system, in accordance with aspects of the subject technology.

According to various embodiments, the patient identifier is supplemented with a device ID of an infusion device that provides Intravenous (IV) infusion to the patient. Such association may occur at the infusion device (operating as a reporter 104) or at a remote recording system (operating as a consumer 102). One or more messages are sent between the systems to maintain synchronization of the patient and the device ID.

The subject technology provides a patient, order, and infusion association interoperability model that creates an agreement for coupling the infusion reporter 104 and the infusion data consumer 102 with respect to infusion data for orders flowing into patient medical records. The subject protocol between the infusion reporter 104 and the infusion data consumer further automates the association and disassociation of patient orders with infusion data. In this regard, the subject technology creates feedback to the associated infusion reporter 104 that is made to provide the user with more indication of the success of the association and to allow improved and more accurate disassociation of the patient order from the infusion data; this prevents errors in the patient medical record.

According to various embodiments, if the reporter device ID is associated or disassociated with patient and/or order information within consumer application 102 (e.g., eMAR system), a corresponding association or disassociation message may be sent to the reporting device ID. The message may include that the patient is associated with or disassociated from the order identifier.

In some embodiments, the infusion device may provide (on its display screen) a visual indication that it is remotely associated or disassociated (such as flashing its lights, displaying an icon, audio, or otherwise providing confirmation that the correct pump is synchronized). And if a new patient ID is entered on the infusion device or an existing patient ID is changed or cleared, a corresponding association or disassociation message is sent to the consumer system 102.

Thus, a complete correlation can be made between the infusion data provided by the infusion device and the patient and order information to allow the infusion data to immediately flow into the medical chart for a given order. In this regard, there is minimal workflow impact on the clinical workflow within the consumer application 102, as the association and disassociation are automatically synchronized between the consumer 102 and the reporter system 104, reducing the manual steps of disassociation, and thus, medical chart errors, which is particularly useful for disassociation. Because the association can be made on the reporter device, the likelihood of incomplete patient chart records is reduced or avoided.

Fig. 6 depicts an example diagram of an institutional patient care system 600 of a healthcare organization in accordance with aspects of the subject technology. In fig. 6, a patient care device (or "medical device" in general) 12 is connected to a hospital network 10. The term patient care device (or "PCD") may be used interchangeably with the term patient care unit (or "PCU"), any of which may include various auxiliary medical devices such as infusion pumps, vital sign monitors, medication dispensing devices (e.g., cabinets, suitcases), medication preparation devices, automatic dispensing devices, modules coupled to one of the foregoing (e.g., syringe pump modules configured to be attached to an infusion pump), or other similar devices. As previously described, the PCU/PCD 12 (and/or infusion pump) functions as the aforementioned reporter 104.

Each device 12 is connected to the internal healthcare network 10 by a transmission channel 31. The transmission channel 31 is any wired or wireless transmission channel, for example, an 802.11 wireless Local Area Network (LAN). In some embodiments, the network 10 also includes computer systems located in various departments throughout the hospital. For example, the network 10 of fig. 1 optionally includes a computer system associated with an admission department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more cell site computers, and/or a medical decision support system. As described further below, the network 10 may include separate sub-networks. In the depicted example, the healthcare network 10 includes a device network 40 through which the patient care devices 12 (and other devices) communicate according to normal operation.

In addition, the institutional patient care system 600 may contain a separate information system server 30. According to various embodiments, the server 30 and/or database 37 may contain, act as, or include a remote recording system configured to store electronic drug administration records (eMAR) of patients admitted or cared for within a hospital organization. In this regard, according to various embodiments, the server 30 and/or the eMAR system may be used as the consumer 102 described previously. The server 30 may also be in communication with a database 37 or include a database 37. The server 30 and/or database 37 may also store associations between patient identifiers, identifiers of infusion devices, and patient order information for patients, and receive and record corresponding infusion data received from infusion devices in real-time for those associations. Although the information system server 30 is shown as a separate server, the functions and programming of the information system server 30 may be incorporated into another computer if so desired by an engineer designing an institutional information system. The institutional patient care system 100 may also include one or more device terminals 32 for connection and communication with the information system server 30. The device terminal 32 may comprise a personal computer, a personal data assistant, a mobile device (such as a notebook computer, tablet computer, augmented reality device, or smart phone) configured with software for communicating with the information system server 30 via the network 10.

The patient care device 12 includes a system for providing patient care, such as described in U.S. patent No. 5,713,856 to Eggers et al, which is incorporated herein by reference for this purpose. The patient-care device 12 may include or contain pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), therapeutic devices, and other drug delivery devices that may be used in accordance with the teachings set forth herein. In the depicted example, the patient-care device 12 includes a control unit 14, also referred to as an interface unit 14 or docking station, connected to one or more functional modules 16, 18, 20, 22. The interface unit 14 includes a Central Processing Unit (CPU) 50 coupled to a memory, such as Random Access Memory (RAM) 58, and one or more interface devices, such as a user interface device 54, an encoded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. The interface unit 14 also (although not necessarily) includes a main non-volatile memory unit 56, such as a hard disk drive or non-volatile flash memory, for storing software and data, and one or more internal buses 64 for interconnecting the aforementioned elements.

In various embodiments, the user interface device 54 is a touch screen for displaying information to a user and allowing the user to input information by touching a defined area of the screen. Additionally or in the alternative, the user interface device 54 may include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft key, mouse, trackball, and/or light pen. The data input device 60 may be a bar code reader capable of scanning and interpreting data printed in bar code format. Additionally or in the alternative, the data input device 60 may be any device for inputting encoded data into a computer, such as one or more devices for reading a magnetic stripe, a Radio Frequency Identification (RFID) device, whereby digital data encoded in an RFID tag or smart label (defined below) is captured by the reader 60 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage medium. Other examples of data input device 60 include a voice activated or recognition device or a portable Personal Data Assistant (PDA). The user interface device 54 and the data input device 60 may be the same device, depending on the type of interface device used. Although the data input device 60 is shown in fig. 1 as being disposed within the interface unit 14, it is recognized that the data input device 60 may be located integrally within the pharmacy system 34, or located externally and in communication with the pharmacy system 34 via an RS-232 serial interface or any other suitable communication means. The auxiliary interface 62 may be an RS-232 communication interface, however, any other means for communicating with peripheral devices, such as a printer, patient monitor, infusion pump, or other medical device, may be used without departing from the subject technology. In addition, the data input device 60 may be a separate functional module, such as modules 16, 18, 20, and 22, and is configured to communicate with the controller 14, or any other system on the network, using suitable programming and communication protocols.

Network connection 52 may be a wired or wireless connection such as through an ethernet, wiFi, BLUETOOTH, integrated Services Digital Network (ISDN) connection, digital Subscriber Line (DSL) modem, or cable modem. Any direct or indirect network connection may be used including, but not limited to, a telephone modem, MIB system, RS232 interface, auxiliary interface, optical link, infrared link, radio frequency link, microwave link, or WLANS connection, or other wireless connection.

The functional modules 16, 18, 20, 22 are any devices for providing care to a patient or for monitoring a condition of a patient. As shown in fig. 6, at least one of the functional modules 16, 18, 20, 22 may be an infusion pump module, such as an intravenous infusion pump, for delivering a drug or other fluid to a patient. For purposes of this discussion, the functional module 16 is an infusion pump module. Each of the functional modules 18, 20, 22 may be any patient treatment or monitoring device including, but not limited to, infusion pumps, syringe pumps, PCA pumps, epidural pumps, enteral pumps, blood pressure monitors, pulse oximeters, EKG monitors, EEG monitors, heart rate monitors, or intracranial pressure monitors, etc. Functional modules 18, 20, and/or 22 may be printers, scanners, bar code readers, or any other peripheral input, output, or input/output device.

Each functional module 16, 18, 20, 22 communicates directly or indirectly with the interface unit 14, wherein the interface unit 14 provides overall monitoring and control of the device 12. As shown in fig. 6, the functional modules 16, 18, 20, 22 may be physically and electronically connected in serial fashion to one or both ends of the interface unit 14. However, it is recognized that there are other means for connecting a functional module to an interface unit that may be used without departing from the subject technology. It will also be appreciated that a device providing sufficient programmability and connectivity (such as a pump or patient monitoring device) may be capable of operating as a stand-alone device and may communicate directly with a network without connection through a separate interface unit or control unit 14. As described above, additional medical devices or peripheral devices may be connected to patient-care device 12 through one or more auxiliary interfaces 62.

Each functional module 16, 18, 20, 22 may include a module-specific component 76, a microprocessor 70, a volatile memory 72, and a non-volatile memory 74 for storing information. It should be noted that although four functional modules are shown in fig. 6, any number of devices may be directly or indirectly connected to the central controller 14. The number and types of functional modules described herein are intended to be illustrative, and in no way limit the scope of the subject technology. The module specific assembly 76 includes any assembly necessary to operate a particular module, such as a pumping mechanism for the infusion pump module 16.

While each functional module may be capable of at least some degree of independent operation, the interface unit 14 monitors and controls the overall operation of the device 12. For example, as will be described in greater detail below, the interface unit 14 provides programming instructions to the functional modules 16, 18, 20, 22 and monitors the status of each module.

The patient-care device 12 can operate in several different modes or personalities, each of which is defined by a configuration database. The configuration database may be a database 56 internal to the patient care device or an external database 37. The particular configuration database is selected based at least in part on patient-specific information, such as patient location, age, physical characteristics, or medical characteristics. Medical features include, but are not limited to, patient diagnosis, treatment prescriptions, medical history, patient care provider identity, physiological features, or psychological features. As used herein, patient-specific information also includes care provider information (e.g., doctor identity) or the location of the patient-care device 10 in a hospital or hospital computer network. Patient care information may be sourced through interface devices 52, 54, 60, or 62, and may originate anywhere in network 10, such as, for example, from a pharmacy server, an admission server, a laboratory server, or the like.

Medical devices incorporating aspects of the subject technology may be equipped with a Network Interface Module (NIM) to allow the medical devices to participate as nodes in a network. Although for clarity purposes the subject technology will be described as operating in an ethernet network environment using Internet Protocol (IP), it will be appreciated that the concepts of the subject technology are equally applicable to other network environments and such environments are intended to be within the scope of the subject technology.

Data from and to various data sources may be converted to network compatible data using existing techniques, and movement of information between the medical device and the network may be accomplished by various means. For example, the patient-care device 12 and the network 10 may communicate via automatic interactions, manual interactions, or a combination of both automatic and manual interactions. The automatic interaction may be continuous or intermittent and may occur through a direct network connection 54 (as shown in fig. 1), or through an RS232 link, MIB system, RF link (such as BLUETOOTH), IR link, WLANS, digital cable system, telephone modem, or other wired or wireless communication means. Manual interaction between the patient care device 12 and the network 10 involves the transfer of data between systems physically, intermittently, or periodically using, for example, the user interface device 54, the coded data input device 60, a bar code, a computer diskette, a portable data assistant, a memory card, or any other medium for storing data. The communication means in various aspects is bi-directional, wherein data is accessed from as many points of the distributed data sources as possible. Decision making may occur at various places within the network 10. For example, and not by way of limitation, decisions may be made in the HIS server 30, the decision support 48, the remote data server 49, the hospital department or unit station 46, or within the patient care device 12 itself.

All direct communications with medical devices operating on a network in accordance with the subject technology may be performed through information system server 30, referred to as a Remote Data Server (RDS). In accordance with aspects of the subject technology, a network interface module incorporated into a medical device (such as, for example, an infusion pump or vital sign measurement device) ignores all network traffic that does not originate from an authenticated RDS. The main responsibility of the RDS of the subject technology is to track the location and status of all networked medical devices and maintain open communications.

With further reference to fig. 6, an infusion device as used herein may be a patient-care device 12, an interface control unit 14, or modules 16, 18, 20, 22. According to various embodiments, an infusion device includes a pump and a control unit. The control unit 14 is configured to provide an intravenous infusion of the drug to the current patient using the pump and to display a representation of the status of the intravenous infusion on the display screen while the infusion is being provided by the pump. The representation of the status may comprise, for example, monochromatic light emitted from an LED typically attached to a control unit, pump or infusion device, or may be an element displayed on a display screen. In some implementations, the color pod is a backlit or illuminated outline around the content in the display screen.

The control unit 14 is configured to send infusion information to the remote record system 30 during an infusion process, including a patient identifier and an order identifier of the infusion currently being provided by the pump. For example, a caregiver may enter that a particular patient is receiving a dose of acyclovir and the patient ID, drug ID, and dose information may be sent to the system 30 along with the device ID of the infusion device. The recording system 30 then sends (for which the control unit 14 is configured to subsequently receive) a confirmation of the infusion information including association information representing an association between the infusion and the current patient or pump to the control unit 14. This association is absent from the eMAR system which has accepted that the patient will receive a given dose of acyclovir. For example, the eMAR system may indicate to the pump that it is infusing patient X for order Y.

The control unit 14 may receive an indication of a change in the infusion being currently provided by the pump, for example, from an interface device 54 at the infusion device. For example, a caregiver may enter parameters into the infusion device indicating a new medication, a new patient, or a new order for a current patient. The control unit 14 compares the change to the association information received from the remote recording system and determines whether the association received from the remote recording system is no longer suitable for the changed infusion fluid based on the comparison of the change to the association information received from the remote recording system. The control unit 14 then proceeds to update the representation of the status displayed on the display screen to indicate that the associated information received from the remote recording system is no longer suitable for intravenous administration. This provides the caregiver with the opportunity to alter any mistakes made or confirm the alteration.

Upon confirmation of the change by the caregiver, the control unit 14 is configured to send a message to the remote recording system 30 to indicate that the infusion device has determined that the associated information is no longer applicable to the changed infusion. For example, a message is sent to the eMAR system that the system 30 considers the order ID for infusion by the infusion device to be no longer valid. The system 30 may then choose to take action, depending on its intended program implementation. For example, if the patient changes at the infusion device, the system 30 may break the association between all of the modules 16, 18, 20, 22 associated with the infusion device and the current patient. If the drug changes, the system 30 may stop accumulating the current drug (e.g., acyclovir) and begin recording the accumulation of the new drug. In some embodiments, the system 30 may notify the control unit 14 to terminate the associated infusion or request a confirmation as to whether the infusion should continue with respect to the patient or drug being changed.

In some embodiments, if the medication changes, the system 30 may also begin to buffer infusion data related to the new medication until the changed infusion is confirmed at the remote recording system 30, such as by an authorized care administrator at the terminal 32. When the changed infusion is confirmed, the remote recording system 30 is configured to create an association between the changed infusion and the current patient or infusion device and may begin recording data provided by the infusion device for the changed infusion associated with the current patient or infusion device.

According to various embodiments, whether the system 30 automatically acts on a change notification from an infusion device may depend on whether the change notification represents a hard or soft change. The hard change may, for example, indicate a change in medication not ordered for a particular patient, a change in dose exceeding a threshold amount, or an infusion device being assigned to a new patient. In these cases, the system 30 may send an alert to a mobile device associated with an authorized administrative caregiver or primary care giver of the patient, or may pause or terminate one or more infusions as described above, or request confirmation prior to such termination, and/or perform automatic disassociation and re-association based on information received from the infusion device. The soft change may include, for example, receiving an indication that a new infusion device is being applied to the current infusion, a change in volume of the order, or that the current infusion is being titrated. In these cases, the system 30 may simply record the change and send an alert.

FIG. 7 illustrates an example process flow 700 for automatically associating or disassociating an infusion with a patient or medication in accordance with aspects of the subject technology. For purposes of explanation, the various blocks of example process 700 are described herein with reference to fig. 1-6 and the components and/or processes described herein.

In the depicted example, the clinician sets up the infusion device to deliver an intravenous infusion of the drug to the current patient, and the infusion device provides an infusion of the drug to the patient using the pump. As part of this process, the clinician programs the infusion device (e.g., control unit 14) for use as reporter 104 with the patient ID and the medication ID (702). The infusion device begins infusion and, at the same time or prior to beginning infusion, sends an association (or disassociation) request to the system 30 (for use as the consumer 102) (704). The request may include infusion information, i.e., the patient ID and medication/order ID of the infusion currently being provided by the device. The system 30 performs verification of the data received from the infusion device and sends a confirmation of the infusion information including association information representing an association between the infusion and the current patient (706). Infusion continues (or begins) and the infusion device sends status information to the system 30 during infusion. Status information may also be displayed by the infusion device.

At some point, the infusion device may receive an indication of a change in the infusion being currently provided to the patient. The infusion device is configured to compare the change to the association information received from the remote recording system and determine that the association received from the remote recording system is no longer applicable to the changed infusion based on the comparison of the change to the association information received from the remote recording system. When the association is no longer applicable, the infusion device is configured to send a disassociation request to the system 30 (708). In this regard, the system 30 receives an indication that the infusion device has determined that the associated information is no longer suitable for infusion or for the current patient.

In connection with the disassociation request, the system 30 can receive new association information from the infusion device including a new patient identifier and/or a new medication (e.g., for a current or new patient). The system 30 may automatically initiate creation of a new association between the infusion device and a new patient or new medication based on new association information received from the infusion device. As part of this process, the system 30 may perform a second verification of new information received from the infusion device (710). For example, the system 30 may send a message to an authorized administrator to verify that a disassociation occurred or confirm a new association. The infusion device may display on the display screen that the system 30 is out of sync with the changed infusion to include an indication of the association between the changed infusion and the current patient or infusion device and prompt the clinician to proceed with confirmation of the changed infusion. The system 30 may then automatically disassociate the current patient or current infusion from the infusion device and send a confirmation of the new association back to the infusion device (712). The infusion device may then continue to infuse based on the new association, displaying the status of the infusion to the clinician in real-time (714).

Fig. 8 depicts an example process 800 for associating or disassociating infusion initiated by an infusion device with a patient or medication in accordance with aspects of the subject technology. For purposes of explanation, the various blocks of example process 800 are described herein with reference to fig. 1-7 and the components and/or processes described herein. One or more blocks of process 800 may be implemented, for example, by one or more computing devices, including, for example, medical device 12. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some implementations, one or more blocks may be implemented separately from other blocks and by one or more different processors or devices. Moreover, for purposes of explanation, the blocks of example process 800 are described as occurring serially or linearly. However, multiple blocks of the example process 800 may also occur in parallel. Furthermore, blocks of the example process 800 need not be performed in the order shown, and/or one or more blocks of the example process 800 need not be performed.

In the depicted example, the infusion device displays a representation of a status of an intravenous infusion of a medication being provided by the infusion device to a current patient on a display screen of the infusion device (802). The representation of the state may be implemented as a single color light (such as an LED) or as a graphical element in a graphical interface of a display screen. The infusion device (e.g., the control unit 14 or modules 16, 18, 20, 22) transmits infusion information during infusion that includes a patient identifier and an order identifier for the infusion currently being provided by the infusion device (804). In some implementations, the control unit 14 or a module associated therewith may send an association message that causes all modules of the control unit 14 to associate according to the association message. For example, if the docking station includes three pumps and the first pump sends or receives a message associated with a patient, the other two pumps may also be associated with the same patient. A confirmation of the infusion information is received from the remote recording system 30 (806). According to various examples, the confirmation includes association information representing an association between the infusion and the current patient or infusion device. In the docking station example, each pump in the docking station may receive an association confirmation message including a particular order identifier to be infused by the respective pump.

The infusion device receives an indication of a change in infusion currently being provided by the infusion device (808). The indication may include receiving parameters corresponding to a new medication or new patient (or new order) at an input interface of the infusion device, such as entered by a clinician. The infusion device compares the change to the associated information received from the remote recording system (810) and determines that the associated information received from the remote recording system is no longer suitable for the changed infusion based on the comparison of the change to the associated information received from the remote recording system (812). The comparison may include evaluating a correspondence between the previous value and the new value. Examples of parameters that may be used to evaluate the association state include: patient weight, patient name, patient identifier, drug concentration, drug container, volume to be infused, dose information, control unit identifier, etc.

The infusion device updates the status representation displayed on the display screen to indicate that the associated information received from the remote recording system is no longer suitable for intravenous infusion. This may include changing the color of the monochromatic light from a first color to a second color. According to some implementations, green may indicate that the association is current and verified, while red may indicate that the association is not verified and does not match. Third, the yellow color may be preserved for cases where soft changes occur. Simultaneously or thereafter, the infusion device sends a message to the remote recording system 30 indicating that the infusion device determines that the associated information is no longer suitable for the changed infusion (816).

According to various embodiments, the change in infusion currently being provided by the infusion device may include changing the medication to a new medication. In this regard, the association information received from the remote recording system may include an indication that the record of the current patient stored at the remote recording system has not been updated with an order for the new medication. In some embodiments, a message sent to system 300 may instruct system 30 to stop recording infusion data related to a medication and begin recording infusion data related to a new medication. The instruction may not be explicit. For example, the indication of the change may be interpreted by the system 30 as an instruction.

According to various embodiments, the change in the infusion currently being provided by the infusion device may include changing the current patient to a new patient. In this regard, the association information received from the remote recording system may include an indication that the infusion device has not been assigned to a new patient at the remote recording system. In some embodiments, the message sent to the system 300 may instruct the system 30 to disassociate the current patient from the infusion device. The instruction may not be explicit. For example, the indication of the change may be interpreted by the system 30 as an instruction.

Additionally, or in the alternative, the message may instruct the remote recording system 30 to buffer infusion data related to the new medication until the remote recording system confirms the changed infusion at the remote recording system. Also, instructions may not be explicit. Upon confirmation of the changed infusion at the remote recording system 30, the system 30 may create an association between the changed infusion and the current patient or infusion device and begin recording data provided by the infusion device for the changed infusion associated with the current patient or infusion device.

As previously described, when a change is detected, the infusion device may display on the display screen an indication that the remote recording system is not synchronized with the changed infusion to include an association between the changed infusion and the current patient or infusion device and prompt confirmation of proceeding with the changed infusion. The infusion device may then adjust infusion parameters on the infusion device to effect a change to the infusion (e.g., based on the entered parameters) upon receipt of the confirmation. The infusion device may be configured to terminate (or pause) the infusion when no acknowledgement is received. In addition, other modules associated with the infusion device may provide infusion to the same patient. When no acknowledgement is received, the infusion device may terminate other infusions.

FIG. 9 depicts an example process flow 900 for server initiated association or disassociation of an infusion with a patient or medication in accordance with aspects of the subject technology. The steps of fig. 9 are similar or identical to those of fig. 7 and 8, except that the clinician programs the association or disassociation (including the patient ID and medication ID) at the server and the server sends an association or disassociation request to the infusion device and the infusion device performs verification and responds with a confirmation. Verification may be performed by the clinician at the patient bedside or at an associated nursing station or mobile device. Verification may be performed using one or more input devices (such as a scanner, user interface, or sensor) in communication with reporter 102. For example, the association request may include an identifier for the clinician requesting the association. The identifier may be provided or associated with a user logged into the reporter 102 device. Verification may include confirming correspondence of the identities of the requester and the user of the infusion device. In some implementations, the verification may include verifying the source or content of the request, such as through the use of a shared secret, encryption/decryption, message hashing, or other system for proving validity between the reporter 102 and the consumer 104.

As shown in fig. 9, after the disassociation request is accepted, new infusion state data can be generated. In some implementations, the reporter 102 may buffer the infusion status data until a new association is confirmed. Upon confirmation, the reporter 102 sends the cached event to the consumer 104. In some embodiments, the infusion state data may include a flag or other value indicating whether the data is cached (e.g., due to non-association) or transmitted without caching. In some implementations, the data may be sent to EMR/PDMS, which may decide to display the data (or portions thereof) and indicate that the data has not been validated.

Many of the above-described examples of fig. 7, 8, and 9, as well as related features and applications, may also be implemented as a software process, designated as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium), and may be executed automatically (e.g., without user intervention). When executed by one or more processing units (e.g., one or more processors, cores of processors, or other processing units), cause the one or more processing units to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROM, flash memory drives, RAM chips, hard drives, EPROMs, and the like. Computer readable media does not include carrier waves and electronic signals transmitted over a wireless or wired connection.

The term "software" is intended to include firmware residing in read-only memory or applications stored in magnetic storage, which may be read into memory for processing by a processor, where appropriate. Furthermore, in some embodiments, multiple software aspects of the subject disclosure may be implemented as sub-portions of a larger program while maintaining different software aspects of the subject disclosure. In some embodiments, multiple software aspects may also be implemented as separate programs. Finally, any combination of separate programs that collectively implement the software aspects described herein is within the scope of the subject disclosure. In some implementations, a software program, when installed to operate on one or more electronic systems, defines one or more particular machine implementations that carry out and execute the operations of the software program.

A computer program (also known as a program, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object or other unit suitable for use in a computing environment. The computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

Fig. 10 is a conceptual diagram illustrating an example electronic system 400 for automatically associating or disassociating an infusion with a patient or medication in accordance with aspects of the subject technology. Electronic system 400 may be a computing device for executing software associated with one or more portions or steps of process 400 or the components and processes provided in fig. 1-9, including, but not limited to, information system server 30, production server 204, computing hardware within patient-care device 12, or terminal device 37. Electronic system 400 may be representative and incorporate the disclosure with respect to fig. 1-9. In this regard, the electronic system 400 may be a personal computer or mobile device, such as a smart phone, tablet, notebook, PDA, augmented reality device, wearable device (such as a watch or band or glasses), or a combination thereof, or other touch screen or television having one or more processors embedded therein or coupled thereto, or any other type of computer-related electronic device having network connectivity.

Electronic system 400 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, electronic system 400 includes bus 408, one or more processing units 412, system memory 404, read Only Memory (ROM) 410, persistent storage 402, input device interface 614, output device interface 406, and one or more network interfaces 416. In some implementations, the electronic system 400 may include or be integrated with other computing devices or circuits for operating the various components and processes previously described.

Bus 408 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 400. For example, bus 408 communicatively connects one or more processing units 412 with ROM 410, system memory 404, and persistent storage 402.

From these various memory units, one or more processing units 412 retrieve instructions to be executed and data to be processed in order to perform the processes of the subject disclosure. In various embodiments, one or more of the processing units may be a single processor or a multi-core processor.

ROM 410 stores static data and instructions required by one or more processing units 412 and other modules of the electronic system. On the other hand, persistent storage 402 is a read-write memory device. Such devices are non-volatile memory units that store instructions and data even when electronic system 400 is turned off. Some implementations of the subject disclosure use a mass storage device (such as a magnetic or optical disk and its corresponding disk drive) as persistent storage device 402.

Other embodiments use removable storage devices, such as floppy disks, flash memory drives, and their corresponding disk drives, as persistent storage device 402. Like persistent storage 402, system memory 404 is a read-write memory device. However, unlike storage device 402, system memory 404 is a volatile read-write memory, such as random access memory. The system memory 404 stores some instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in system memory 404, persistent storage 402, and/or ROM 410. From these various memory units, one or more processing units 412 retrieve instructions to be executed and data to be processed in order to perform processes of some embodiments.

Bus 408 is also connected to input and output device interfaces 414 and 406. The input device interface 414 enables a user to communicate information and select commands to the electronic system. Input devices for use with input device interface 414 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 406 enables, for example, display of images generated by the electronic system 400. Output devices used with output device interface 406 include, for example, printers and display devices, such as Cathode Ray Tubes (CRTs) or Liquid Crystal Displays (LCDs). Some implementations include devices such as touch screens that function as both input and output devices.

In addition, as shown in FIG. 4, bus 408 also couples electronic system 400 to a network (not shown) through a network interface 416. The network interface 416 may include, for example, a wireless access point (e.g., bluetooth or WiFi) or a radio circuit for connecting to the wireless access point. The network interface 416 may also include hardware (e.g., ethernet hardware) for connecting the computer to a portion of a computer network, such as a local area network ("LAN"), wide area network ("WAN"), wireless LAN, or intranet, or a network of networks, such as the internet. Any or all of the components of electronic system 400 may be used in conjunction with the subject disclosure.

The functions described above may be implemented in computer software, firmware, or hardware. The techniques may be implemented using one or more computer program products. The programmable processor and computer may be included in or packaged as a mobile device. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuits. The general purpose and special purpose computing devices and the storage devices may be interconnected by a communication network.

Some implementations include electronic components, such as microprocessors, storage, and memory, that store computer program instructions in a machine-readable or computer-readable medium (also referred to as a computer-readable storage medium, machine-readable medium, or machine-readable storage medium). Some examples of such computer readable media include RAM, ROM, compact disk read-only (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), digital versatile disk read-only (e.g., DVD-ROM, dual layer DVD-ROM), various recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini SD cards, micro SD cards, etc.), magnetic and/or solid state disk drives, read-only and recordable Magnetic disks, super-density optical disks, any other optical or magnetic medium, and floppy disks. The computer readable medium may store a computer program executable by at least one processing unit and include a set of instructions for performing various operations. Examples of computer programs or computer code include machine substitutesCode, such as produced by a compiler, and files containing higher level code that are executed by a computer, electronic component, or microprocessor using an interpreter.

Although the discussion above refers primarily to microprocessors or multi-core processors executing software, some embodiments are performed by one or more integrated circuits, such as Application Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs). In some implementations, such integrated circuits execute instructions stored on the circuits themselves.

As used in the description of the application and in any claims, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical equipment. These terms do not include a person or group of people. For purposes of this specification, the term display or displaying means displaying on an electronic device. As used in the specification and any claims of the present application, the terms "computer-readable medium" and "computer-readable medium" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other transitory signals.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) and a keyboard and a pointing device (e.g., a mouse or a trackball) for displaying information to the user and by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. In addition, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an embodiment of the subject matter described in this specification), or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), the internet (e.g., the internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

The computing system may include clients and servers. The client and server are typically remote from each other and may interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to and receive user input from a user interacting with the client device). Data generated at the client device (e.g., results of the user interaction) may be received at the server from the client device.

In any of the embodiments disclosed herein, the generated or detected data may be forwarded to a "remote" device or locations, where "remote" means locations or devices other than the location or device where the program was executed. For example, the remote location may be another location in the same city (e.g., office, laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Thus, when one item is indicated as being "remote" from another, it is meant that the two items may be in the same room but separate, or at least in different rooms or different buildings, virtually (e.g., different network addresses), and/or physically. "communication" information refers to the transmission of data representing the information as electrical signals over a suitable communication channel (e.g., a private or public network). "forwarding" an item refers to any means of transporting the item from one location to the next, whether by physical transport of the item or otherwise (where possible), and includes physical transport of data-carrying media or communication data, at least in the case of data. Examples of communication media include radio or infrared transmission channels, network connections to another computer or networking device, and the internet or information including email transmissions and recordings on websites, and the like.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. While the foregoing has described what are considered to be the best mode and/or other examples, it will be understood that various modifications to these aspects will be apparent to those skilled in the art, and that the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more. The terms "a," "an," and "some" mean one or more, unless stated otherwise specifically. Male pronouns (e.g., his) include female and neutral sexes (e.g., her and its), and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention.

Those of skill in the art will appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functions may be implemented in various ways for each particular application. The various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different manner) all without departing from the scope of the subject technology.

Description of the subject technology as clauses:

for convenience, various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the subject technology. The identifications of the drawings and reference numbers are provided below by way of example only and for illustrative purposes, and the terms are not limited by these identifications.

Clause 1. An infusion device, the infusion device comprising: a pump; and a control unit configured by instructions that, when executed by the processor, cause the control unit to: providing intravenous infusion of a drug to a current patient using the pump; displaying a representation of the status of the iv fluid infusion on a display screen when fluid infusion is provided by the pump; during infusion, sending infusion information to a remote recording system, the infusion information including a patient identifier and an order identifier of an infusion currently being provided by the pump; receiving a confirmation of the infusion information from the remote recording system including association information representing an association between the infusion and the current patient or the pump; receiving an indication of a change in infusion currently being provided by the pump at the infusion device; comparing the change to the associated information received from the remote recording system; determining that the association received from the remote recording system is no longer applicable to the changed infusion fluid based on a comparison of the change to the association information received from the remote recording system; updating a representation of a state displayed on the display screen to indicate that the associated information received from the remote recording system is no longer suitable for the iv fluid; and sending a message to the remote recording system indicating that the infusion device has determined that the associated information is no longer suitable for the changed infusion.

Clause 2. The infusion device of clause 1, wherein the representation of the state comprises monochromatic light, and wherein updating the representation comprises changing a color of the monochromatic light from a first color to a second color.

Clause 3 the infusion device of clause 1 or 2, wherein the changing of the infusion currently being provided by the infusion device comprises changing the medication to a new medication, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion comprises: determining, by a control unit of the infusion device, that a record of the current patient stored at the remote recording system has not been updated with an order for the new medication.

Clause 4 the infusion device of clause 3, wherein sending the message to the remote recording system comprises: the remote recording system is instructed to stop recording infusion data relating to the medication and to begin recording infusion data relating to the new medication.

Clause 5 the infusion device of clause 3 or 4, wherein sending the message to the remote recording system comprises: the remote recording system is instructed to cache infusion data relating to the new medication until the changed infusion is confirmed at the remote recording system, wherein, while the changed infusion is being confirmed at the remote recording system, the remote recording system creates an association between the changed infusion and the current patient or the infusion device and begins recording data provided by the infusion device for the changed infusion associated with the current patient or the infusion device.

Clause 6 the infusion device of any of clauses 1-5, wherein the changing of the infusion currently provided by the infusion device comprises changing the current patient to a new patient, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion comprises: determining, by a control unit of the infusion device, that the infusion device has not been assigned to the new patient at the remote recording system, and wherein sending the message to the remote recording system comprises: the remote recording system is instructed to disassociate the current patient from the infusion device.

The infusion device of any one of clauses 1-6, wherein the control unit is further configured to: displaying on the display screen that the remote recording system is not synchronized with the changed infusion to include an indication of an association between the changed infusion and the current patient or the infusion device; prompting confirmation of infusion continuing the change; when the confirmation is received, adjusting infusion parameters on the infusion device to implement the change to the infusion; and terminating the infusion when the acknowledgement is not received.

Clause 8 the infusion device of clause 7, wherein the control unit is further configured to, when the acknowledgement is not received: determining a second infusion being provided by the infusion device; and terminating the second infusion.

Clause 9. A method comprising: displaying a representation of the status of the infusion on a display screen of the infusion device while the infusion device is providing an intravenous infusion of the medication to the current patient; during an infusion, transmitting infusion information from the infusion device to a remote recording system, the infusion information including a patient identifier and an order identifier of an infusion currently being provided by the infusion device; receiving a confirmation of the infusion information from the remote recording system including association information representing an association between an infusion and the current patient or the infusion device; receiving, at the infusion device, an indication of a change in infusion currently being provided by the infusion device; comparing the change to the associated information received from the remote recording system; determining that the associated information received from the remote recording system is no longer suitable for the changed infusion based on a comparison of the change to the associated information received from the remote recording system; updating a representation of the status displayed on the display screen to indicate that the associated information received from the remote recording system is no longer applicable to the iv fluid; and sending a message to the remote recording system indicating that the infusion device has determined that the associated information is no longer suitable for the changed infusion.

Clause 10. The method of clause 9, wherein the representation of the state comprises monochromatic light, and wherein updating the representation comprises changing a color of the monochromatic light from a first color to a second color.

Clause 11 the method of clause 9 or 10, wherein the changing the infusion currently being provided by the infusion device comprises changing the medication to a new medication, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion comprises: determining, by the infusion device, that a record of the current patient stored at the remote recording system has not been updated with an order for the new medication.

The method of clause 11, wherein sending the message to the remote recording system comprises: the remote recording system is instructed to stop recording infusion data relating to the medication and to begin recording infusion data relating to the new medication.

The method of any of clauses 11 or 12, wherein sending the message to the remote recording system comprises: instruct the remote recording system to cache infusion data relating to the new medication until the remote recording system, until a changed infusion is confirmed at the remote recording system, wherein, when the changed infusion is being confirmed at the remote recording system, the remote recording system creates an association between the changed infusion and the current patient or the infusion device, and begins recording data provided by the infusion device for the changed infusion associated with the current patient or the infusion device.

The method of any of clauses 9-13, wherein changing the infusion currently being provided by the infusion device comprises changing the current patient to a new patient, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion comprises: determining, by the infusion device, that the infusion device has not been assigned to the new patient at the remote recording system, and wherein sending the message to the remote recording system comprises: the remote recording system is instructed to disassociate the current patient from the infusion device.

The method of any of clauses 9-14, further comprising: displaying on the display screen that the remote recording system is not synchronized with the changed infusion to include an indication of an association between the changed infusion and the current patient or the infusion device; prompting confirmation of infusion continuing the change; when the confirmation is received, adjusting infusion parameters on the infusion device to implement the change to the infusion; and terminating the infusion when the acknowledgement is not received.

Clause 16 the method of clause 15, further comprising, when the acknowledgement is not received: determining a second infusion provided by the infusion device; and terminating the second infusion.

Clause 17. A method performed by a computing system, comprising: receiving, from an infusion device, infusion information related to an infusion of a medication being provided by the infusion device to a current patient, the infusion information including a patient identifier and an order identifier of the infusion being provided by the infusion device; determining an association between an infusion of the medication and the current patient or the infusion device; providing a confirmation of the infusion information to the infusion device including association information representing the determined association between the infusion and the current patient or the infusion device; receiving from the infusion device an indication that the infusion device has determined that the associated information is no longer suitable for infusion or the current patient; receiving new association information including a new patient or a new medication for the current patient from the infusion device in conjunction with the indication; automatically disassociating the current patient or infusion from the infusion device; and automatically initiate creation of a new association between the infusion device and the new patient or the new medication based on the new association information received from the infusion device.

The method of clause 17, wherein receiving the indication comprises: an indication is received that a medication being provided by the infusion device is changed to the new medication.

The method of clause 19, wherein receiving the indication that the infusion device has determined that the associated information is no longer suitable for infusion or the current patient comprises: receiving an instruction to stop recording infusion data relating to the medication, the method further comprising: remotely from the infusion device, a record of infusion data relating to the new medication is initiated.

Clause 20 the method of clause 18 or 19, further comprising: remote from the infusion device, the infusion data relating to the new medication is cached until creation of the new association is confirmed by the computing system, and when creation of the new association is confirmed, data provided by the infusion device for the new patient or the new medication of the current patient is recorded.

Further consider:

in some embodiments, any of the clauses herein may rely on any of the independent clauses or any of the dependent clauses. In one aspect, any term (e.g., subordinate term or independent term) may be combined with any other term(s) (e.g., subordinate term or independent term). In one aspect, a claim may include some or all of the words (e.g., steps, operations, means or components) recited in a clause, sentence, phrase or paragraph. In one aspect, a claim may include some or all of the words recited in one or more clauses, sentences, phrases, or paragraphs. In one aspect, some words in each of the clauses, sentences, phrases, or paragraphs may be removed. In one aspect, additional words or elements may be added to a clause, sentence, phrase, or paragraph. In one aspect, the subject technology may be implemented without utilizing some of the components, elements, functions or operations described herein. In one aspect, the subject technology may be implemented with additional components, elements, functions, or operations.

It is to be understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based on design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some steps may be performed simultaneously. The claims of the appended method present elements of the various steps in a sample order and are not meant to be limited to the specific order or hierarchy presented.

A phrase such as an "aspect" does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. The disclosure relating to an aspect may apply to all configurations, or one or more configurations. A phrase such as an aspect may refer to one or more aspects and vice versa. Phrases such as "an embodiment" do not imply that such an embodiment is essential to the subject technology or that such an embodiment applies to all configurations of the subject technology. The disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments. The phrase such an embodiment may refer to one or more embodiments and vice versa.

The term "exemplary" is used herein to mean "serving as an example or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

As used herein, the term "correspondence" or "correspondence" encompasses structural, functional, quantitative, and/or qualitative dependencies or associations between two or more objects, datasets, information, and/or the like, preferably wherein correspondence or associations may be used to transform one or more of the two or more objects, datasets, information, and/or the like to appear the same or equal. The correspondence may be evaluated using one or more of a threshold, a range of values, fuzzy logic, pattern matching, a machine learning evaluation model, or a combination thereof.

All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by any claims. Furthermore, to the extent that the term "includes," "has," or the like is used in the specification, such term is intended to be inclusive in a manner similar to the term "comprising," as "comprising" is interpreted when employed as a transitional word.

Claims

1. An infusion device, the infusion device comprising:

a pump; and

a control unit configured by instructions that, when executed by a processor, cause the control unit to:

providing intravenous infusion of a drug to a current patient using the pump;

displaying a representation of the status of the iv fluid infusion on a display screen when fluid infusion is provided by the pump;

during infusion, sending infusion information to a remote recording system, the infusion information including a patient identifier and an order identifier of an infusion currently being provided by the pump;

receiving a confirmation of the infusion information from the remote recording system including association information representing an association between the infusion and the current patient or the pump;

receiving an indication of a change in infusion currently being provided by the pump at the infusion device;

comparing the change to the associated information received from the remote recording system;

determining that the association received from the remote recording system is no longer applicable to the changed infusion fluid based on a comparison of the change to the association information received from the remote recording system;

updating a representation of the status displayed on the display screen to indicate that the associated information received from the remote recording system is no longer applicable to the iv fluid; and is also provided with

A message is sent to the remote recording system indicating that the infusion device has determined that the associated information is no longer suitable for the changed infusion.

2. The infusion device of claim 1, wherein the representation of the status comprises monochromatic light, and wherein updating the representation comprises: the color of the monochromatic light is changed from a first color to a second color.

3. The infusion device of claim 1 or 2, wherein the change to the infusion currently being provided by the infusion device comprises: changing the medication to a new medication, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion includes: determining, by a control unit of the infusion device, that a record of the current patient stored at the remote recording system has not been updated with an order for the new medication.

4. The infusion device of claim 3, wherein transmitting the message to the remote recording system comprises:

the remote recording system is instructed to stop recording infusion data relating to the medication and to begin recording infusion data relating to the new medication.

5. The infusion device of claim 3 or 4, wherein sending the message to the remote recording system comprises:

Instructing the remote recording system to cache infusion data relating to the new medication until the changed infusion is confirmed at the remote recording system,

wherein upon confirmation of the changed infusion at the remote recording system, the remote recording system creates an association between the changed infusion and the current patient or the infusion device and begins recording data provided by the infusion device for the changed infusion associated with the current patient or the infusion device.

6. The infusion device of any one of claims 1-5, wherein the change to the infusion currently being provided by the infusion device comprises: changing the current patient to a new patient, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion includes: determining, by a control unit of the infusion device, that the infusion device has not been assigned to the new patient at the remote recording system, and

wherein sending the message to the remote recording system comprises:

the remote recording system is instructed to disassociate the current patient from the infusion device.

7. The infusion device of any one of claims 1-6, wherein the control unit is further configured to:

displaying on the display screen that the remote recording system is not synchronized with the changed infusion to include an indication of an association between the changed infusion and the current patient or the infusion device;

prompting confirmation of continuing the changed infusion;

when the confirmation is received, adjusting infusion parameters on the infusion device to implement the change to the infusion; and is also provided with

Terminating the infusion when the confirmation is not received.

8. The infusion device of claim 7, wherein the control unit is further configured to, when the acknowledgement is not received:

determining a second infusion being provided by the infusion device; and is also provided with

Terminating the second infusion.

9. A method, comprising:

displaying a representation of the status of the infusion on a display screen of the infusion device while the infusion device is providing an intravenous infusion of the medication to the current patient;

during an infusion, transmitting infusion information from the infusion device to a remote recording system, the infusion information including a patient identifier and an order identifier of an infusion currently being provided by the infusion device;

Receiving a confirmation of the infusion information from the remote recording system including association information representing an association between an infusion and the current patient or the infusion device;

receiving, at the infusion device, an indication of a change in infusion currently being provided by the infusion device;

determining that the associated information received from the remote recording system is no longer suitable for the changed infusion based on a comparison of the change to the associated information received from the remote recording system;

10. The method of claim 9, wherein the representation of the state comprises monochromatic light, and wherein updating the representation comprises changing a color of the monochromatic light from a first color to a second color.

11. The method of claim 9 or 10, wherein the changing of the infusion currently being provided by the infusion device comprises: changing the medication to a new medication, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion includes: determining, by the infusion device, that a record of the current patient stored at the remote recording system has not been updated with an order for the new medication.

12. The method of claim 11, wherein transmitting the message to the remote recording system comprises:

13. The method of claim 11 or 12, wherein sending the message to the remote recording system comprises:

instructing the remote recording system to cache infusion data relating to the new medication until the remote recording system, until the changed infusion is confirmed at the remote recording system,

14. The method of any of claims 9-13, wherein the changing of the infusion currently being provided by the infusion device comprises: changing the current patient to a new patient, and wherein determining that the associated information received from the remote recording system is no longer applicable to the changed infusion includes: determining, by the infusion device, that the infusion device has not been assigned to the new patient at the remote recording system, and wherein sending the message to the remote recording system comprises:

15. The method of any of claims 9-14, further comprising:

prompting confirmation of continuing the changed infusion;

Terminating the infusion when the confirmation is not received.

16. The method of claim 15, further comprising, when the acknowledgement is not received:

Determining a second infusion provided by the infusion device; and is also provided with

Terminating the second infusion.

17. A method performed by a computing system, comprising:

receiving, from an infusion device, infusion information related to an infusion of a medication being provided by the infusion device to a current patient, the infusion information including a patient identifier and an order identifier of the infusion being currently provided by the infusion device;

determining an association between an infusion of the medication and the current patient or the infusion device;

providing a confirmation of the infusion information to the infusion device including association information representing the determined association between the infusion and the current patient or the infusion device;

receiving from the infusion device an indication that the infusion device has determined that the associated information is no longer suitable for infusion or the current patient;

receiving new association information including a new patient or a new medication for the current patient from the infusion device in conjunction with the indication;

automatically disassociating the current patient or infusion from the infusion device; and is also provided with

Based on the new association information received from the infusion device, creation of a new association between the infusion device and the new patient or the new medication is automatically initiated.

18. The method of claim 17, wherein receiving the indication comprises: an indication is received that a medication being provided by the infusion device is changed to the new medication.

19. The method of claim 18, wherein receiving an indication that the infusion device has determined that the associated information is no longer suitable for infusion or the current patient comprises:

receiving an instruction to stop recording infusion data associated with the medication,

the method further comprises the steps of:

remotely from the infusion device, a record of infusion data relating to the new medication is initiated.

20. The method of claim 18 or 19, further comprising:

remotely from the infusion device, caching infusion data relating to the new medication until creation of the new association is confirmed by the computing system,

when creation of the new association is confirmed, data provided by the infusion device for the new patient or a new medication of the current patient is recorded.