Method and system for communication between a monitoring client and a base

Abstract

To provide a system which enables implementation of an effective nursing care method that depends on the condition of a patient at a hospital.SOLUTION: An electronic patient care system disclosed herein implements a method comprising: determining if a monitoring client is connected to a base through a physical connection; establishing a first communication link between the monitoring client and the base through the physical connection; updating, as necessary, an interface program on the monitoring client and the base through the first communication link; establishing a second communication link between the monitoring client and the base using the first communication link; and communicating data from the base to the monitoring client using the second communication link.SELECTED DRAWING: None

Description

Technical Field

[0001] Cross - reference to Related Applications This application is an international patent application claiming priority based on the following applications.

[0002] U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled "Systems, Methods, and Apparatus for Electronic Patient Care".

[0003] This application is also a continuation - in - part application claiming priority based on the following applications.

[0004] U.S. Patent Application No. 13 / 480,444, filed May 24, 2012, entitled "Blood Treatment Systems, and Methods", and U.S. Patent Application Publication No. US - 2013 - 0037485 - A1 (Attorney Docket No. J43), published on February 14, 2013, and PCT Application No. PCT / US12 / 00257, filed May 24, 2012, entitled "Blood Treatment Systems, and Methods", and International Patent Application Publication No. WO / 2012 / 161744 (Attorney Docket No. J43WO), published on November 29, 2012.

[0005] This application may also be related to one or more of the following patent applications, which are hereby incorporated by reference in their entirety.

[0006] U.S. Provisional Patent Application No. 61 / 297,544 (Attorney Docket No. H53), filed January 22, 2010, entitled "Electronic Order - Mediation System for Medical Equipment", U.S. Patent Application No. 13 / 011,543, filed January 21, 2011, entitled "Electronic Patient Monitoring System", and U.S. Patent Application Publication No. US - 2011 - 0313789 - A1 (Attorney Docket No. I52), published on December 22, 2011, U.S. Patent Application No. 13 / 333,574, entitled "Systems, Methods, and Apparatus for Electronic Patient Care," filed on December 21, 2011, and U.S. Patent Application Publication No. US-2012-0185267-A1 (Attorney Docket No. I97), published on July 19, 2012, PCT Application No. PCT / US11 / 66588 (Attorney Docket No. I97WO), entitled "Systems, Methods, and Apparatus for Electronic Patient Care," filed on December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02), entitled "Infusion Systems, Methods, and Apparatus," filed on December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04), entitled "Fluid Delivery Rate Estimation Systems, Methods, and Apparatus," filed on December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05), entitled "Oral Medication Dispensing Systems, Methods, and Apparatus," filed on December 21, 2011, U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), entitled "Systems, Methods, and Apparatus for Monitoring, Controlling, or Managing Fluid Volume," filed on August 3, 2012, U.S. Provisional Patent Application No. 61 / 738,447 (Attorney Docket No. J32), entitled "Systems, Methods, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification," filed on December 18, 2012, U.S. Patent Application No. 13 / 723,238, entitled "Systems, Methods, and Apparatus for Clamping," filed on December 21, 2012 (Attorney Docket No. J47), U.S. Patent Application No. 13 / 723,235, entitled "Oral Medication Dispensing Systems, Methods, and Apparatus," filed on December 21, 2012 (Attorney Docket No. J74), PCT Application No. PCT / US12 / 71131 (Attorney Docket No. J74WO), entitled "Oral Medication Dispensing Systems, Methods, and Apparatus," filed on December 21, 2012, U.S. Patent Application No. 13 / 723,568 (Attorney Docket No. J75), entitled "Liquid Delivery Rate Estimation System, Method, and Apparatus," filed on December 21, 2012, U.S. Patent Application No. 13 / 725,790 (Attorney Docket No. J76), entitled "Infusion System, Method, and Apparatus," filed on December 21, 2012, PCT Application No. PCT / US12 / 71490 (Attorney Docket No. J76WO), entitled "Infusion System, Method, and Apparatus," filed on December 21, 2012, U.S. Patent Application No. 13 / 723,239 (Attorney Docket No. J77), entitled "System, Method, and Apparatus for Electronic Patient Care," filed on December 21, 2012, U.S. Patent Application No. 13 / 723,242 (Attorney Docket No. J78), entitled "System, Method, and Apparatus for Electronic Patient Care," filed on December 21, 2012, U.S. Patent Application No. 13 / 723,244 (Attorney Docket No. J79), entitled "System, Method, and Apparatus for Monitoring, Controlling, or Managing Liquid Volume," filed on December 21, 2012, PCT Application No. PCT / US12 / 71142 (Attorney Docket No. J79WO), entitled "System, Method, and Apparatus for Monitoring, Controlling, or Managing Liquid Volume," filed on December 21, 2012, U.S. Provisional Patent Application No. 61 / 740,474 (Attorney Docket No. J80), entitled "System, Method, and Apparatus for Communicating Data," filed on December 21, 2012, U.S. Patent Application No. 13 / 723,251 (Attorney Docket No. J81), entitled "Liquid Delivery Rate Estimation System, Method, and Apparatus," filed on December 21, 2012, PCT Application No. PCT / US12 / 71112 (Attorney Docket No. J81WO), entitled "Liquid Delivery Rate Estimation System, Method, and Apparatus," filed on December 21, 2012, U.S. Patent Application No. 13 / 723,253 (Attorney Docket No. J85), entitled "System, Method, and Apparatus for Electronic Patient Care," filed on December 21, 2012, and U.S. Patent Application No. 13 / 840,339 (Attorney Docket No. K14), filed on March 15, 2013, entitled "Infusion System, Method, and Apparatus", PCT Application No. PCT / US13 / 32445 (Attorney Docket No. K14WO), filed on March 15, 2013, entitled "Infusion System, Method, and Apparatus", U.S. Patent Application No. 13 / 833,432 (Attorney Docket No. K21), filed on March 15, 2013, entitled "Syringe Pump and Syringe Method", U.S. Patent Application No. 13 / 836,497 (Attorney Docket No. K22), filed on March 15, 2013, entitled "System and Apparatus for Electronic Patient Care", U.S. Patent Application No. 13 / 833,712 (Attorney Docket No. K23), filed on March 15, 2013, entitled "System, Method, and Apparatus for Clamping", and U.S. Patent Application No. 13 / 834,030 (Attorney Docket No. K28), filed on March 15, 2013, entitled "System, Method, and Apparatus for Monitoring, Controlling, or Managing Fluid Volume".

[0007] This application may also be related to the following patent applications, which are hereby incorporated by reference in their entirety.

[0008] U.S. Patent Application No. 13 / 900,655 (Attorney Docket No. K66), filed on March 23, 2013, entitled "System, Method, and Apparatus for Electronic Patient Care".

[0009] This disclosure relates to patient care. More particularly, the disclosure relates to systems, methods, and apparatuses for electronic patient care. BACKGROUND OF THE DISCLOSURE

[0010] Providing patient care in a hospital generally requires the interaction of many specialists and caregivers (e.g., physicians, nurses, pharmacists, technicians, nurse practitioners, etc.), and any number of medical devices / systems necessary for the treatment of a given patient. Despite the existence of systems intended to facilitate the care process, such as those incorporating electronic medical records (EMRs) and computerized provider order entry (CPOE), the process of providing comprehensive care to patients, including instructing and delivering medical treatments such as medication, is associated with several important issues.

Summary of the Invention

Means for Solving the Problems

[0011] In exemplary embodiments related to drug instructions and administration, an electronic patient care system can comprise a first data collection module (e.g., a monitoring client), and a second instruction input module having a user interface for transmitting instructions or receiving patient-related information (e.g., a fixed or portable monitoring client). The first module can be configured to receive and store measurement parameters regarding a patient's current state (e.g., patient state parameters), such as blood pressure, heart rate, cardiac rhythm, temperature, oxygenation, respiratory rate, or ventilation. The first module can also receive information regarding existing parameters related to the patient from a first database (e.g., an EHR database containing information about the patient) including patient state parameters such as, for example, drug allergies or sensitivities, other currently administered drugs present in the patient's tissue, age, weight, height, kidney, or liver function. The first module can be configured to obtain drug information regarding the prescribed drug and / or existing drugs from a second database (e.g., a drug information database), such as known drug interactions, effects of drugs, or existing drugs related to blood pressure, pulse, cardiac rhythm, or respiration. The first module can be configured to compare the patient's currently measured patient state parameters and the received existing patient state parameters with known normal ranges and create a table of patient state parameters found to be outside the normal ranges. The first module can then compare the table of patient state parameters with a table of corresponding parameters obtained from the drug information database. If a match is found between the table of patient state parameters and the table of corresponding parameters, the first module can then read one or more pre-input and stored messages for transmission to the second (instruction input) module. These messages can include, for example, warnings to the user of the second module regarding the specific prescribed drug, the patient's existing drugs, and the patient's current and existing medical conditions.Optionally, if a warning is received by the second module and the warning is confirmed by the user of the second module through an input signal from the user interface, further repetition of the warning can be avoided.

[0012] In other embodiments, the electronic patient care system can provide the user with editable default values derived from standard dosing and administration guidelines obtained from a drug information database, and can warn the user of changes that can be indicated based on the patient's current and existing medical conditions, allergies, existing medications, or other patient state parameters. The electronic patient care system preferably minimizes the amount of input typed by the user.

[0013] In other embodiments, the first module or other modules of the electronic patient care system can be used to identify medications and direct them to be delivered to the patient's bedside (e.g., via barcodes and readers, or RFID tags and scanners), and to verify that the appropriate medications and dosages have been prepared and delivered to the patient. In embodiments, the first module can also interact with patient care devices that administer treatment, such as infusion pumps or pill dispensers, through a wired or wireless communication link. In the case of an infusion pump, the first module or another connecting module can provide the infusion pump with patient treatment parameters, such as infusion settings including infusion rate or infusion pressure, and can receive from it various operating parameters, such as the presence of air in the infusion line, the amount of solution remaining in the connected intravenous bag, or the pressure of the fluid in the infusion line. If it is determined that an operating parameter is abnormal, the first module can respond by sending a signal to the infusion pump to interrupt the infusion, by sending a signal to a mechanical occlusion to close the venous line, by changing the infusion rate, and / or by warning a healthcare provider or the like of the abnormality either directly by an alarm incorporated within the first module or by transmission of the alarm to a second module. In another embodiment, the first module can also be configured to monitor the patient's condition and communicate with various patient care devices used to determine patient condition parameters, such as a blood pressure monitor, an ECG monitor, a pulse oximetry monitor, a temperature monitor, etc. The various parameters measured can be monitored and / or recorded by a portable device and / or within the EMR. In some cases, the first module can be programmed to alert the patient or another person if the monitored patient condition parameters are outside a predetermined range. In some embodiments, the first module can transmit a signal to a monitoring client to perform measurements not scheduled by the patient care device to obtain another patient condition parameter.The first module can communicate with various healthcare providers at various locations. In an embodiment, it is possible for the first module to notify a patient to whom it is assigned of an abnormality, and for example, recommend a corrective action by means of an audible alarm or a recorded message.

[0014] In one embodiment, a system for providing a microinfusion pump includes a monitoring client, a pharmacy computer, a compounding robot, a microinfusion pump, and a data download device. The monitoring client is configured to communicate a prescription via a user interface. The pharmacy computer is operably communicable with the monitoring client to receive the prescription. The compounding robot is configured to prepare prescription medications into at least one liquid corresponding to the prescription. The microinfusion pump is configured to receive at least one liquid corresponding to the prescription. The data download device is configured to download the prescription into the memory of the microinfusion pump.

[0015] In some embodiments, the compounding robot fills the microinfusion pump with at least one liquid. The compounding robot can be operably communicable with the data download device, and the compounding robot can instruct the data download device to download the prescription into the memory of the microinfusion pump. The data download device can receive the prescription from the compounding robot and / or the pharmacy computer. In some embodiments, the compounding robot receives the prescription from the pharmacy computer.

[0016] In one embodiment of the present disclosure, the system includes a hub. The hub is configured to monitor patient care devices. The hub includes an operating system (which can be embodied as processor-executable software) and a sandbox component (which can be embodied as processor-executable software). The operating system component is configured to access at least one of the hardware resources and software resources of the hub.

[0017] The sandbox component is configured to manage access to at least one of the hardware resources and software resources. The hub is further configured to identify patient care devices and execute an application to monitor the patient care devices. The hub can execute the application within the sandbox component, whereby the application accesses at least one of the hardware resources and software resources through the sandbox component.

[0018] The hub may be further configured to manage patient care devices. The patient care device may be one or more of an infusion pump, a pill dispenser, a microinfusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO2 capnometer, an intravenous bag, and / or a drip flow meter.

[0019] The hub may be configured to receive identification information (e.g., a serial number, a (encrypted or unencrypted) code, or other identification value) from the patient care device and download an application from a server associated with the identification information. Further, the hub may be configured to receive identification information from the patient care device and update an application from a server associated with the identification information.

[0020] Hardware resources may include a disk drive, memory, buzzer, microphone, speaker, and camera. Software resources may be one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component.

[0021] In yet another embodiment, a system for electronic patient care includes a hub. The hub is configured to monitor patient care devices. The sandbox can be configured to manage access to at least one of the hardware resources and software resources. The hub is further configured to identify patient care devices and execute an application to monitor the patient care devices. The hub executes the application within the sandbox component, whereby the application accesses at least one of the hardware resources and software resources through the sandbox component. The hub may be further configured to manage the patient care devices. The hub may be further configured to receive identification information from the patient care devices and download an application from a server associated with the identification information. The hub may be further configured to receive identification information from the patient care devices and update an application from a server associated with the identification information.

[0022] Hardware resources may include a disk drive, memory, buzzer, microphone, speaker, and camera. Software resources may be one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component.

[0023] In yet another embodiment, a system for electronic patient care includes a monitoring client. The monitoring client is configured to monitor patient care devices. The monitoring client includes an operating system component configured to access at least one of the monitoring client's hardware resources and the monitoring client's software resources. A sandbox component is configured to control access to at least one of the hardware resources and the software resources. The monitoring client may be further configured to identify a patient care device and execute an application to monitor the patient care device. The monitoring client executes the application within the sandbox component, whereby the application accesses at least one of the hardware resources and the software resources through the sandbox component. The monitoring client is further configured to manage the patient care device.

[0024] The patient care device may be an infusion pump, pill dispenser, micro-infusion pump, ECG monitor, blood pressure monitor, pulse oximeter, and / or CO2 capnometer, intravenous bag, and drip flow meter.

[0025] The monitoring client may be further configured to receive identification information from the patient care device and download an application from a server associated with the identification information. The monitoring client may be further configured to receive identification information from the patient care device and update an application from a server associated with the identification information.

[0026] Hardware resources may include a disk drive, memory, buzzer, microphone, speaker, and camera. Software resources may include a variable, secure data object, secure variable, protected API, API, and software representation of a hardware component.

[0027] In yet another embodiment, a system for electronic patient care includes a monitoring client configured to monitor a patient care device. The monitoring client includes a sandbox component configured to control access to at least one of the hardware resources and software resources. The monitoring client may be further configured to identify the patient care device and execute an application to monitor the patient care device. The monitoring client executes the application within the sandbox component, whereby the application accesses at least one of the hardware resources and software resources through the sandbox component. The monitoring client may be further configured to control the patient care device.

[0028] The patient care device may include an infusion pump, pill dispenser, micro-infusion pump, ECG monitor, blood pressure monitor, pulse oximeter, and / or CO2 capnometer, intravenous bag, and drip flow meter.

[0029] The monitoring client may be further configured to receive identification information from the patient care device and download an application from a server associated with the identification information. The monitoring client may be further configured to receive identification information from the patient care device and update an application from a server associated with the identification information.

[0030] Hardware resources may be a disk drive, memory, buzzer, microphone, speaker, and camera. Software resources may be one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component.

[0031] In another embodiment, a system for electronic patient care includes a hub configured to communicate with an electronic medical record and a patient care device. The hub is configured to identify a patient and a patient care device (e.g., an infusion pump). The hub is also configured to download at least one treatment parameter (e.g., an infusion drug and / or an infusion rate or rate profile, etc.) from the electronic medical record and program the patient care device with the at least one treatment parameter. The hub identifies the patient according to at least one of reading an RFID tag using an RFID interrogator, voice using a microphone to use coupled speech recognition software, face using face recognition software coupled to a camera, biometric parameters of biometric reading, identification information, barcode reading by a barcode reader. In a particular embodiment, the hub can download at least one treatment parameter using one or more of the identification techniques described herein.

[0032] In another embodiment, a system for electronic patient care includes a monitoring client configured to communicate with an electronic medical record and a patient care device. The monitoring client is configured to identify a patient and a patient care device (e.g., an infusion pump). The monitoring client is also configured to download at least one treatment parameter (e.g., an infusion drug and / or an infusion rate or rate profile, etc.) from the electronic medical record and program the patient care device with the at least one treatment parameter. The monitoring client identifies patients according to at least one of: reading RFID tags using an RFID interrogator; voice using a microphone and associated voice recognition software; face using a camera and associated face recognition software; biometric parameters for biometric reading; identification information; barcode reading using a barcode reader. In a particular embodiment, the monitoring client can download at least one treatment parameter using one or more of the identification techniques described herein.

[0033] In yet another embodiment, a system for electronic patient care includes a monitoring client, a monitoring client dock, a patient care device, and a device dock. The monitoring client is configured to communicate at least one patient care parameter. The monitoring client dock is configured to receive the patient client for docking the monitoring client thereto. The patient care device is configured to communicate at least one patient care parameter. The device dock is configured to receive the patient care device for docking the patient care device thereto.

[0034] In an embodiment, the monitoring client dock and the device dock are configured to communicate wirelessly and via a cable operably coupled to the monitoring client dock and the device dock.

[0035] In another embodiment, the monitoring client is configured to wirelessly communicate at least one patient care parameter.

[0036] In another embodiment, the monitoring client dock is configured to communicate wirelessly with the monitoring client, and the monitoring client operably communicates with the patient care device by communicating at least one patient care parameter wirelessly to the monitoring client dock, through the cable to the dock, and to the docked patient care device.

[0037] In another embodiment, when the monitoring client determines that at least one of cable communication is not available and the monitoring client is undocked from the monitoring client dock, the monitoring client utilizes wireless communication with the monitoring client dock to operably communicate at least one patient care parameter.

[0038] In another embodiment, the device dock is configured to wirelessly communicate with the monitoring client, and the monitoring client operably communicates with the patient care device by communicating at least one patient care parameter to the patient care device wirelessly docked with the device dock.

[0039] In another embodiment, when the monitoring client determines that at least one of cable communication is not available, communication between the monitoring client and the monitoring client dock is not available, and the monitoring client is undocked from the monitoring client dock, the monitoring client utilizes wireless communication with the device dock to operably communicate at least one patient care parameter.

[0040] In another embodiment, the patient care device is configured to wirelessly communicate with the monitoring client, and the monitoring client wirelessly communicates at least one patient care parameter with the patient care device.

[0041] In another embodiment, when the monitoring client determines that at least one of cable communication is not available, communication between the monitoring client and the monitoring client dock is not available, communication between the device dock and the patient care device is not available, and the monitoring client is undocked from the monitoring client dock, the monitoring client operably communicates at least one patient care parameter wirelessly with the patient care device.

[0042] In another embodiment, the monitoring client dock and the dock are configured to wirelessly communicate at least one patient parameter. The system further comprises a cable operably coupled to the monitoring client dock and the device dock, and the monitoring client dock and the dock are configured to communicate wirelessly if at least one of the device dock, the monitoring client dock, and the monitoring client determines that the cable is not available for use as a communication link.

[0043] In another embodiment, the monitoring client is configured to communicate with a patient care device via a plurality of communication links, and the monitoring client communicates via an operable one of the plurality of communication links.

[0044] In another embodiment, the patient care device is one of an infusion pump, a pill dispenser, a micro-infusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO2 capnometer, an intravenous bag, and a drip flow meter.

[0045] In another embodiment, the patient care parameter is at least one of an intravenous pump flow parameter, an ECG parameter, a blood pressure parameter, a pulse oximeter parameter, a CO2 capnometer parameter, an intravenous bag parameter, and a drip flow meter value. The patient care parameter may be a patient status parameter and / or a patient treatment parameter.

[0046] In another embodiment, the patient care device is configured to wirelessly communicate as a node of a mesh network.

[0047] In another embodiment, the cable is operably coupled to a monitoring client dock and a device dock, and when a patient care device is docked to the device dock and a monitoring client is docked to the monitoring client dock, the monitoring client is configured to communicate at least one patient care parameter with the patient care device through the cable.

[0048] In yet another embodiment, a system for electronic patient care comprises a monitoring client, a patient care device, and a device dock. The monitoring client is configured to communicate at least one patient care parameter. The patient care device is configured to communicate at least one patient care parameter. The device dock is configured to receive the patient care device for docking the patient care device therein and to receive the monitoring client for docking the monitoring client therein.

[0049] In yet another embodiment, a system for electronic patient care comprises a patient care device configured to communicate at least one patient care parameter, a monitoring client configured to communicate at least one patient care parameter, and a device dock configured to receive the patient care device for docking the patient care device therein. The device dock and the monitoring client are integrated together.

[0050] In yet another embodiment, a system for electronic patient care comprises a stackable monitoring client configured to communicate at least one patient care parameter and a stackable patient care device configured to communicate at least one patient care parameter. The stackable monitoring client and the stackable patient care device can communicate at least one patient care parameter via a daisy-chain communication link and / or using a backplane.

[0051] In yet another embodiment, a system for electronic patient care comprises a patient care device configured to communicate at least one patient care parameter, a hub-client configured to communicate at least one patient care parameter, and a device dock configured to receive the patient care device for docking the patient care device therein. The hub can be plugged into the device dock to establish a communication link therebetween. The system can further comprise a monitoring client operably communicating with the hub to receive at least one patient care parameter. The patient treatment parameter can communicate operably with the hub, and the hub communicates the patient treatment parameter to the patient care device.

[0052] In a particular embodiment, the hub can include a user interface, and the hub may require user authentication before transmitting the patient treatment parameter to the patient care device.

[0053] In a particular embodiment, the monitoring client can include a user interface, and the monitoring client may require user authentication before transmitting the patient treatment parameter to the patient care device through the hub.

[0054] In a particular embodiment, the patient care device can include a user interface, and the patient care device may require user authentication of the patient treatment parameter before treating the patient.

[0055] The hub can be configured to monitor the patient care device. In a particular embodiment, the hub can include a sandbox component configured to control access to at least one of hardware resources and software resources.

[0056] The hub can further be configured to identify patient care devices and execute an application to monitor the patient care devices. The hub can execute the application within a sandbox component, whereby the application accesses at least one of the hardware resources and software resources through the sandbox component.

[0057] In another embodiment, a system for electronic patient care includes at least one patient monitor adapted to monitor at least one patient parameter, a monitoring client operably communicating with the at least one patient monitor to receive the at least one patient parameter therefrom, and a monitoring server operably communicating with the monitoring client to receive the at least one patient parameter from the monitoring client.

[0058] In another embodiment, the system can further include a remote communicator operably communicating with the at least one patient monitor to receive at least one patient parameter.

[0059] The at least one patient monitor can include at least one of an electrocardiogram monitor, a blood pressure monitor, a pulse oximeter monitor, and a CO2 capnometer. The monitoring client can be configured to download patient information according to a specified unique patient identifier. The unique patient identifier can be encoded within a barcode disposed on a wristband. The unique patient identifier can be encoded on an RFID tag (e.g., an RFID transponder) coupled to the wristband. The patient information includes patient status or patient care parameters. The unique patient identifier can be operably transmitted to the monitoring server to obtain an electronic permission for communicating patient-specific data. A subset of the patient-specific data can be stored in the memory of the monitoring client. The monitoring client is adapted to determine whether a new instruction meets a predetermined criterion based on the subset of the patient-specific data stored in the memory.

[0060] In another embodiment, the system further comprises a portable monitoring client adapted to present new instructions to the monitoring client. At least one of the monitoring client and / or the remote communicator is adapted to communicate the new instructions to the monitoring server, and the monitoring server is adapted to determine whether the new instructions meet another predetermined criterion.

[0061] In another embodiment, the new instructions may be drug instructions, and the monitoring server is adapted to determine whether the new instructions meet another predetermined criterion by determining whether the drug instructions are contraindicated to the currently prescribed drugs. The monitoring server can communicate with a database to determine whether the new instructions meet another predetermined criterion. The monitoring server can be configured to send an alarm to the monitoring client if the new instructions do not meet another predetermined criterion.

[0062] In another embodiment, the system can comprise a remote communication adapted to operably communicate with at least one of the monitoring client and the monitoring server.

[0063] In another embodiment, the monitoring client may be one of a desk-based device, a portable device, a handheld controller, a notebook PC, a netbook PC, a tablet PC, and a smart phone. The monitoring client comprises a touch screen.

[0064] In another embodiment, the system can further comprise an infusion pump, and the monitoring client is operably communicable with the infusion pump. The infusion pump may be attachable to the monitoring client. The infusion pump may be removable from the monitoring client. In another embodiment, the system further comprises a dock configured to dock the monitoring client to the infusion pump.

[0065] In another embodiment, the monitoring client is operably communicable with the infusion pump via a wireless link.

[0066] In another embodiment, the monitoring server is configured to communicate with a plurality of databases, at least one of the plurality of databases including a data format or communication protocol different from another database of the plurality of databases.

[0067] In another embodiment, the monitoring server is adapted to format data from a plurality of databases for downloading to a monitoring client. Optionally, and in some particular embodiments, the monitoring client can communicate at least one patient parameter to the monitoring server. In a particular embodiment, the patient parameter can be one or more of, and / or can comprise at least one of, the treatment progress of the infusion pump, an electrocardiogram signal, a blood pressure signal, a pulse oximeter signal, a CO2 capnometer signal, and / or a temperature signal.

[0068] In another embodiment, the monitoring server can be configured to download operation instructions to the infusion pump via the monitoring client.

[0069] The monitoring client can receive a user request to read a patient parameter and can query a monitoring device to receive the patient parameter.

[0070] In another embodiment, the system can further comprise a portable monitoring client. The portable monitoring client can be operably communicable with the monitoring client to communicate directly with patient information, thereby bypassing the monitoring server. The portable monitoring client can be configured to change at least one parameter of the infusion pump and communicate at least one changed parameter to the monitoring server.

[0071] Changes to patient instructions presented via a portable monitoring client can be communicated to another portable monitoring client.

[0072] In another embodiment, the monitoring client is configured to periodically upload information to the monitoring server for storage in a patient-specific database.

[0073] The system can further include another monitoring client adapted to receive information from the patient-specific database.

[0074] The information can include at least one of patient instructions, patient medications, progress notes, monitoring data from a patient monitor, and treatment data from an attached device.

[0075] The monitoring server can be configured to query an electronic health record database to receive patient information therefrom. The monitoring server can further be configured to input a predetermined set of information to the monitoring client according to the patient information.

[0076] The predetermined set of information can include at least one of a patient's age, height, weight, diagnosis, current medications, medication categories, medication allergies, and sensitivities.

[0077] In another embodiment, a remote portable monitoring client is adapted to communicate with the monitoring client via the monitoring server. The remote portable monitoring client can be one of a tablet PC, a netbook, and a PC. The remote portable monitoring client can include a touch screen.

[0078] In another embodiment, the electronic patient care method includes displaying a plurality of patients on a display, displaying at least one patient parameter associated with one of the plurality of patients on the display, displaying at least one alert associated with the patient on the display, and selecting a patient from the plurality of patients.

[0079] In some specific embodiments, the method can further include transmitting an alert from a monitoring client to a portable remote communicator device having a display.

[0080] In yet another embodiment, the electronic patient care system includes a monitoring client configured to communicate at least one patient care parameter, a patient care device configured to communicate at least one patient care parameter, and a communication interface configured to discover the presence of at least one patient care device and convert a communication signal from that device into a communication protocol associated with the monitoring client to facilitate communication between the monitoring client and the at least one patient care device.

[0081] In a particular embodiment, the communication interface is further configured to discover the presence of additional other patient care devices different from each other and convert communication signals from these devices into a communication protocol associated with the monitoring client.

[0082] In another particular embodiment, the communication interface is further configured to provide power suitable for each device. In yet another particular embodiment, the system further includes one or more databases accessible by a monitoring client that enables at least one of central storage of patient information and / or download information that can be used for the treatment of patients associated with the monitoring client.

[0083] In yet another specific embodiment, the communication interface is further configured to perform a failure check on at least one of access data integrity of communication with the patient care device, evaluate whether the monitoring client is functioning properly, evaluate whether the patient care device is functioning properly, and / or evaluate whether the communication interface is functioning properly.

[0084] In yet another embodiment, the electronic patient care system includes a hub client configured to communicate at least one patient care parameter, a patient care device configured to communicate at least one patient care parameter, and a communication interface configured to facilitate communication between the hub and at least one patient care device by detecting the presence of the at least one patient care device and converting a communication signal from the device into a communication protocol associated with the hub.

[0085] In a specific embodiment, the communication interface is further configured to detect the presence of additional other patient care devices different from each other and convert a communication signal from the device into a communication protocol associated with the hub.

[0086] In another specific embodiment, the communication interface is further configured to provide power suitable for each device. In yet another specific embodiment, the system further includes one or more databases accessible by a hub that enables at least one of central storage of patient information and / or download information that can be used for treatment of a patient associated with the hub.

[0087] In yet another specific embodiment, the communication interface is further configured to perform a failure check on at least one of access data integrity of communication with the patient care device, evaluate whether the monitoring client is functioning properly, evaluate whether the patient care device is functioning properly, and / or evaluate whether the communication interface is functioning properly.

[0088] In yet another embodiment, the electronic patient care system includes a dock configured to communicate at least one patient care parameter, a patient care device configured to communicate at least one patient care parameter, and a communication interface configured to facilitate communication between the dock and the at least one patient care device by detecting the presence of the at least one patient care device and converting a communication signal from the device into a communication protocol associated with the dock.

[0089] In a specific embodiment, the communication interface is further configured to detect the presence of additional other patient care devices that are different from each other and convert a communication signal from the device into a communication protocol associated with the dock.

[0090] In another specific embodiment, the communication interface is further configured to provide power suitable for each device. In yet another specific embodiment, the system further includes one or more databases accessible by a dock that enables at least one of central storage of patient information and / or download information that can be used for treatment of a patient associated with the dock.

[0091] In yet another specific embodiment, the communication interface is further configured to perform a failure inspection on at least one of access data integrity of communication with the patient care device, evaluate whether the monitoring client is functioning properly, evaluate whether the patient care device is functioning properly, and / or evaluate whether the communication interface is functioning properly.

[0092] In an embodiment, the patient care device includes a main body, a track within the main body configured to receive a support column, and two functional members coupled to the main body and configured to functionally lock the main body to the support column within the track.

[0093] In an embodiment, the hub includes a patient care device interface, a power source coupled to the patient care device interface and configured to supply power to the patient care device, a processor, and a transceiver coupled to the patient care device interface configured to enable communication between the processor and the patient care device. The processor can be configured to disable the patient care device in some specific embodiments when in an alarm state.

[0094] In an embodiment, the dock includes a patient care device interface, a power source coupled to the patient care device interface and configured to supply power to the patient care device, a processor, and a transceiver coupled to the patient care device interface configured to enable communication between the processor and the patient care device. The processor can be configured to disable the patient care device in some specific embodiments when in an alarm state. In an embodiment, the communication module includes a patient care device interface, a power source coupled to the patient care device interface and configured to supply power to the patient care device, a processor, and a transceiver coupled to the patient care device interface configured to enable communication with the patient care device and another device. The processor, in some specific embodiments, can be configured to disable the patient care device when in an alarm state.

[0095] In another embodiment, the patient care system includes a dock, a plurality of modular patient care devices configured to dock with the dock, and a storage display for a monitoring client. The modular patient care devices can interface with the dock along a horizontal plane, alternately or via a connector. In yet another embodiment, the electronic patient care system includes a first module configured to receive and store information about a patient, the information including data related to a first parameter of the patient measured by a device connected to the patient and data related to a second parameter of the patient received from a first database containing information about the patient, and a second module configured to receive a medication instruction from a user via a user interface associated with the second module and further configured to transmit the treatment instruction to the first module. The first module is further configured to: a) obtain medication information from a second database, the medication information including data providing limitations on the normal administration of such a medication; b) determine, based on the medication information, the value of the first parameter, and the value of the second parameter, whether the medication instruction, in this particular embodiment, must be verified by the second module; and c) transmit from the first module to the second module a pre-established message for verifying the acceptability of the medication instruction or warning regarding it for display on the user interface.

[0096] As drug information, drug interaction information, drug allergy information, blood pressure effect information, heart rate effect information, cardiac rhythm effect information, or respiratory effect information can be cited, and the first parameter or the second parameter includes data related to the drug currently administered to the patient, known drug allergies, current blood pressure, current heart rate, current cardiac rhythm, current respiratory rate, or current ventilation.

[0097] The pre-established message can include a warning regarding the potential effect of the prescribed drug, and the warning includes measurement data regarding the first parameter, received data regarding the second parameter, or drug information obtained by the first module.

[0098] The first module can be configured to generate a signal for processing a drug instruction or a modified drug instruction when receiving a confirmation signal triggered by an input signal from the user interface after the pre-established message has been transmitted.

[0099] In another embodiment, the patient care device includes a first communication link and a second communication link, and the dock includes a first communication link and a second communication link. When the patient care device is within a predetermined range of the dock, the patient care device and the dock are paired using the first communication link, and after pairing, they remain in communication using the second communication link. Pairing that occurs using the first communication link enables the patient care device and the dock to be paired with respect to the second communication link. The first communication link may be short-range wireless communication, and the second communication link may be Bluetooth (registered trademark), Bluetooth Low Energy, WiFi, or other communication links.

[0100] In another embodiment, the patient care device includes a first communication link and a second communication link, and the monitoring client includes a first communication link and a second communication link. When the patient care device is within a predetermined range of the monitoring client, the patient care device and the monitoring client are paired using the first communication link, and after pairing, they remain in communication using the second communication link. Pairing that occurs using the first communication link enables the patient care device and the monitoring client to be paired with respect to the second communication link. The first communication link may be short-range wireless communication, and the second communication link may be Bluetooth, Bluetooth Low Energy, WiFi, or other communication links.

[0101] In some embodiments, the patient care device includes a memory in which a user interface template is stored. The user interface template can communicate with a dock, hub, and / or the monitoring client for display on the user interface of the dock, hub, and / or monitoring client. The user interface template can be configured to display one or more patient care parameters received from the patient care device (e.g., in real time).

[0102] In yet another embodiment, the infusion pump includes a removable electronic component. The removable electronic component includes at least one processor, a power regulator, and a control system.

[0103] In an embodiment, the communication module includes at least one processor and one or more of a transceiver, a battery, and a power source for providing at least one of communication capabilities and power to the patient care device.

[0104] In yet another embodiment, the wearable system monitor comprises a watchdog component and a transceiver. The wearable system monitor can comprise a processor coupled to the watchdog component and the transceiver to perform a watchdog function for at least one paired device. The paired device may be at least one of a dock, a hub, a monitoring client, and / or a patient care device.

[0105] In yet another embodiment, the method includes one or more of establishing a communication link between a patient care device and a monitoring server, communicating patient care parameters to the monitoring server, anonymizing the patient care parameters, and / or storing the anonymized patient care parameters in the monitoring server.

[0106] In yet another embodiment, the method includes one or more of establishing a communication link between a monitoring server and a plurality of patient care devices associated with a plurality of patients, communicating a plurality of patient care parameters from the plurality of patient care devices to the monitoring server, anonymizing the patient care parameters, storing the patient care parameters in the monitoring server, treating the plurality of patients, and analyzing a subset of the plurality of patient care parameters associated with the plurality of patients to determine the effectiveness of the treatment.

[0107] In yet another embodiment, the patient care device (e.g., an infusion pump) is hot swappable at at least one of a dock, a hub, and / or a monitoring client connection.

[0108] In yet another embodiment, a method having a hot-swappable patient care device, such as an infusion pump, includes one or more of receiving one or more patient care parameters associated with the patient care device, storing the one or more patient care parameters in a non-volatile memory of the patient care device, loading the one or more patient care parameters into an operating memory, and resuming operation of the patient care device. The method can, in additional embodiments, include determining that operation of the patient care device can be resumed.

[0109] In yet another embodiment, a method having a hot-swappable patient care device, such as an infusion pump, includes one or more of calculating one or more operating parameters associated with the patient care device, storing the one or more operating parameters in a non-volatile memory of the patient care device, loading the one or more operating parameters into an operating memory, and resuming operation of the patient care device. The method can, in additional embodiments, include determining that operation of the patient care device can be resumed.

[0110] In yet another embodiment, a pairing method includes positioning a hub having a monitoring client and / or a user interface within an operating range of a patient care device (e.g., an infusion pump), displaying identification information of the patient care device on the user interface, selecting the patient care device for pairing using the user interface, pairing the patient care device with the monitoring client and / or the hub, and / or communicating patient care parameters to the monitoring client and / or the hub. In yet another embodiment, and optionally, the method can include operably communicating additional patient care parameters to another patient care device via the patient care device, e.g., to the monitoring client and / or the hub.

[0111] In yet another embodiment, the method includes docking a patient care device within a dock, identifying the patient care device, querying a server for an application for controlling the patient care device, downloading the application into the dock, a hub, and / or a monitoring client, executing the application using the dock, the hub, and / or the monitoring client, and controlling the patient care device using the application.

[0112] In yet another embodiment, the method includes arranging for the patient care device to communicate operably with a hub. The hub can identify the patient care device, query a server for an application for controlling the patient care device, download the application into the hub, execute the application, and control the patient care device using the application.

[0113] In yet another embodiment, the method includes arranging for the patient care device to communicate operably with a dock. The dock can identify the patient care device, query a server for an application for controlling the patient care device, download the application into the dock, execute the application, and control the patient care device using the application.

[0114] In yet another embodiment, the method includes arranging for the patient care device to communicate operably with a monitoring client. The monitoring client can identify the patient care device, query a server for an application for controlling the patient care device, download the application into the monitoring client, execute the application, and control the patient care device using the application.

[0115] In yet another embodiment, the method can include presenting a request on a user interface of a communication device, confirming the request, sending the request, receiving the request with a check value, and verifying that the check value conforms to the request prior to transmission.

[0116] In yet another embodiment, the hub includes a dock for receiving a patient care device and at least one connector coupled to an open door configured to receive another patient care device.

[0117] In yet another embodiment, the hub operably communicates with at least one of an electronic medical record, DERS, CPOE, and / or the Internet to control and / or monitor a patient care device.

[0118] In another embodiment, the hub is adapted to connect to a cradle to control one or more patient care devices coupled to the cradle.

[0119] In yet another embodiment, the battery pack includes a patient care device interface, a battery, and a regulated power supply configured to use the battery to power a patient care device. The battery can be recharged using a DC power supply in some embodiments.

[0120] In an embodiment, the patient care device includes a screen and an accelerometer. The patient care device is configured to display the screen in an upright position as determined using the accelerometer.

[0121] In yet another embodiment, the electronic patient care system includes a monitoring client and a dock configured to couple to a support. An adapter can be coupled to the dock. The adapter can include at least one electrical coupler to position a patient care device to communicate operably with the monitoring client. The patient care device can slide within the adapter.

[0122] In yet another embodiment, the electronic patient care system includes a monitoring client, a patient care device, and a communication module. The patient care device and / or the communication module are fault-tolerant with respect to the monitoring client. For example, the monitoring client cannot instruct the patient care device to perform an unsafe operation.

[0123] In the following embodiments, bases can include, for example, medical devices, docks, cradles, hubs, pill dispensers, syringe pumps, infusion pumps, microinfusion pumps, communication modules, ECG monitors, blood pressure monitors, pulse oximeters, CO2 capnometers, communication relays, and the like.

[0124] In another embodiment, a method incorporated into a set of executable instructions for a processor includes determining whether a monitoring client is connected to a base via a physical connection, establishing a communication link between the monitoring client and the base via the physical connection, updating, if necessary, an interface program between the monitoring client and the base via a first communication link, establishing a second communication link between the monitoring client and the base using the first communication link, and communicating data from the base to the monitoring client using the second communication link.

[0125] In another embodiment, the method incorporated into a set of executable instructions for a processor is performed when the processor is on the monitoring client.

[0126] In another embodiment, a method incorporated into a set of executable instructions for a processor is performed when the processor is on the base.

[0127] In another embodiment, when an operation of communicating data from the base to the monitoring client using a second communication link includes the step of the base communicating data to the monitoring client using the second communication link, a method incorporated into a set of executable instructions for a processor is performed.

[0128] In another embodiment, when an operation of communicating data from the base to the monitoring client using a second communication link includes the step of the monitoring client receiving data using the second communication link, a method incorporated into a set of executable instructions for a processor is performed.

[0129] In another embodiment, a method incorporated into a set of executable instructions for a processor further includes the step of displaying data to the monitoring client according to data communicated from the base.

[0130] In another embodiment, a method incorporated into a set of executable instructions for a processor further includes the step of initializing treatment of a patient using the monitoring client.

[0131] In another embodiment, a method incorporated into a set of executable instructions for a processor that further includes the step of initializing treatment of a patient using the monitoring client further includes the step of treating the patient using the base.

[0132] In another embodiment, a method incorporated into a set of executable instructions for a processor that further includes the step of initializing treatment of a patient using the monitoring client further includes the step of treating the patient using a hemodialysis system as the base.

[0133] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor further involves a step of a monitoring client sending a treatment start signal based on a base.

[0134] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor involves a step of removing a physical connection between the monitoring client and the base.

[0135] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor involves a step of removing a physical connection between the monitoring client and the base, and further involves a step of continuing communication between the monitoring client and the base using a second communication link.

[0136] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor involves a step of removing a physical connection between the monitoring client and the base, and further involves a step of continuing communication between the monitoring client and the base using a second communication link, and further comprises a step of monitoring a link quality value of the second communication link.

[0137] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor further involves a step of performing data communication between the monitoring client and the base as long as the link quality value exceeds a predetermined threshold.

[0138] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor further involves a step of putting the monitoring client into a headless state when the link quality value becomes smaller than a first predetermined threshold.

[0139] In another embodiment, a method incorporated into a set of executable instructions for a processor comprises the step of putting the monitoring client into a headless state when the link quality value becomes less than a first predetermined threshold, and in response to the headless state, the monitoring client further comprises the step of displaying a message on the user interface.

[0140] In another embodiment, a method incorporated into a set of executable instructions for a processor comprises the step of putting the monitoring client into a headless state when the link quality value becomes less than a first predetermined threshold, and the message is characterized in that it is displayed to the user so as to bring the monitoring client closer to the base.

[0141] In another embodiment, a method incorporated into a set of executable instructions for a processor that includes the step of putting the monitoring client into a headless state when the link quality value becomes less than a first predetermined threshold further comprises the step of periodically determining for each link quality value whether it is greater than the first predetermined threshold.

[0142] In another embodiment, a method incorporated into a set of executable instructions for a processor that includes the step of putting the monitoring client into a headless state when the link quality value becomes less than a first predetermined threshold further comprises the step of exiting the headless state when the link quality value becomes greater than the first predetermined threshold.

[0143] In another embodiment, a method incorporated into a set of executable instructions for a processor that includes the step of putting the monitoring client into a headless state when the link quality value becomes less than a first predetermined threshold further comprises the step of exiting the headless state when the link quality value becomes greater than a second predetermined threshold greater than the first predetermined threshold.

[0144] In another embodiment, the method incorporated into the set of executable instructions of the processor involves, as necessary, communicating the version number of the interface program from the monitoring client to the base via a first communication link, determining whether the interface program on the monitoring client is the latest version, retrieving the updated version of the interface program from the server by the base, and overwriting the interface program with the updated version of the interface program, and involves the operation of updating the interface program on the monitoring client.

[0145] In another embodiment, in the method incorporated into the set of executable instructions of the processor, the step of establishing a second communication link between the monitoring client and the base using the first communication link involves determining whether the base is paired with another monitoring client, interrupting any pairing between the other monitoring client and the base as necessary, generating a configuration file using the base, communicating the configuration file from the base to the monitoring client using the first communication link, reading the configuration file received from the base by the monitoring client, and pairing the base with the monitoring client for wireless communication to establish a second communication link between the monitoring client and the base according to the configuration file.

[0146] In another embodiment, the method incorporated into the set of executable instructions of the processor involves putting the monitoring client into a headless state when the link quality value is less than a predetermined threshold, temporarily suspending data communication between the base and the monitoring client, and displaying a message requesting the user to move the monitoring client closer to the base on a graphical user interface.

[0147] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor includes steps of putting the base into a headless state when the link quality value is less than a predetermined threshold, temporarily halting data communication between the base and the monitoring client, and indicating that the base has become headless.

[0148] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor configured to be executed by a processor includes steps of performing data communication between the monitoring client and the base as long as the link quality value is greater than a predetermined threshold, putting it into a headless state if the link quality value is less than the predetermined threshold, keeping it in the headless state as long as the link quality value is less than the predetermined threshold, determining whether the link quality value has become greater than the predetermined threshold, and ending the headless state if the link quality value has become greater than the predetermined threshold.

[0149] In another embodiment, the method incorporated into the set of operations of instructions executable by a processor configured to be executed by a processor includes steps of performing data communication between the monitoring client and the base as long as the link quality value is greater than a first predetermined threshold, putting it into a headless state if the link quality value is less than the first predetermined threshold, keeping it in the headless state as long as the link quality value is less than a second predetermined threshold, determining whether the link quality value has increased and become greater than the second predetermined threshold, and ending the headless state if the link quality value exceeds the second predetermined threshold.

[0150] In an embodiment of the present disclosure, in a system for communicating between a monitoring client and a base, the system includes a base having a communication component. The communication component communicates data between the monitoring client and the base as long as the link quality value is greater than a predetermined threshold. When the link quality value becomes smaller than the predetermined threshold, it enters a headless state and remains in the headless state as long as the link quality value is smaller than the predetermined threshold, determines whether the link quality value has become greater than the predetermined threshold, and is configured to end the headless state when the link quality value becomes greater than the predetermined threshold.

[0151] In an embodiment of the present disclosure, in a system for communicating between a monitoring client and a base, the system includes a base having a communication component. The communication component communicates data between the monitoring client and the base as long as the link quality value is greater than a first predetermined threshold. When the link quality value is smaller than the first predetermined threshold, it enters a headless state and remains in the headless state as long as the link quality value is smaller than a second predetermined threshold, determines whether the link quality value has increased and become greater than the second predetermined threshold, and is configured to end the headless state when the link quality value exceeds the second predetermined threshold.

[0152] In an embodiment of the present disclosure, in a system for communicating between a monitoring client and a base, the system includes a base having an update component. The update component determines whether a monitoring client is connected to the base via a physical connection, establishes a first communication link between the monitoring client and the base via the physical connection, updates an interface program between the monitoring client and the base via the first communication link as needed, establishes a second communication link between the monitoring client and the base using the first communication link, and is configured to communicate data from the base to the monitoring client via the second communication link.

[0153] In embodiments of the present disclosure, the base is one of a medical device, a dock, a cradle, a hub, a pill dispenser, a syringe pump, an infusion pump, a micro-infusion pump, a communication module, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO2 capnometer, and a communication relay.

[0154] In embodiments of the present disclosure, the update component is executed within a sandbox. In some embodiments, the sandbox can be equipped in at least one of a hub, a dock, and a cradle.

[0155] In embodiments of the present disclosure, a system enabling electronic patient care includes a monitoring client connected to the base via a physical connection, and at least one of the monitoring client and the base having a processor configured to perform at least one of establishing a first communication link between the monitoring client and the base via the physical connection, updating an interface program between the monitoring client and the base via the first communication link, and establishing a second communication link between the monitoring client and the base using the first communication link.

[0156] In embodiments of the present disclosure, the processor is equipped in the monitoring client. In embodiments of the present disclosure, the processor is equipped in the base. In embodiments of the present disclosure, the second communication link transmits data from the base to the monitoring client. In embodiments of the present disclosure, the monitoring client receives data using the second communication link. In embodiments of the present disclosure, the monitoring client is configured to display data transmitted from the base. In embodiments of the present disclosure, the monitoring client is configured to initialize patient treatment. In embodiments of the present disclosure, the base is configured to treat a patient. In embodiments of the present disclosure, the base is a hemodialysis system.

[0157] In an embodiment of the present disclosure, the base is a patient care device. In an embodiment of the present disclosure, the patient care device is selected from the group consisting of an infusion pump, a pill dispenser, a micro-infusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO2 capnometer, an intravenous bag, and a drip flow meter.

[0158] In an embodiment of the present disclosure, the system further comprises a monitoring client configured to send based on a treatment start signal. In an embodiment of the present disclosure, the communication link between the monitoring client and the base is wireless. In an embodiment of the present disclosure, the base is configured to monitor the link quality value of the second communication link. In an embodiment of the present disclosure, the system is configured to perform data communication between the monitoring client and the base as long as the link quality value is greater than a predetermined threshold.

[0159] In an embodiment of the present disclosure, the monitoring client is configured to enter a headless state when the link quality value becomes less than a first predetermined threshold. In an embodiment of the present disclosure, the monitoring client is configured to display a message on the user interface in response to the headless state. In an embodiment of the present disclosure, the message is displayed to the user to bring the monitoring client closer to the base. In an embodiment of the present disclosure, the base is configured to periodically determine for each link quality value whether each link quality value is greater than a first predetermined threshold.

[0160] In an embodiment of the present disclosure, the base is configured to exit the headless state when the link quality value is greater than a first predetermined threshold. In an embodiment of the present disclosure, the base is configured to exit the headless state when the link quality value is greater than a second predetermined threshold greater than the first predetermined threshold.

[0161] In an embodiment of the present disclosure, the monitoring client and the base are configured such that the monitoring client transmits the version number of the interface program to the base via a first communication link, the monitoring client is further configured to determine whether the interface program on the monitoring client is the latest version, the base is configured to retrieve the updated version of the interface program from the server, and the base is further configured to overwrite the interface program with the updated version of the interface program. At least one update of the interface program is configured to be performed via the first communication link such that at least one of the above is satisfied.

[0162] In an embodiment of the present disclosure, the system is configured such that the processor determines whether the base is paired with other monitoring clients, the processor is further configured to interrupt any pairing between the base and other monitoring clients as needed, the base is configured to generate a configuration file, the first communication link is configured to communicate the configuration file from the base to the monitoring client, the monitoring client is configured to read the configuration file received from the base, the base is paired with the monitoring client for wireless communication, and the base paired with the monitoring client for wireless communication establishes a second communication link between the monitoring client and the base according to the configuration file. The second communication link between the monitoring client and the base is configured to be established using the first communication link such that at least one of the above is satisfied. In yet another embodiment, the tablet includes one or more processors and memory. The memory has a set of executable instructions configured to cause the processor to determine whether the tablet is connected to a base via a physical connection, establish a first communication link between the tablet and the base via the physical connection, update an interface program on the tablet via the first communication link as needed, establish a second communication link between the tablet and the base using the first communication link, and transmit data from the base to the tablet using the second communication link.

[0163] The tablet can be configured to (1) monitor the operation of the base, (2) control the operation of the base, (3) receive an error state from the base, (4) monitor the operation of the base to determine whether an error state exists, (5) monitor the operation of the base to determine whether an unsafe state exists, (6) store error parameters or operation parameters for transmission to a server, (7) store error parameters or operation parameters for transmission to the base for storage, (8) store error parameters or operation parameters for transmission to the base for relay to a server, and / or (9) provide entertainment selected from the group consisting of video games, movies, pre-recorded music, and web browsing to a patient while the patient is receiving treatment.

[0164] These and other aspects will become more apparent from the following detailed description of various embodiments of the disclosure with reference to the drawings.

Brief Description of the Drawings

[0165]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Figure 40

Figure 41

Figure 42

Figure 43

Figure 44

Figure 45

Figure 46

Figure 47

Figure 48

Figure 49

Figure 50

Figure 51

Figure 52

Figure 53

Figure 54

Figure 55

Figure 56

Figure 57

Figure 58

Figure 59

Figure 60

Figure 61

Figure 62

Figure 63

Figure 64

Figure 65

Figure 66

Figure 67

Figure 68A

Figure 68B

Figure 69

Figure 70

Figure 71

Figure 72A

Figure 72B

Figure 73

Figure 74

Figure 75

Figure 76

Figure 77

Figure 78

Figure 79

Figure 80A

Figure 80B

Figure 81

Figure 82A

Figure 82B

Figure 83

Figure 84

Figure 85

Figure 86

Figure 87

Figure 88

Figure 89

Figure 90

Figure 91

Figure 92

Figure 93

Figure 94

Figure 95

Figure 96

Figure 97

Figure 98

Figure 99

Figure 100

Figure 101

Figure 102

Figure 103

Figure 104

Figure 105

Figure 106

Figure 107

Figure 108

Figure 109

Figure 110

Figure 111

Figure 112

Figure 113

Figure 114

Figure 115

Figure 116

Figure 117

Figure 118

Figure 119

Figure 120

Figure 121

Figure 122

Figure 123

Figure 124

Figure 125

Figure 126

Figure 127

Figure 128

Figure 129

Figure 130

Figure 131

Figure 132

Figure 133

Figure 134

Figure 135

Figure 136

Figure 137

Figure 138

Figure 139

Figure 140

Figure 141

Figure 142

Figure 143

Figure 144

Figure 145

Figure 146

Figure 147

Figure 148

Figure 149

Figure 150

Figure 151

Figure 152

Figure 153A

Figure 153B

Figure 154

Figure 155

Figure 156

Figure 157

Best Mode for Carrying Out the Invention

[0166] Techniques for facilitating patient care are disclosed. The techniques can be implemented, for example, in a system having one or more patient care devices communicatively coupled to a monitoring client according to an exemplary embodiment. The patient care devices can include any number of diverse functions and / or can be manufactured by different manufacturers. In such one case, the communication interface between the client monitoring station and the various diverse patient care devices enables discovery and protocol conversion, as well as various other functions such as power supply, compliance with various standards, and user interface. The patient care devices can be infusion pumps, microinfusion pumps, insulin pumps, syringe pumps, pill dispensers, dialyzers, ventilators, ultrasonic diagnostic devices, ECG monitors, blood pressure monitors, pulse oximeters, CO2 capnometers, drip counters, drip flow meters, optical Doppler devices, heart rate monitors, intravenous bags, hemodialyzers, peritoneal dialyzers, intestinal dialyzers, patient thermometers, and / or other bedside patient care devices. U.S. Patent Application No. 11 / 704,899, filed on February 9, 2007, titled "Fluid Delivery System and Method," and published as U.S. Patent Application Publication No. 2007-0228071-A1 (Attorney Docket No. E70) on October 4, 2007, U.S. Patent Application No. 11 / 704,896, filed on February 9, 2007, titled "Pump Fluid Delivery System and Method of Using a Force Applying Assembly," and published as U.S. Patent Application Publication No. 2007-0219496 (Attorney Docket No. E71) on September 20, 2007, U.S. Patent Application No. 11 / 704,886, filed on February 9, 2007, titled "Patch Size Fluid Delivery System and Method," and published as U.S. Patent Application Publication No. 2007-0219481 (Attorney Docket No. E72) on September 20, 2007, U.S. Patent Application No. 11 / 704, filed on February 7, 2007, titled "Adhesive and Peripheral System and Method for Medical Devices,"No. 897, and U.S. Patent Application Publication No. 2007-0219597 (Attorney Docket No. E73), published on September 20, 2007, U.S. Patent Application No. 12 / 347,985, filed on December 31, 2008, entitled "Infusion Pump Assembly", and then U.S. Patent Application Publication No. 2009-0299277 (Attorney Docket No. G75), published on December 3, 2009, U.S. Patent Application No. 12 / 347,982, filed on December 31, 2008, entitled "Wearable Pump Assembly", and then U.S. Patent Application Publication No. 2009-0281497 (Attorney Docket No. G76), published on November 12, 2009, U.S. Patent Application No. 12 / 347,981, filed on December 31, 2008, entitled "Infusion Pump Assembly", and then U.S. Patent Application Publication No. 2009-0275896 (Attorney Docket No. G77), published on November 5, 2009, U.S. Patent Application No. 12 / 347,984, filed on December 31, 2008, entitled "Pump Assembly with Switch", and then U.S. Patent Application Publication No. 2009-0299289 (Attorney Docket No. G79), published on December 3, 2009, U.S. Patent Application No. 12 / 249,882, filed on October 10, 2008, entitled "Infusion Pump Assembly", and then U.S. Patent Application Publication No. 2010-0094222 (Attorney Docket No. F51), published on April 15, 2010, U.S. Patent Application No. 12 / 249,636, filed on October 10, 2008, entitled "System and Method for Administering an Injectable Fluid", and then U.S. Patent Application Publication No. 2010-0094261 (Attorney Docket No. F52), published on April 15, 2010, U.S. Patent Application No. 12 / 249,621, filed on October 10, 2008, entitled "Occlusion Detection System and Method", and then U.S. Patent Application Publication No. 2010-0090843 (Attorney Docket No. F53), published on April 15, 2010, U.S. Patent Application No. 12 / 249, filed on October 10, 2008, entitled "Multi-Language / Multi-Processor Infusion Pump Assembly",No. 600, and all of U.S. Patent Application Publication No. 2010-0094221 (Attorney Docket No. F54), published on April 15, 2010, U.S. Patent No. 8,066,672 (Attorney Docket No. F55), issued on November 29, 2011, entitled Infusion Pump Assembly with Backup Power Supply, U.S. Patent No. 8,016,789 (Attorney Docket No. F56), issued on September 13, 2011, entitled Pump Assembly with Removable Cover Assembly, and U.S. Patent No. 7,306,578 (Attorney Docket No. C54), issued on December 11, 2007, entitled Loading Mechanism for Infusion Pumps, are hereby incorporated by reference in their entirety. Techniques can be used to enable seamless communication and fail-safe operation. Numerous other features, functions, and applications will be apparent in light of the present disclosure.,

[0167] General Overview As described previously, the process of providing comprehensive care to a patient, such as the instruction and delivery of medical treatment, is associated with several important issues. For example, there is a significant potential for important information to be communicated incorrectly, treatment decisions to be made without access to complete information, and / or delays in the implementation of prescriptions due to unnecessary redundancy and inadequate procedures.,

[0168] More specifically, medication errors can be the cause of hundreds of deaths and can injure thousands or even millions of people each year in the United States alone. Hospitals under financial pressure may experience many medication error incidents. Medications associated with many dangerous errors include insulin, narcotics, heparin, and chemotherapy. Causes of medication errors include administering the wrong drug, administering the drug at the wrong concentration, delivering the drug at the wrong rate, or delivering the drug by the wrong route (the drug can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, eyes or ears, intrathecally, intraperitoneally, or even into the bladder). Even with proper order and proper labeling, medications can still be inappropriately administered due to illegible handwriting, incorrect transmission of the drug prescription, and mispronunciation of drugs with similar names. There has been a tendency to use electronic medical records (EMRs) and barcode systems for medications to reduce medication error incidents. EMR systems can facilitate computer provider order entry (CPOE) and flagged prescriptions, for example, that do not match the patient's diagnosis, allergies, weight, and / or age. However, these systems have not been widely adopted and their implementation can lead to significant delays and inefficiencies in prescribing, preparing, and administering medications.

[0169] In addition, drug infusion devices, such as infusion pumps, are associated with a significant number (e.g., up to one-third) of all medication errors that can lead to significant harm. There is a possibility that the wrong drug is hung, incorrect parameters (e.g., drug concentration or infusion rate) are entered, or existing infusion parameters are inappropriately changed. Nearly half of the deaths associated with infusion pumps are due to user error, and many of these errors may be due to mistakes in programming the infusion pump.

[0170] An effective monitoring system can monitor and arbitrate at every stage of the medication order and administration process to minimize any of the several adverse events that may result from treatment. The medication treatment process can conceptually be divided into three stages: the prescription stage, the medication preparation stage, and the medication administration stage. Errors can occur when a medication prescription is written or entered, when the medication is retrieved for use or mixed in a solution, or when the medication is administered to a patient.

[0171] According to an embodiment of the present disclosure, there is disclosed an electronic patient care system comprising a monitoring client configured to communicate at least one patient care parameter, a patient care device configured to communicate at least one patient care parameter, and a communication interface configured to facilitate communication between the monitoring client and the at least one patient care device by detecting the presence of the at least one patient care device and converting a communication signal from the device into a communication protocol associated with the monitoring client. In some embodiments, the monitoring client passively monitors the operation of the patient care device. The communication interface can be implemented by the communication module described below. The communication interface can further be configured to detect the presence of other additional patient care devices different from each other (e.g., various manufacturers, functions, and / or communication protocols, etc.) and convert communication signals from these devices into a communication protocol associated with the monitoring client or a hub. Thus, the communication interface enables a monitoring client such as a tablet computer to be effectively used as a common general user interface that can be used by a healthcare provider when providing treatment to a patient associated with the monitoring client. One or more databases accessible by the monitoring client enable central storage of patient information (in any format and database structure desired by the healthcare facility or database custodian) and downloading of information that can be used by a healthcare provider during treatment of a patient associated with the monitoring client. The communication interface can be implemented in several ways using wired and / or wireless technologies, enabling seamless communication and fail-safe operation of a large number of patient care devices. Some patient care devices, hubs, docks, and / or monitoring clients can communicate simultaneously on two or more communication links and / or simultaneously on two frequency channels (in some embodiments, the data may be redundant).In some embodiments, the communication module enables the patient care device to be used portably, for example, by including a battery for moving the patient care device, such as an infusion pump, and sufficient circuitry. In addition or alternatively, the patient wristband can be provided with a battery (or, in some embodiments, can be directly plugged into the patient care device) that can be plugged into the communication module to power the patient care device. The communication module can be wirelessly charged.

[0172] In some embodiments, data such as patient care parameters (e.g., in some embodiments, real-time parameters) can be transmitted to and anonymized on a cloud server for storage.

[0173] System Architecture As shown in FIG. 1, an electronic patient care system 100 includes one or more monitoring clients 1, 4 that can be physically assigned in close proximity to individual patients 2 respectively, and a remote monitoring server 3 that uploads information from various monitoring clients 1, 4 and downloads information and instructions to the monitoring clients 1, 4 from various sources. In the case of a patient's room, a healthcare provider can interact directly with the monitoring client 1 to obtain information about or enter instructions regarding the patient 2. A number of monitoring clients 1 can interact with a single monitoring server 3. The monitoring server 3 can include middleware (e.g., middleware on the monitoring server 3 in FIG. 1). In addition or alternatively, providers at remote locations (e.g., a doctor's office, a nurse station 5, a hospital pharmacy 6) can interact directly with individual monitoring clients 1 through a communication link with the monitoring server 3 or via a hospital local area network having each monitoring client 1, 4 as a node.

[0174] The prescription sent to update the patient's personal EHR19 or sent to the pharmacy 6 for dispensing may be filled in by the remote communicator 11, other monitoring client 4, nurse station 5, or doctor's office. The prescription may be for pills, for injecting fluids, or for other treatments. The prescription may be for injecting fluids using an infusion pump 7, syringe pump 126, or microinfusion pump 130, or for dispensing pills using a pill dispenser 128.

[0175] The pharmacy 6 can be equipped with one or more computers connected to a network, such as the Internet, to receive prescriptions in one or more computers and place the prescriptions in a queue. The pharmacy can (1) compound the drug (e.g., using an automatic compounding device capable of compounding fluids or generating pills coupled to one or more computers or manually by a pharmacist monitoring the queue of one or more computers), (2) pre-fill the fluid reservoir of the syringe pump 126, (3) program the syringe pump 126 (e.g., the treatment plan is programmed into the syringe pump 126), (4) pre-fill the microinfusion pump 130, (5) program the microinfusion pump 130, (6) pre-fill the intravenous bag 170, (7) program the infusion pump 7, (8) pre-fill the pill dispenser 128, or (9) use the prescription to program the pill dispenser 128 at the pharmacy according to the prescription. The automatic compounding device can automatically fill the fluid in one or more of the syringe pump 126, intravenous bag 170, or microinfusion pump 130, and / or can automatically fill the pill dispenser 128 with pills. The automatic compounding device can generate barcodes, RFID tags, and / or data. Information in the barcode, RFID tag, and / or data can include the treatment plan, prescription, and / or patient information.

[0176] The automatic matching device can (1) attach a barcode to the infusion pump 7, syringe pump 126, micro-infusion pump 130, pill dispenser 128, or intravenous bag 170, (2) attach an RFID tag to the infusion pump 7, syringe pump 126, micro-infusion pump 130, pill dispenser 128, or intravenous bag 170, and / or (3) program the RFID tag or memory in the infusion pump 7, syringe pump 126, micro-infusion pump 130, pill dispenser 128, or intravenous bag 170 with information or data. The data or information can be transmitted to a database (e.g., the patient's EHR 19 or the patient's personal EHR 19') that associates a prescription with the infusion pump 7, syringe pump 126, micro-infusion pump 130, pill dispenser 128, or intravenous bag 170 using, for example, a serial number or other identification information in a barcode, RFID tag, or memory.

[0177] The infusion pump 7, syringe pump 126, micro-infusion pump 130, or pill dispenser 128 can have a scanner (e.g., an RFID interrogator or barcode scanner) that determines whether (1) the syringe pump 126 or the intravenous bag 170 has the correct fluid, (2) the micro-infusion pump 130 has the correct fluid, (3) the pill dispenser 128 has the correct pill, (4) the treatment programmed in the infusion pump 7, syringe pump 126, micro-infusion pump 130, or intravenous bag 170 corresponds to the fluid in the syringe pump 126, micro-infusion pump 130, or intravenous bag 170, (5) the treatment programmed in the pill dispenser 128 corresponds to the pill in the pill dispenser 128, and / or (6) the treatment programmed in the infusion pump 7, syringe pump 126, micro-infusion pump 130, or pill dispenser 128 is correct for a particular patient (e.g., as determined from the patient's barcode, RFID, or other patient identification information). That is, in some particular embodiments, the infusion pump 7, syringe pump 126, micro-infusion pump 130, and / or pill dispenser 128 can read one or more serial numbers from an RFID tag or barcode and ensure that the values match values that can be seen in the internal memory (e.g., downloaded via an automated compounding device), or that the values match values that can be seen in the patient's electronic health record via the patient's serial number (e.g., as determined by scanning the patient's RFID tag or the patient's barcode scan and stored in the patient's EHR 19 or the patient's personal EHR 19').

[0178] For example, a scanner of an infusion pump 7, a syringe pump 126, a micro-infusion pump 130, or a pill dispenser 128 can scan a barcode of another patient care device to obtain the serial number of the patient care device and a barcode of the patient to determine the serial number of the patient, and query the electronic medical record data to determine whether the serial number of the patient care device corresponds to the serial number of the patient that may be stored in the electronic medical record (e.g., updated by a pharmacy 22 or an automatic dispensing device of the pharmacy).

[0179] In addition to, or as an alternative to, the monitoring client 6 may determine whether (1) the syringe pump 126 or the intravenous bag 170 has the correct fluid, (2) the microinfusion pump 130 has the correct fluid, (3) the pill dispenser 128 has the correct pills, (4) the treatment programmed into the infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 corresponds to the fluid within the syringe pump 126, microinfusion pump 130, or intravenous bag 170, (5) the treatment programmed into the pill dispenser 128 corresponds to the pills within the pill dispenser 128, and / or (6) the treatment programmed into the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 is correct for a particular patient (as determined, for example, from the patient's barcode, RFID, or other patient identification information) by scanning the infusion pump 7, syringe pump 126, pill dispenser 128, microinfusion pump 130, or intravenous bag 170. In addition to, or as an alternative to, the monitoring client 1, infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 may query the electronic medical record database 19 or 19' and / or the pharmacy 22 to verify or download a prescription, for example, using the barcode serial number on the infusion pump 7, syringe pump 126, microinfusion pump 130, pill dispenser 128, or intravenous bag 170.

[0180] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send instructions or requests to the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, for example, to send a bolus amount, infusion flow rate, total delivery fluid, start time of drug delivery, stop time of drug delivery, or delivery flow profile to the infusion pump 7, syringe pump 126, and / or micro-infusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests, such as pill dispensing instructions, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria, to the pill dispenser 7. The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval. For example, a particular drug is taken as needed (i.e., when needed), but if taken in excess, the drug may not be safe. The maximum pill dispensing criteria can prevent the drug from being taken in an unsafe level by the patient, for example, in a given amount during a given time interval.

[0181] Optionally, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 100 is operating properly or within a predetermined boundary, and / or return data to the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11 for display on the displays of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 can communicate to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 (where applicable) upstream pressure, change in upstream pressure, downstream pressure with respect to the patient 2, change in downstream pressure with respect to the patient 2, presence or absence of air in the infusion line, actual bolus amount delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile. In another embodiment, the pill dispenser 128 can optionally return data to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11, such as, for example, the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether a maximum pill dispensing criterion has been exceeded.

[0182] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition in order to issue an alarm and / or alert. For example, one or more of monitoring clients 1, 4, 11 can use an increase in downstream pressure of infusion pumps 7, syringe pumps 126, and / or micro-infusion pumps 130, which is an indication of excessive clotting, infiltration, occlusion, or kinking of tubing to the patient, or an occlusion occurring downstream by a material such as contamination seen within intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of monitoring clients 1, 4, 11 can visually and / or audibly warn or alert the user. These alarms and / or alerts can also inform the nurse to make other appropriate actions, such as suggesting to change the needle in response to an occlusion (e.g., caused by clotting) when the downstream pressure on the patient rises above a predetermined threshold, or suggesting to check for kinks in the line when the downstream pressure on the patient rises above a predetermined threshold.

[0183] In addition or alternatively, a sudden drop in downstream pressure for patient 2 is an indication that the tubing has come off the needle and / or the needle has now come out of the patient, and in response, one or more of monitoring clients 1, 4, 11 can visually and / or audibly warn or alert the user to reattach the tubing to the needle or insert a new needle for continuous infusion. The alarm can also indicate that it may be necessary to act quickly, for example, there is a possibility that the patient is bleeding when the tubing has come off the needle, and the patient is bleeding from the unattached needle connector.

[0184] In some embodiments, in addition to, or alternatively, the upstream pressure for one or more infusion pumps 7 can be monitored for any upstream occlusion. For example, contamination in the intravenous bag 170 can block the tubing upstream of the infusion pump 7. Each time the infusion pump 7 attempts to pump fluid from the intravenous bag 170, the upstream pressure on the infusion pump 7 can drop lower than it would occur if there were no upstream occlusion. Thus, one or more of the monitoring clients 1, 4, 11 can issue an alarm or alert when the upstream pressure drops below a predetermined threshold, and propose or require that the occlusion be relieved, for example, by a caregiver replacing the tubing or the intravenous bag 170.

[0185] One or more of the monitoring clients 1, 4, 11 can optionally send instructions to one or more of the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 to stop the delivery of fluid in response to a sudden increase and / or decrease in the downstream pressure on the patient 2.

[0186] As shown in FIG. 1 and as in some embodiments, system 100 includes a monitoring client dock 102 and a device dock 104. The monitoring client dock 102 is configured to receive a monitoring client 1, and the device dock 104 is configured to receive one or more patient care devices to facilitate bedside patient care (described in more detail below). The device dock 104 is shown as being capable of receiving several patient care devices, but in other embodiments, the device dock 104 can receive one patient care device, multiple patient care devices, or any arbitrary number of patient care devices. Additionally, the monitoring client dock 102 is shown as being capable of receiving one monitoring client 1, but in other embodiments, the monitoring client dock 102 can receive two monitoring clients 1, three or more monitoring clients 1, or any arbitrary number of monitoring clients 1.

[0187] In an exemplary embodiment, cable 110 is coupled to both docks 102, 104 to provide a communication link therebetween. The cable 110 can be permanently attached to, or attachable to, one or both of the docks 102, 104. In addition to or as an alternative, the cable 110 can include one or more connectors (not explicitly shown) for plugging the cable into one or both of the docks 102, 104.

[0188] In some embodiments, docks 102, 104 can communicate with each other using one or more wires and / or waveguides within cable 110. For example, in embodiments of the present disclosure, cable 110 comprises an optical fiber waveguide to provide an optical communication link between docks 102, 104. In other embodiments, as would be appreciated in view of the present disclosure, cable 110 can be replaced with one or more wireless communication links (e.g., Bluetooth, etc.) if desired. Still other embodiments can utilize a combination of wired and wireless communication channels between docks 102, 104. Any number of suitable wired connection types can be used in various embodiments.

[0189] In some embodiments, the communication link between docks 102, 104 can use any known communication link such as serial communication, parallel communication, synchronous communication, asynchronous communication, packet-based communication, virtual circuit-based communication, etc. In addition or alternatively, in some embodiments, the communication link established between docks 102, 104 can utilize wireless communication, wired communication, connectionless protocols such as User Datagram Protocol (UDP), or connection-based protocols such as Transmission Control Protocol (TCP). For example, the communication between docks 102, 104 can be based on one or more of Universal Serial Bus standards, SATA, eSATA, FireWire, Ethernet® standards, Fibre Channel, Bluetooth, Bluetooth Low Energy, WiFi, any physical layer technology, any OSI layer technology, etc.

[0190] When the monitoring client 1 is docked to the monitoring client dock 102, the monitoring client 1 has access to the communication between the docks 102 and 104. For example, in some embodiments of the present disclosure, the monitoring client 1 can communicate with an electronic circuit, such as a memory, within the device dock 104 via a communication link provided by the cable 110. In addition or alternatively, the monitoring client 1 can communicate with any device docked to the device dock 104 through the communication link provided by the cable 110 and / or one or more wireless communication links (described in more detail below).

[0191] Referring further to the exemplary embodiment shown in FIG. 1, the device dock 104 can include various accessories, such as an attachable display 134, a camera 136, and a microphone 138, each of which is optional. Similarly, the monitoring client dock 102 can include various accessories, such as a camera 140 and a microphone 142, each of which is optional. The monitoring client 1 can include various accessories, such as a camera 144 and a microphone 146, each of which is optional. The cameras 136, 140, 144 can be used, for example, by face recognition software to authenticate or identify the presence of a provider (e.g., a nurse, nurse practitioner, doctor, etc.) and / or a patient. In addition or alternatively, the microphones 138, 142, and 146 can be used, for example, by voice recognition software to authenticate or identify the presence of a provider and / or a patient. As will be appreciated in view of the present disclosure, the cameras 136, 140, 144 and the microphones 138, 142, 146 can also be used, for example, to enable a patient to communicate with a remote care provider and / or to confirm the patient's identification information (e.g., using voice and / or face recognition technology, retinal scans, etc.) before treatment is initiated to ensure that the correct patient receives the correct treatment.

[0192] As shown in FIG. 1, in some embodiments, the monitoring client 1, the monitoring client dock 102, and the device dock 104 each have antennas 112, 106, and 108 for wireless communication (each antenna 112, 106, and / or 108 is optional). If the cable 110 is unplugged or communication between the docks 102, 104 via the cable 110 is otherwise interrupted or impaired, the monitoring client dock 102 and the device dock 104 can continue to communicate with each other using the wireless communication link established through the antennas 106, 108. In addition, if the monitoring client 1 is removed from the monitoring client dock 102, the monitoring client 1 can communicate directly with, for example, the device dock 104, and / or the monitoring client 1 can communicate with the device dock 104 by wirelessly communicating with the monitoring client dock 102 that relays the communication via the cable 110 or via the wireless communication link between the docks 102, 104. As described previously, the communication between the monitoring device 1 and the device dock 104 can be utilized by the monitoring client 1 to communicate with the various devices docked to the device dock 104.

[0193] In some embodiments, the monitoring client 1 can electrically determine whether one or more electrical contacts of one or more connectors are in electrical engagement with the monitoring client dock 102 to determine whether the cable 110 can be used as a communication link, for example, by measuring the voltage or impedance between two electrical contacts of a connector of the monitoring client 1 used for docking to the monitoring client dock 102 and for providing electrical communication between the monitoring client dock 102 and the monitoring client 1. Also, the monitoring client 1 can determine that the cable 110 is not available if it determines that the monitoring client 1 is not electrically coupled to the cable 110. In addition or alternatively, in some embodiments, a magnet within the dock 102 engages a Hall effect sensor within the monitoring client 1, and then the monitoring client 1 uses this to determine whether it is docked such that the cable 110 is not available as a communication link if the monitoring client 1 is not docked. In addition or alternatively, a circuit within the monitoring client dock 102 can send a signal to the monitoring client 1 if the cable is not available as a communication link. In some embodiments, the monitoring client 1 can periodically "ping" the device dock 104 via the cable 110. If the monitoring client does not receive a response from the device dock 104 within a predetermined time, the monitoring client 1 presumes that the cable 110 is not available as a communication link.

[0194] If the monitoring client 1 determines that cable 110 is not available for use as a communication link, the monitoring client 1 can send an alarm or alert to the remote communicator 11 that can issue an alarm or alert using a speaker and / or a vibration motor, warn or alert the remote communicator using a speaker and / or a vibration motor, and / or the monitoring client 1 can attempt to communicate with the patient care device via another communication link. The term "alert" as used herein is intended to include, for example, "soft" alerts such as alerts that do not draw attention to a person until a predetermined time has elapsed and the cause of the alert remains.

[0195] In some embodiments of the present disclosure, the monitoring client dock 102 includes one or more wires or waveguides from the monitoring client 1 to the cable 110 that use minimal circuitry or no circuitry. For example, in some embodiments of the present disclosure, the monitoring client dock 102 is a cradle that provides a direct electrical coupling from the monitoring client 1 to the cable 110. In addition or alternatively, in some embodiments of the present disclosure, the device dock 104 includes one or more wires or waveguides that use minimal circuitry or no circuitry to facilitate communication between the various docked devices and / or the monitoring client 1 via the monitoring client dock 102. The device dock 104 may be a cradle in some embodiments.

[0196] In embodiments of the present disclosure, each monitoring client 1 is assigned to a specific patient 2 and may be desk-based, portable, or handheld and can have display and user input capabilities. The monitoring client 1 may be portable and can facilitate efficient data viewing and data input, and the monitoring client 1 may be a notebook PC, netbook PC, tablet PC, "smartphone" with or without a touch screen. In addition or alternatively, in some embodiments, the monitoring client 1, and / or the remote communicator 11, can be docked or coupled to a cable connected to a much larger display, thereby making the much larger display (e.g., a 24-inch display) the display of the monitoring client 1 and / or the remote communicator 11, and the much larger display can have input capabilities such as touch screen capabilities, touch pen input capabilities, keyboard input capabilities, remote control input capabilities, etc. that are communicated to the monitoring client 1 and / or the remote communicator 11. For example, viewing of X-ray or patient imaging files can be facilitated by docking the monitoring client 1 and / or the remote communicator 11 to a monitoring dock coupled to a larger display, whereby a caregiver can view the patient imaging files using the larger display. The viewing dock can also charge the monitoring client and / or the remote communicator 11.

[0197] The monitoring client 1 can run a Linux (registered trademark)-based operating system, an Android-based operating system, a BlackBerry-based operating system, a tablet-based operating system, iOS, iPad (registered trademark) OS, iPhone (registered trademark) OS, etc. The designation of a specific monitoring client 1 to a specific patient 2 can be done using any of several methods, including (but not limited to) a unique patient identifier encoded on a barcode 114 or RFID tag 116 embedded within, for example, the list band 118. The device dock 104 is equipped with a scanner 120 to determine the unique patient identifier of the barcode 114 or RFID tag 116. The scanner 120 may be a laser barcode scanner, a CCD-based barcode scanner, a short-range communicator or pager, an RFID reader, etc. In other embodiments, the unique patient identifier can be based on the patient's biometric data. In one such exemplary case, biometric capabilities (e.g., face and / or voice recognition, retinal scan, blood type monitor, fingerprint scan, etc.) can be embedded within or associated with the monitoring client 1. The device dock 104 can communicate the unique patient identifier to the monitoring client dock 102, the monitoring client 1, the monitoring server 3, the remote communicator 11, other monitoring clients 4, another server, or an electronic computing device to facilitate the treatment of patient 2.

[0198] The monitoring client 1 can include one or more of a microprocessor, a microcontroller, a logic device, a digital circuit, an analog circuit, etc. for communicating (e.g., transmitting or receiving) information related to a patient's care, condition, disease, or treatment. For example, the monitoring client 1 can transmit or receive patient care parameters such as patient status parameters and / or patient treatment parameters. Some exemplary patient status parameters are measurements such as blood pressure, body temperature, heart rate, pulse oximeter, CO2 level, blood oxygen level, patient arousal, patient consciousness, patient response, etc. Some exemplary patient treatment parameters include the drugs being administered, the flow rate of drugs or fluids, the drug administration schedule, or other bedside treatment parameters.

[0199] In some embodiments, for example, the monitoring client 1 can be physically associated with, permanently attached to, attachable to, removable from, or removably attachable to the infusion pump 7. This can be achieved by a docking interface between two devices, such as the monitoring client dock 102 and the device dock 104. In such an embodiment, the monitoring client 1 can communicate with the pump 7 (or other patient care device) in several ways, including, for example, through electrical contact with the docks 102, 104, by an electrical connector, or wirelessly by using the respective antennas 112, 122A and the transceivers on each device. In addition or alternatively, the infusion pump can include pre-programmed treatment data indicating a specific treatment for a specific patient that is uploaded to the monitoring client 1 when the infusion pump 7 is operably communicating with the monitoring client 1.

[0200] The monitoring client 1 can also communicate with one or more databases within the facility 8, databases external to the facilities 9, 10, and / or healthcare providers using a portable communicator 11 (including, for example, physicians, nurses, and pharmacists). This can be achieved by a wired connection to the facility server 8 through a connector in the patient's room (such as, for example, a Category 5 local area network connector, USB, wired Ethernet, etc.), or wirelessly 12 (such as, for example, WiFi, 3G, 4G, EVDO, WiMax, etc.). In one embodiment, access to the intra- and extra-facility databases is mediated 13 through the monitoring server 3 (using, for example, middleware), and then software and application programming interfaces can be centralized to communicate with databases having heterogeneous organizations, formatting, and communication protocols. Thus, in embodiments of the present disclosure, any software updates can be largely limited to the monitoring server 3, reducing the maintenance requirements on individual monitoring clients 1, 4, 11. Optionally, the monitoring client 1 can receive information regarding the progress of treatment (such as operating parameters) and communicate with a patient treatment device, such as an infusion pump 7, to provide operating instructions to the patient treatment device. In another embodiment, the monitoring client 1 can also receive readout information from a device and potentially instruct the device 14, 15, 16, 17 to perform a reading if desired by the provider or by an algorithm, and communicate with a patient care device for diagnostic or monitoring purposes to receive patient status parameters (such as, for example, an electrocardiogram (ECG) monitor 14, a blood pressure (BP) monitor 15, a pulse oximeter or CO2 capnometer 16, or other devices such as a temperature monitor).

[0201] In embodiments of the present disclosure, the facility service 8 and / or the drug adverse event network 9 can also comprise a drug error reduction system (DERS). The DERS system can include a first set of predetermined criteria for triggering a soft alarm and / or a second set of predetermined criteria for triggering a hard alarm. The soft alarm can be disabled (e.g., stopped) by a caregiver using the injection pump 7 and / or the user interface of the monitoring client 1 (and may also be only an audible and / or vibrating alarm), while the hard alarm interrupts the treatment until the cause is removed.

[0202] In further additional embodiments of the present disclosure, the DERS system can include a first set of predetermined criteria that define soft limits and / or a second set of predetermined criteria that define hard limits. The hard and soft limits define treatment limits such as drug dosage limits based on dimensions, weight, age, other patient parameters, or other criteria. The soft limit can be disabled by a caregiver using the injection pump 7 and / or the user interface of the monitoring client 1 to start treatment, while the hard limit prevents the treatment from starting until the settings are changed to match the second set of predetermined criteria that define the hard limit, even though the treatment is outside the first set of predetermined criteria.

[0203] As can be further seen in the exemplary embodiment of FIG. 1, the system 100 also comprises communication modules 124A - 124K, each having a respective one of the antennas 122A - 122K. In some embodiments, each communication module 124A - 124K is optional and / or each device can have integrated communication capabilities. Each communication module 124A - 124K comprises a connector for coupling to a respective device. In other embodiments, each communication module 124A - 124K is permanently integrated with the device as shown attached in FIG. 1.

[0204] Each of the communication modules 124A - 124K optionally includes one or more transceivers for communicating with each other, with the device dock 104, with the monitoring client dock 102, with the monitoring client 1, with the remote communicator 11, with the monitoring server 3, over a local area network and / or a wide area network (e.g., the Internet), with the hub 802 (see FIG. 8), and / or with any other device having sufficient wireless communication capabilities for communication on one or more wireless links. In some particular embodiments, the communication modules 124A - 124K can operate, for example, as a wireless mesh network using, for example, IEEE802.14.4, Zigbee, XBee, Wibree, IEEE802.11, etc. In a more general sense, the communication between the modules 124A - 124K and other components of the system 100 (e.g., docks 102 and 104, monitoring clients 1, 4, 11, etc.) can be implemented using any wireless communication protocol that enables device discovery, handshake, and / or inter - device communication as described herein, in any of a static, dynamic, or ad - hoc topology (e.g., to accommodate the mobility of various medical devices associated with the monitoring clients 1, 4, 11 and / or the dock 104).

[0205] In other embodiments, each patient care device may not include a module or may include three or more modules (e.g., a communication module). For example, each module can have a specific function, such as WiFi, and the user can select a plurality of modules each having a specific function and can couple them together. The group of modules can then be applied to a patient care device, such as an infusion pump. Consider yet another example. Each module can have a primary processor, a backup processor, and functional circuitry, all operably communicating with each other. The functional circuitry can be a wireless transceiver, a battery, an interface for a touch screen or display (the display can be attached to the housing), a wire connection, Bluetooth, Bluetooth Low Energy, WiFi, 3G, 4G, a coprocessor, a control system (e.g., for controlling an infusion pump), drug delivery using a fluid measurement circuit, etc. The selected modules can be connected to each other, e.g., in a daisy chain, and then connected to the infusion pump. The selected modules can operably communicate with each other in this example, e.g., via CAN bus, wired communication, wireless, and / or others, to adjust their operation and / or function.

[0206] Each module can include a speaker and a microphone, respectively. When several modules are connected to each other, the modules can adjust their operation so that while another module is using the microphone, one module audibly sends a signal to the speaker to determine whether the speaker is functioning properly. Some modules can use their speakers at different frequencies, such that any one of the modules can sense the voice via its microphone and can demodulate different frequencies to simultaneously inspect some of the speakers. The inspection can be requested by a first module from a second module, and the second module can send the result of the inspection to the first module.

[0207] Continuing with reference to FIG. 1, one or more of communication modules 124A - 124K can also optionally include one or more batteries to power devices coupled thereto. For example, communication module 124A can be coupled to infusion pump 7 to power it. Other structures and functions of communication modules 124A - 124K can be included depending on the purpose and function of the associated devices. For example, in some embodiments, control of the infusion occurs at the infusion pump and input regarding the desired delivery occurs at the infusion pump, and thus, in some embodiments of the present disclosure, communication module 124A implements a control algorithm, such as a proportional integral derivative (PID) control loop, to control infusion pump 7. In such a case, monitoring client 1 can communicate a fluid flow rate signal to communication module 124A (e.g., via a wireless link), and then apply a signal corresponding to the fluid flow rate signal through an electrical contact coupled to a motor (not explicitly shown) of infusion pump 7 to achieve the desired flow rate. In some embodiments, infusion pump 7 provides one or more feedback signals from a flow meter provided within infusion pump 7 to communication module 124A, whereby communication module 124A can control the operation of infusion pump 7 (e.g., some aspects of the operation of a PID control system, etc.). The results can be delivered to monitoring client 1 for display to the user using a GUI, such as a QT - based GUI (in some embodiments, monitoring client 1 is a tablet). In addition or alternatively, in some embodiments, a drip flow meter 148 can be used to wirelessly communicate the flow rate to communication module 124A via communication module 124K and antenna 122K associated with drip flow meter 148.

[0208] As will be appreciated in view of the present disclosure, the communication modules 124A - 124K can be operably coupled to various patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. For example, referring further to FIG. 1, communication module 124B is operably coupled to syringe pump 126, and communication module 124C is operably coupled to pill dispenser 128. In addition or alternatively, communication module 124E is operably coupled to ECG monitor 12, communication module 124F is operably coupled to blood pressure monitor 15, communication module 124G is operably coupled to pulse oximeter / CO2 capnometer 16, communication module 124H is operably coupled to other monitor 17, communication module 124I is operably coupled to patient's intravenous access 35, and communication module 124K is operably coupled to drip flow meter 148. Each of the communication modules 124A - 124K can provide, for example, appropriate control systems, control algorithms, battery power, or other functions for the respective patient care devices 7, 14, 15, 16, 17, 35, 126, 128, or 148 to which they are coupled.

[0209] In addition or alternatively, in some embodiments, communication module 124D is docked within device dock 104 and is operably coupled to device dock 104 via a bus or backplane to communicate, for example, with any device attached to device dock 104, and also to communicate with the electronic circuitry within device dock 104, the electronic circuitry within monitoring client dock 102, and / or monitoring client 1. Optionally, communication module 124D can provide communication and / or power to any device docked within device dock 104, such as infusion pump 7, syringe pump 126, pill dispenser 128, or microinfusion pump 130. Note that the functionality of communication module 124D can also be integrated within the circuitry of device dock 104 itself.

[0210] In addition to, or alternatively to, in some embodiments, it is optional to configure each of the communication modules 124 to be replenished by a power source accessible through one or more wired power sources, e.g., a power source accessible through a bus or backplane within the device dock 104, to provide sufficient power supply to each of the devices 7, 14, 15, 16, 17, 35, 126, 148. As discussed previously, in some embodiments of the present disclosure, the communication module 124D provides sufficient power to the devices 7, 126, 128, 130, and 133.

[0211] As discussed previously, in some embodiments, each of the communication modules 124 is composed of a power circuit (e.g., a voltage converter, a regulation circuit, a rectification and filtering circuit, a buck circuit, a boost circuit, a buck-boost circuit, a switch-mode power supply, etc.) that provides sufficient power to the corresponding devices 7, 126, 128, and 130. In some such cases, this power circuit can be configured to enable the provision of various power supply characteristics (e.g., voltage levels, maximum load / current requirements, and A / C frequencies) associated with different patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. Any number of power supply and management schemes will be apparent in view of the present disclosure.

[0212] Optionally, in other embodiments of the present disclosure, a power module 132 having one or more battery cells, such as lithium-ion battery cells, is attached to the device dock 104 to provide sufficient power to devices 7, 126, 128, 130, 133 over the entire treatment duration. Additionally or alternatively, the power module 132 can be plugged into an outlet in the patient's room (generally shown as an AC source in FIG. 1) if available. In such cases, if available, outlet power can be used to power the devices in the dock 104 and also to charge the batteries included within the power module 132 (which can occur simultaneously). If the outlet power is lost or otherwise unavailable, the batteries within the power module 132 and / or communication modules 124A, 124B, 124C can provide power to the docked devices.

[0213] Exemplary system 100 can optionally include a dongle 133. The dongle 133 can be docked within the device dock 104 shown in FIG. 1, or in other embodiments, can be remote from the device dock 104 and / or the monitoring client 1. The dongle 133 can provide a communication link or protocol for wireless devices that would otherwise not be usable. For example, as new wireless protocols, technologies, standards, and techniques become available over time, the dongle 133 can be used to provide a bridge, router, or repeater between new communication protocols and convert information transmitted in one protocol to another protocol, whereby new protocol devices can communicate with patient care devices 7, 14, 15, 17, 35, 126, 128, 130, device dock 104, communication module 124D, monitoring client dock 102, monitoring client 1, hub 802 of FIG. 8, and / or other devices. The dongle 133 can retransmit data received from a new communication link using, for example, a wireless protocol, technology, standard, or technique used by any one or more of patient care devices 7, 14, 15, 17, 35, 126, 128, 130, device dock 104, communication module 124D, monitoring client dock 102, monitoring client 1, hub 802 of FIG. 8, and / or other devices in a format known to or used by each other, such as the monitoring server 3 or the monitoring client 1. The dongle 133 can also provide a communication bridge to a mobile-based communication link, such as an EVDO or CDMA-based mobile system.

[0214] In some embodiments, the dongle 133 can communicate patient care parameters, such as patient treatment parameters or patient condition parameters, from one or more patient care devices and retransmit them to the monitoring client 1, the hub 802 of FIG. 8, and / or the monitoring server 3, and vice versa. Optionally, in some embodiments, the dongle 133 can include a wired attachment connector, such as an RS-232 connector, and can be connectable to a legacy device to provide communication from the legacy device to one or more other patient care devices, the monitoring client 1, the hub 802 of FIG. 8, and / or the monitoring server 3. The legacy device can be, for example, a legacy patient care device, a legacy computing device, or other devices using a legacy wired communication protocol.

[0215] Optionally, the system 100 can also include a wearable system monitor 131 for monitoring the operation of various devices, docks, monitoring clients, and / or servers. The wearable system monitor 131 can be programmed, interacted with, and / or paired with using the monitoring client 1, the remote communicator 11, and / or the hub 802 of FIG. 8. The wearable system monitor 131 can be worn by the patient 2 or a provider, and multiple wearable system monitors 131 can be used. The wearable system monitor 131 can interrogate various devices to ensure proper operation. For example, in an exemplary embodiment, the wearable system monitor 131 communicates with the patient care devices 14, 15, 16, 17, 35, 126, 128, 130, the monitoring client 1, the monitoring client dock 102, the device dock 104, and / or the hub 802 of FIG. 8 to determine whether any failures, errors, irregularities, data corruption, communication degradation, incomplete operation, slow operation, or other problems exist.

[0216] Communications from the wearable system monitor 131 can include one or more interrogation signals to determine whether the device receiving the interrogation is functioning properly, is functioning within predetermined operating parameters, and / or is otherwise in a desired state or situation. The system monitor 131 can communicate a detected state or fault to one or more devices such as the monitoring server 3, the monitoring client 1, or the hub 802 of FIG. 8 to alert the provider, initiate a shutdown procedure, and / or initiate other appropriate remedial actions directed to a device not operating properly. For example, the system monitor 131 uses a transceiver of the communication module 124J that communicates with other devices configured with the monitoring server 3, other monitoring clients 4, the communication module 124, or the remote communicator 11 via the monitoring client 1, the network, and / or a WiFi router coupled to the Internet to signal an alert and / or alarm due to an abnormal interrogation response or no interrogation response. The alert and / or alarm can cause the device to audibly sound or visibly display the alert and / or alarm. In some embodiments of the present disclosure, the system monitor 131 includes a call button (not explicitly shown) to enable the patient 2 to request to the care provider. For example, to visibly and / or audibly indicate the request to the user owning the device, the request is routed to the monitoring client 1 or the remote communicator 11.

[0217] The system monitor 131 can implement its functions in various ways, including, for example, (1) predicting a response to an interrogation within a predetermined time, (2) incrementing a counter within the device receiving the interrogation and requesting the value of the counter from the device after incrementing, (3) challenge-response interrogations, and / or (4) other system monitoring techniques or methods.

[0218] As described previously, in some embodiments, the system monitor 131 predicts a response to an inquiry within a predetermined time after querying a patient care device paired with the system monitor 131. For example, the system monitor 131 can send a text string message of "system monitor inquiry" to the infusion pump 7. In this embodiment, the infusion pump 7 receives a message labeled with "system monitor inquiry" from the system monitor 131 and processes the message using one or more of its processors. When the infusion pump 7 processes the message, the software routine therein executes code to send a response message back to the system monitor 131. For example, the response message may be a text string message of "system monitor response" sent to the system monitor 131. In this embodiment, the system monitor 131 can predict that it will receive a response message within a predetermined time such as 2 seconds, and if the system monitor 131 does not receive a response message within 2 seconds, the system monitor 131 warns other devices and / or sends an alert (e.g., the system monitor 131 can broadcast an alert or error message, or cause an alarm or alert to be provided to the processor audibly or visually via the remote communicator 11).

[0219] As described above, in some embodiments, the system monitor 131 increments a counter within the device that has received the query and, after the increment, requests the value of the counter from the device. For example, the system monitor 131 can send a request to a patient care device, such as an infusion pump 7, by sending a message, such as "increment counter," to the device. The device's processor receives the "increment counter" message, reads the value from a memory location in the device, increments the value found at the memory location, and stores the new value in the same memory location by overwriting the previous value. Thereafter, in this example, the processor reads the new value from the memory location and transmits the new value to the system monitor 131, e.g., via a transceiver on the device that received the query. In this embodiment, the system monitor 131 predicts a specific value from the device that has received the query (this predicted value can be stored, for example, in the memory of the system monitor, such as within a table). For example, the system monitor 131 can store 48 values previously received from the device in its memory and predict that it will receive the 49th value from the device after requesting that the value be updated within the device that received the query.

[0220] Also, as described previously, challenge - response queries can be used by the system monitor 131. For example, the system monitor 131 can send an encrypted message to the patient care device. The patient care device is then tasked, for example, to decrypt the message using an encryption key and resend the message to the system monitor 131. The system monitor 131 can predict an unencrypted message to return within a predetermined time. In this embodiment, if the system monitor 131 does not receive a response message within the predetermined time, the system monitor 131 warns other devices and / or sends an alert (for example, the system monitor 131 can broadcast an alert or alarm message and / or communicate these to the monitoring client 1, the monitoring server 3, the hub 802 of FIG. 8, or the remote communicator 11, which then display or audibly indicate the alert or alarm).

[0221] In an embodiment of the present disclosure, the monitoring client 1 has the ability to communicate and directly interact with a healthcare provider using a handheld or portable remote communicator 11 (which may be, for example, a smartphone, a tablet computer, a PDA, a laptop, or other portable computing device). This can be achieved by the wireless 12, thereby enabling communication to be maintained regardless of the location of the patient within the facility or the location of any provider inside or outside the facility. In one aspect, specific information about the patient 2 can be locally stored within the monitoring client 1, whereby the patient's healthcare provider can directly access the information without the need to access the monitoring server 3.

[0222] In some embodiments, optionally, by incorporating appropriate safety and security checks, changes to the settings or flow parameters of the connected infusion pump 7 or patient monitoring devices 14 - 17, 35, 126, 128, 130, 148 can be achieved directly between the provider's monitoring client 11 and the monitoring client 1 (via wired or wireless communication), and the selected changes can also communicate to the monitoring server 3, and thereby optionally to other appropriate locations such as the nurse station 5 and / or pharmacy 6. Further, any new instructions regarding the patient 2 can be entered into the provider's remote communicator 11 (e.g., a smart phone) that gives the instructions and communicated to the monitoring client 1, and then can be notified to a caregiver (e.g., a nurse, nurse practitioner, doctor, physician, or other healthcare professional) via the caregiver's own portable communicator 11. In addition or alternatively, in some embodiments, new instructions can be communicated to the infusion pump 7 or patient monitoring devices 14 - 17, 35, 126, 128, 130, 148, whereby the control system therein or coupled thereto can change its operation, e.g., set points, in response to the new instructions. In some embodiments, any information obtained and stored within the monitoring client 1 is periodically uploaded to the monitoring server 3 and stored in a patient-specific database. Thus, if the patient's monitoring client 1 is out of operation, a new device can be assigned to the patient 2 and the patient's current information from the monitoring server 3 can be quickly added again. Instructions, medications, progress notes, monitoring data, treatment data, patient treatment parameters, patient monitoring parameters, and / or operation parameters from the patient's attached devices can also be uploaded from the monitoring client 1 to the patient's EHR 19, any applicable remote communicator 11, the hub 802 of FIG. 8, and / or the monitoring server 3 for permanent, temporary, or transient storage and / or for analysis to confirm compliance with predetermined criteria such as ranges, thresholds, etc.

[0223] In some embodiments, the monitoring server 3 can comprise a computer that can communicate with and provide some elements of control for some of the monitoring clients 1, 4, 11 within the facility 8. The monitoring server 3 can provide the monitoring clients 1, 4, 11 with data extracted from some databases both inside 8 and outside 9 of the facility. In embodiments of the present disclosure, the monitoring server 3 queries the facility's EHR system 19 about target information regarding the patient 2 and then can add a predetermined set of information (e.g., the patient's age, height, weight, disease category, current medications and medication categories, drug allergies and sensitivities, etc.) to that patient's monitoring client 1. According to such an example, the monitoring server 3 can establish communication links to the EHR 19, laboratory 20, radiology 21, pharmacy 22, and / or other systems (such as cardiology 23 or scheduling database 24, etc.) within the facility, for example, when the monitoring client 1 is assigned to the patient 2. With a unique patient identifier, the monitoring server 3 can receive patient-specific data from these systems and obtain electronic access (permission) to transmit to the systems. A predetermined (selectable) subset of the data can be downloadable into the memory (not explicitly shown in FIG. 1) of the monitoring client 1.

[0224] The information thus obtained can then serve as a key database against which new instructions can be analyzed. Instructions entered into the monitoring client 1 can be checked for compatibility with patient-specific information obtained by the monitoring server 3. Optionally, for safety redundancy, instructions remotely input from communicator 11 can be intercepted and similarly checked by monitoring server 3. Monitoring server 3 can also obtain information from a drug database within pharmacy 22 of the facility or outside 9 to determine whether a new patient instruction might, for example, create an incompatibility with the patient's existing medications. In an embodiment of the present disclosure, monitoring server 3 can download new information regarding the patient's prescribed medications and be programmed to access a publicly available Internet site 25 to determine whether it can communicate a warning or alert to the patient's health care provider(s) 13. Monitoring server 3 can also route information between remote portable communicator 11 and patient monitoring client 1.

[0225] In an embodiment of the present disclosure, a patient's physician, nurse, or pharmacist can have access to the patient's monitoring client 1 to relay or receive new instructions regarding patient 2 (e.g., medication instructions, etc.). The monitoring client 1 or server 3 can then record the new instructions and relay the request to the pharmacist 6 as well as the patient's nurse via the nurse's portable communicator 11 and / or via the fixed terminal of the nurse station 5. A "smartphone" (e.g., specifically, Google's Nexus One phone, Apple's iPhone, or RIM's BlackBerry OS) having a communication application customized on the monitoring client 1 can serve as a convenient portable communicator 11 for providers not in a fixed location (such as an office or a remote nurse station). A tablet PC, netbook, or laptop computer can also serve as a convenient portable communicator 11 for both portable and fixed locations. A PC can serve as a convenient communication device 11 for a fixed or desktop location. When the provider is placed in the patient's room, the provider can input or receive information regarding patient 2 using direct input through the keyboard or touch screen on the monitoring client 1.

[0226] The monitoring client 1 can receive, process, and transmit information regarding a specific patient 2 that has been assigned or designated. The monitoring client 1 can be most conveniently attached or docked to the monitoring client dock 102 so as to communicate with an infusion pump 7 or any other device that can connect or associate with the patient 2. The monitoring client 1 can be, for example, a handheld device approximately the size of a cordless phone or a tablet netbook. It is convenient for it to have a touchscreen interface for use by the patient's provider. It is also possible to provide an output to a larger fixed display located within the patient's room, or at the nurse's station 5 or other convenient location, either through a wired or wireless connection. Each monitoring client 1 can communicate with a central monitoring server 3, through which it can access patient data from the facility's EHR database 19, laboratory database 20, radiology database 21, pharmacy database 22, or other databases of various other facility departments. In some cases, the monitoring client 1 can upload information received from patient monitoring devices 14 - 17 or from provider input to the patient's EHR 19 via the monitoring server 3. The monitoring clients 1, 4 can also receive information from databases outside of the facility through the monitoring server 3 that has an Internet connection 25. Various external databases 9, including various drug information databases and alert networks that handle hazardous drug-related events, are thus accessible.

[0227] The monitoring server 3 can be arranged, for example, to manage various levels of external database information that helps to keep the content of the monitoring client 1 as up-to-date as possible. This can be achieved, for example, by comparing safety and drug information related to patients when available and prioritizing updates / downloads on the data transfer schedule. The monitoring clients 1, 4 can also communicate either directly with the portable communicator 11 used by healthcare providers such as nurses, physicians, and pharmacists, or through the monitoring server 3. In some cases, these devices can have a wired connection to the monitoring server 3 (e.g., when used in a fixed location such as a hospital pharmacy or a nurse's station). In other cases, the portable communicator 11 can communicate with the monitoring server 3 through a secure Internet connection (e.g., a VPN-based Internet connection, UPN, Https, private key mechanism, etc.) using a wired or wireless (e.g., Bluetooth or WiFi 802.11) connection 13 to the computer and device 11. Alternatively, a handheld remote communicator 11 (such as a smartphone or a tablet netbook) can communicate directly 12 with the monitoring client 1 of the facility via a cellular phone network, and / or the facility can include a private cell network that can include a WiFi network (e.g., the unlicensed ISM band from 2.4 GHz to 2.4835 GHz).

[0228] In some embodiments, the communication link between the monitoring clients 1, 4 and the monitoring server 3 exists via an Ethernet network or via wireless transmission using one of several criteria when it is widely available within the facility, enabling all patient-specific monitoring clients 1, 4 to be linked to the central monitoring server 3. The server 3 can then act as a relay for communication with other facility servers 8, web-based servers 25, and the internal and external portable communicators 11 held by the healthcare provider. In some embodiments, the wireless network provides additional functionality that enables communication with the monitoring server 3 regardless of where patient 2 is within the facility.

[0229] One way to cover the entire facility with a wireless range is to obtain a license for a private cellular phone network for the facility. One or more microcellular frequencies can be obtained or leased to provide a local communication network throughout the facility. Such an arrangement maintains communication when the patient and monitoring clients 1, 4 are moved from one location to another within the facility, enabling connection with the monitoring server 3, various in-hospital and out-of-hospital databases 8, 25, and users of fixed stations (e.g., in some embodiments, the nurse station 5 and the pharmacy 6), or with monitoring clients 11 (e.g., a portable smart phone, laptop, or tablet-type device) either inside or outside the hospital. In some embodiments, this type of system provides additional security via an authorized cellular communication infrastructure. Additionally, in some embodiments, the active wireless system can monitor the intensity of use within the area and command additional channel frequencies for that area. However, in some embodiments, the network bandwidth capacity may not enable efficient transmission of large data files, such as those including radiographic images. Such large bandwidth data files can be communicated more efficiently via a wired connection.

[0230] Alternatively or in addition, the hospital can implement an Internet or intranet-based communication system, in which an 802.11 WiFi type protocol is used for wireless communication between individual monitoring clients 1, 4 and the monitoring server 3. To ensure proper signal reception throughout the facility, broadband antennas can be mounted on the roof of the building to collect cellular phone signals from a local phone company. An optical fiber or cable network can then distribute signals throughout the facility. In addition or alternatively, the monitoring server 3 can use the private cellular phone network described above. Such a system can typically provide secure communication and can efficiently communicate large files, such as radiation images stored in the radiation database 21. Home or office-based users can connect to the hospital server, for example, using a VPN or another secure access using wired or optical fiber cables, or through a DSL phone line. Data encryption can be used to provide patient data security. In some applications, it may be advantageous to implement an asymmetric bandwidth communication network to optimize infrastructure capabilities. This embodiment uses an authorized carrier frequency in the "upstream" direction from the monitoring client 1 to the monitoring server 3 and an unlicensed 802.11 WiFi frequency in the "downstream" direction from the monitoring server 3 to the monitoring client 1. In this embodiment, the upstream bandwidth and data speed requirements are relatively small compared to the downstream requirements. For low-priority upstream transmissions, the monitoring client 1 can be enabled to transmit data over a more distributed and cost-effective network, such as a ZigBee network, a Bluetooth network, a mesh network, etc.

[0231] As described previously, communication between various monitoring devices such as patient care devices 14, 15, 16, 17, 35 and the monitoring client 1 can be achieved in a cost-effective manner, for example, using a ZigBee wireless mesh network and / or a Bluetooth network. Exemplary monitoring devices include, in particular, an ECG monitor 14, a blood pressure monitor 15, a pulse oximeter / capnometer 16, a thermometer, and a weighing scale. A common feature of most of these devices is that they perform periodic readings of a single or a few parameters. A hospital internal device communication system such as a wireless mesh network provides low-power digital wireless connectivity between devices and can utilize a widely available license-free frequency band (e.g., 2.4 GHz in some jurisdictions). High-level communication protocols can be utilized to ensure data fidelity and security, for example, TCP, UDP, etc. For example, communication between the monitoring client and the patient care device can be ensured using symmetric encryption keys generated for encryption algorithms such as Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES, IDEA, etc. In addition or alternatively, various data integrity techniques can be used, for example, CRC, odd parity bit check, or even parity bit check.

[0232] A mesh network is highly scalable, allowing many devices to be used on a single self-forming, self-healing mesh network. Devices connected to the network can communicate with each other and act as repeaters to transfer data. Mesh networks are relatively low-cost, scalable, and mobile for monitored patients. In some embodiments, the wireless range for devices linked to a wireless mesh network can reach 70 meters from each node of the system within the facility. A similar network can be used to provide a wireless link within the facility between a portable communicator 11 held by a healthcare provider and its assigned patient through the patient monitoring clients 1, 4.

[0233] Often, the information communicated to the monitoring client 1 can include a single parameter value (e.g., blood pressure, etc.) and a time stamp. The monitoring client 1 can be programmed to determine whether the value is outside a predetermined range, record the value in the patient's EHR 19, and notify the appropriate provider via its monitoring client 11. Further, the network enables two-way communication, and the monitoring client 1 can query the patient monitoring device (e.g., BP monitor 15) and instruct it to perform an unscheduled reading. This can be useful, for example, when an abnormal reading is received and its credibility needs to be verified. The monitoring client 1 can be programmed to request repeated readings to verify the abnormal reading. In another embodiment, the monitoring client 1 can be programmed to interrupt or adjust the flow rate, operating parameters, and / or treatment parameters of the infusion pump 7 based on the reading values received from the monitoring devices 14-17. For example, if the BP monitor 15 indicates a blood pressure below a predetermined acceptable range, the monitoring client 1 can be programmed to instruct the infusion pump 7 to stop the infusion and can communicate an emergency notification 12 to the monitoring client 11 of the (one or more) healthcare providers. In another embodiment, if the infusion pump 7 is capable of determining the amount of fluid delivered to the patient 2 (e.g., the flow rate or cumulative amount of fluid that can be pumped during an interval), the processor in the monitoring client 1 can track the cumulative amount delivered and estimate the amount of fluid remaining in the drug bag 170. (Alternatively, the processor in the monitoring client 1 or the infusion pump 7 can calculate the amount delivered from the infusion rate and the elapsed time of the infusion.) When the estimated remaining amount reaches a predetermined amount, the monitoring client 1 can send a signal to the infusion pump 7 to reduce its flow rate so as not to dry out the patient's intravenous access 35. For example, the monitoring client 1 can determine whether a nurse is scheduled to return to replace the bag at a specific time, warn that the intravenous fluid will run out before the nurse's scheduled return, and / or instead of sending its alarm, the monitoring client 1 can send a signal to the infusion pump 7 to slow down the infusion rate so that the intravenous bag will be empty when the nurse arrives or a predetermined time after the nurse's scheduled return time. Also, a notification recommending replenishment of the intravenous bag 17 can be sent to the nurse's monitoring client 11.

[0234] In some embodiments, the operation of the patient care device progression is indicated by an outer border on the display of the monitoring client 1 to indicate the state and / or progression of the patient care device. For example, the outer border is displayed on the monitoring client 1, and thereby, the proportion of the border that lights up (e.g., when the border is filled, it begins to form a completely filled outer peripheral surface) indicates the progression of the treatment being performed by the patient care device, such as the infusion pump 7. The border can be transmitted from the infusion pump 7 to the monitoring client 1 in an image format (e.g., JPEG, BMP, etc.) and / or as a completed proportion to the monitoring client 1, in which case the monitoring client 1 generates the border.

[0235] In some embodiments, a GPS and / or a ranging module (e.g., an ultrasonic ranging module using time-of-flight estimation) can be installed on the infusion pump 7, the monitoring client 1, the caregiver, and / or the patient. A predetermined setting may be that a predetermined group of the infusion pump 7, the monitoring client 1, the hub 802 of FIG. 8, the caregiver, and / or the patient need to be at a predetermined distance from each other before starting the treatment and / or before configuring one of the infusion pump 7 and / or the monitoring client 1 in this particular embodiment.

[0236] In some embodiments, the patient care devices 7, 170, 126, 128, 130, 14, 15, 16, 17, 124, or 148, the dock 102 or 104, the monitoring client 1, the hub 802 of FIG. 8 can send soft alarms, hard alarms, and / or non-critical alarms to the remote communicator 11 without warning on the device that issues the alarm (e.g., to enable the caregiver to find a solution to remove the cause of the alarm without disturbing the patient) and / or on the monitoring client 1 after a predetermined time has elapsed. If the cause of the alarm is removed before the predetermined time, the device that issues the alarm and / or the monitoring client 1 may not give a warning, thereby preventing additional disturbance to the patient.

[0237] In some embodiments, the AC cable of FIG. 1 includes a clip, whereby an intravenous tube can be clipped thereto.

[0238] In some embodiments, the infusion pump 7 includes status LED lights indicating one or more of having passed a safety check, the pump is flowing, there is an occlusion, and / or the pump is disconnected. The user can use the monitoring client 1 to read the barcode on the intravenous bag 170 (e.g., using camera 144 or camera 136 and / or scanner 120), at which time the LED on the plug can blink to indicate to the user that the tube connected to the intravenous bag 170 should be inserted therein.

[0239] In some embodiments, each item, component, device, patient care device, dock, and computing device, numbered or unnumbered, as shown in FIG. 1 or as described herein, is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, facility service 8 is optional, each of services 19, 20, 21, 22, 23, 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online drug database 9 is optional, drug adverse event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. In addition, or alternatively, in some embodiments, each patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Similarly, system monitor 131, list band 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power are each optional in some embodiments of the present disclosure.

[0240] In addition, in some embodiments, some numbered or unnumbered items, components, devices, patient care devices, docks, and computing devices, as shown in FIG. 1 or as described herein, are shown as the only item, component, device, patient care device, dock or computing device, but multiple items, components, devices, patient care devices, docks and computing devices are contemplated. For example, a single infusion pump 7 is shown in FIG. 1, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any arbitrary number of infusion pumps 7 can be used. In addition, or alternatively, in some embodiments, multiple device docks 104 and / or multiple monitoring client docks 102 can be used.

[0241] In addition to, or as an alternative to, the specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, but other combinations, subsets, numbers, or combinations of specific patient care devices can also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is used, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 are disabled, not present or not available for system use, powered off, or not part of the system 100 of FIG. 1. In addition to, or as an alternative to, in some specific embodiments, only the patient care devices used are dockable to the device dock 104. For example, in this particular embodiment, the infusion pump 7 is the only device docked within the device dock 102, and only the device dock 102 receives one device, such as the infusion pump 7. In addition to, as an alternative to, or optionally, in some specific embodiments, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 are dockable, can operate without docking, and / or are not dockable and can operate as stand-alone patient care devices.

[0242] In some embodiments, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and / or 148, the monitoring client 1, the remote communicator 11, and the dock 102 and / or 104 can include a security data class, for example, via an API.

[0243] Any function described with reference to FIG. 1 can, in some embodiments, be performed by the hub 802 of FIG. 8.

[0244] Figure 2 shows a flowchart diagram of a method 150 for maintaining communication between a monitoring client, such as the monitoring client 1 of FIG. 1, and one or more patient care devices, such as one or more of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIG. 1, according to an embodiment of the present disclosure. The method 150 of this example includes operations 152 to 169. The monitoring client 1 can display an icon indicating when communication is established with a paired and / or designated patient care device. The monitoring client 1 can check to determine if communication with a paired and / or designated patient care device is available at a predetermined interval, and if communication with the paired or designated patient care device is not available for a predetermined period of time, the monitoring client 1 can sound an alarm or alert.

[0245] Operation 152 determines whether a monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock through a dock connector. If the communication link of operation 152 is available, method 150 proceeds to operation 154; otherwise, method 150 proceeds to operation 156.

[0246] Operation 156 determines whether a monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock through a wireless link. If the link of operation 156 is available, method 150 proceeds to operation 154; otherwise, method 150 proceeds to operation 158.

[0247] Operation 154 determines whether the monitoring client dock is available for use as a communication link between the monitoring client dock and the device dock using a cable. If the communication link of operation 154 is available, method 150 proceeds to operation 160; otherwise, method 150 proceeds to operation 158. Operation 160 determines whether the device dock is available for use as a communication link between the device dock and the patient care device, for example, through a wireless or wired communication link. If the communication link of operation 160 is available, method 150 proceeds to operation 166; otherwise, method 150 proceeds to operation 162. Operation 162 determines whether the patient care device is available for use as a communication link between the monitoring client and the patient care device dock through a direct wireless link. If the communication link of operation 162 is available, the method proceeds to operation 166; otherwise, method 150 proceeds to operation 164.

[0248] Operation 158 determines whether the device dock is available for use as a communication link between the monitoring client and the device dock through a wireless link. If the communication link of operation 158 is not available, method 150 proceeds to operation 162; otherwise, method 150 proceeds to operation 160.

[0249] Operation 166 attempts a handshake between the monitoring client and the patient care device using the available communication link. In an alternative embodiment, no handshake is used; for example, not all protocols use a handshake between communication endpoints. Decision operation 168 determines whether the handshake of operation 166 was successful. If decision operation 168 determines that the handshake of operation 166 was not successful, operation 164 determines that communication with the patient care device is not available and / or method 150 attempts to establish communication using another link (not explicitly shown). Otherwise, if decision operation 168 determines that the handshake of operation 166 was successful, operation 169 communicates data using a sufficient number of communication links determined to be available by method 150.

[0250] Method 150 is an exemplary embodiment of the present disclosure that describes a method for maintaining communication between a monitoring client and one or more patient care devices. In some embodiments, method 150 includes a schedule of communication links, although other schedules can be used, and broadcast, unicast, multicast, or unicast can be used, a routing algorithm can be used, a distance vector routing protocol can be used, a link state routing protocol can be used, an optimized link state routing protocol can be used, a path vector protocol can be used, static routing on a predetermined alternative communication path can be used, and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, weights can be assigned to each communication path, and Dijkstra's algorithm can be used to communicate between the monitoring client 1 and one or more patient care devices, and the weights can be determined in any known way, including as a function of bandwidth, signal quality, bit error rate, available data throughput or latency, and / or other factors that may be linear.

[0251] Referring to the drawings, FIG. 3 shows a block diagram of an electronic patient care system 300 having two docks 102, 104 for wireless communication therebetween, according to another embodiment of the present disclosure. System 300 is similar to system 100 of FIG. 1, except that the communication between the monitoring client dock 102 and the device dock 104 is through a wireless link. For example, in some embodiments, system 300 of FIG. 3 is system 100 of FIG. 1 with cable 110 absent or inoperative, and in addition to or alternatively, system 300 of FIG. 3 can have docks 102 and 104 that cannot be connected together using cables.

[0252] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send instructions or requests to the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, for example, to send a bolus amount, infusion flow rate, total delivery fluid, start time of drug delivery, stop time of drug delivery, or delivery flow profile to the infusion pump 7, syringe pump 126, and / or micro-infusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests, such as a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria, to the pill dispenser 128 for dispensing pills. The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval. For example, a particular drug is taken as needed (i.e., when needed), but if taken in excess, the drug may not be safe. The maximum pill dispensing criteria can prevent the drug from being taken in an unsafe level by the patient, for example, in a given amount during a given time interval.

[0253] In some embodiments, the remote communicator 11 can be used to initiate two-way audio / visual communication (e.g., a video call) between the remote communicator 11 and the monitoring client 1. Additionally, or alternatively, the monitoring client 1 can be used to initiate two-way audio / visual communication between the monitoring client 1 and the remote communicator 11 of the monitoring client.

[0254] Optionally, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also determine whether to issue or transmit an alarm or alert, whether a treatment or condition is safe for the patient, whether the system 300 is operating properly or within predetermined bounds, and / or return data to the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11 for display on the displays thereof. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 (if applicable) upstream pressure, change in upstream pressure, downstream pressure with respect to the patient 2, change in downstream pressure with respect to the patient 2, presence or absence of air in the infusion line, actual bolus amount delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile. In another embodiment, the pill dispenser 128 may optionally return data to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 such as, for example, the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether a maximum pill dispensing criterion has been exceeded.

[0255] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to issue an alarm and / or alert. For example, one or more of monitoring clients 1, 4, 11 can use an increase in downstream pressure of infusion pump 7, syringe pump 126, and / or micro-infusion pump 130, which is an indication of excessive clotting, penetration, blockage, or kinking of the tubing to the patient, or blockage by other materials within intravenous bag 170. In response to a rapid increase in downstream pressure, one or more of monitoring clients 1, 4, 11 can visually and / or auditorily warn or alert the user. In addition to, or alternatively, a rapid decrease in downstream pressure to patient 2 is an indication that the tubing has come out of the needle and / or the needle has now come out of the patient, and in response, one or more of monitoring clients 1, 4, 11 can visually and / or auditorily warn or alert the user. Optionally, one or more of monitoring clients 1, 4, 11 can send an instruction to one or more of infusion pump 7, syringe pump 126, and / or micro-infusion pump 130 to stop the delivery of fluid in response to a rapid increase and / or decrease in downstream pressure to patient 2.

[0256] In some embodiments, each numbered or unnumbered item, component, device, patient care device, dock, and computing device, as shown in FIG. 3 or as described herein, is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, facility service 8 is optional, each service 19, 20, 21, 22, 23, 24 is optional, cloud server 25 is optional, each other monitoring client 4 is optional, online drug database 9 is optional, drug adverse event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. In addition or alternatively, in some embodiments, each patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Similarly, system monitor 131, list band 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power are each optional in some embodiments of the present disclosure.

[0257] In addition, in some embodiments, some numbered or unnumbered items, components, devices, patient care devices, docks, and computing devices, as shown in FIG. 3 or as described herein, are shown as the only item, component, device, patient care device, dock or computing device, but multiple items, components, devices, patient care devices, docks and computing devices are contemplated. For example, a single infusion pump 7 is shown in FIG. 3, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any arbitrary number of infusion pumps 7 can be used. In addition or alternatively, in some embodiments, multiple device docks 104 and / or multiple monitoring client docks 102 can be used.

[0258] In addition to, or alternatively, certain patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, but other combinations, subsets, pluralities, or combinations thereof of patient care devices can also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is being used, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 are disabled, not present or available for use in the system, powered off, or not part of the system 300 of FIG. 3. In addition to, or alternatively, in some embodiments, only the patient care devices being used are dockable to the device dock 104. For example, in a particular embodiment, the infusion pump 7 is the only device docked within the device dock 102, and only the device dock 102 receives one device, such as the infusion pump 7. In addition to, alternatively, or optionally, in some particular embodiments, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 are dockable, can operate without docking, and / or are not dockable and can operate as stand-alone patient care devices.

[0259] In FIG. 3, the device dock 104 is shown as being capable of receiving several patient care devices, but in other embodiments, the device dock 104 can receive one patient care device, a plurality of patient care devices, or any arbitrary number of patient care devices. Also, dock compartments may not be used, for example, as shown in FIG. 3, an empty compartment 170 is shown within the device dock 104. In addition, the monitoring client dock 102 is shown as being capable of receiving one monitoring client 1, but in other embodiments, the monitoring client dock 102 can receive two monitoring clients 1, three or more monitoring clients 1, or any arbitrary number of monitoring clients 1.

[0260] Figure 4 shows a flowchart diagram of a method 202 for maintaining communication between a monitoring client, such as monitoring client 1, and one or more of the devices, such as one or more of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIG. 3, according to an embodiment of the present disclosure.

[0261] Operation 204 determines whether a communication link between the monitoring client dock and the monitoring client is available through the dock connector for use as a communication link between the monitoring client and the monitoring client dock. If the communication link of operation 204 is available, method 202 proceeds to operation 206; otherwise, method 202 proceeds to operation 208. Operation 208 determines whether a communication link between the monitoring client dock and the monitoring client is available through a wireless link for use as a communication link between the monitoring client and the monitoring client dock. If the communication link of operation 208 is available, method 202 proceeds to operation 206; otherwise, method 202 proceeds to operation 210.

[0262] Operation 206 determines whether a communication link between the monitoring client dock and the device dock is available through a wireless link for use as a communication link between the monitoring client dock and the device dock. If the communication link of operation 206 is available, method 202 proceeds to operation 212; otherwise, method 202 proceeds to operation 210.

[0263] Operation 210 determines whether a communication link between the device dock and the monitoring client is available through a wireless link for use as a communication link between the device dock and the monitoring client. If the communication link of operation 210 is available, method 202 proceeds to operation 212; otherwise, method 202 proceeds to operation 214.

[0264] Operation 212 determines whether a communication link between the device dock and the patient care device is available for use as a communication link between the device dock and the patient care device. If the communication link of operation 212 is available, method 202 proceeds to operation 216; otherwise, method 202 proceeds to operation 214.

[0265] Operation 214 determines whether the patient care device is available as a communication link between the monitoring client and the patient care device through a direct wireless link. If the communication link of operation 214 is available, method 202 proceeds to operation 216; otherwise, operation 218 determines that communication with the patient care device is not available.

[0266] Operation 216 attempts a handshake between the monitoring client and the patient care device using the available communication link(s). In an alternative embodiment, the handshake is not attempted; for example, some communication protocols do not use a handshake. Decision operation 220 determines whether the handshake was successful and whether communication between the monitoring client and the device was established. If decision operation 220 determines that the communication link was established, method 202 communicates data between the monitoring client and the device during operation 222 using the available communication link(s). If decision operation 220 determines that the handshake was not successful, method 202 determines that communication with the device is not available in operation 218, or method 202 attempts communication between the monitoring clients through an unvalidated communication link (not explicitly shown).

[0267] Method 202 is an exemplary embodiment of the present disclosure that describes a method for maintaining communication between a monitoring client and one or more patient care devices. In some embodiments, method 202 includes a schedule for the communication link, although other schedules can be used, and broadcast, unicast, multicast, or anycast can be used, and routing algorithms can be used, and distance vector routing protocols can be used, and link state routing protocols can be used, and optimized link state routing protocols can be used, and path vector protocols can be used, and static routing on a predetermined alternative communication path can be used, and / or adaptive networks can be used. For example, in some embodiments of the present disclosure, weights can be assigned to each communication path, and Dijkstra's algorithm can be used to communicate between monitoring client 1 and one or more patient care devices, and weights can be determined in any known way, including as a function of bandwidth, signal quality, bit error rate, available data throughput or latency, and / or other factors that may be linear with respect to each other.

[0268] Referring now to FIG. 5, there is shown an electronic patient care system 500 in the form of a block diagram having a dock 502, a communication module 124D, and a dongle 133 for docking a monitoring client 1 and various patient care devices (e.g., patient care devices 7, 126, 128, or 130) together, according to yet another embodiment of the present disclosure. The electronic patient care system 500 of FIG. 5 is similar to the electronic patient care system 100 of FIG. 1, except that each of the monitoring client 1, patient care devices 7, 126, 128, 130, communication module 124D, and dongle 133 are all dockable to the dock 502. As will be appreciated in view of the present disclosure, the dock 502 can include one or more buses, backplanes, communication paths, electronic circuits, etc. to facilitate communication.

[0269] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send instructions or requests to the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, for example, to send a bolus amount, infusion flow rate, total delivery fluid, start time of drug delivery, stop time of drug delivery, or delivery flow profile to the infusion pump 7, syringe pump 126, and / or microinfusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests, such as a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria, to the pill dispenser 128 for dispensing pills. The maximum pill dispensing criteria is the maximum amount of a drug that can be delivered within a given time interval. For example, a particular drug is taken as needed (i.e., when needed), but if taken in excess, the drug may not be safe. The maximum pill dispensing criteria can prevent the drug from being taken at an unsafe level by the patient, for example, in a given amount over a given time interval.

[0270] Optionally, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 500 is operating properly or within a predetermined boundary, and / or return data to the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11 for display on the displays of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 (where applicable) upstream pressure, change in upstream pressure, downstream pressure with respect to patient 2, change in downstream pressure with respect to patient 2, presence or absence of air in the infusion line, actual bolus amount delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile. In another embodiment, the pill dispenser 128 may optionally return data to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11, such as, for example, the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether a maximum pill dispensing criterion has been exceeded.

[0271] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to issue an alarm and / or alert. For example, one or more of monitoring clients 1, 4, 11 can use an increase in downstream pressure of infusion pump 7, syringe pump 126, and / or micro-infusion pump 130, which is an indication of excessive clotting, infiltration, occlusion, or kinking of tubing to the patient, or occlusion by other materials within intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of monitoring clients 1, 4, 11 can warn or alert the user visually and / or audibly. In addition to, or as an alternative to, a sudden decrease in downstream pressure for patient 2 is an indication that the tubing has come out of the needle and / or the needle has now come out of the patient, and in response, one or more of monitoring clients 1, 4, 11 can warn or alert the user visually and / or audibly. Optionally, one or more of monitoring clients 1, 4, 11 can send an instruction to one or more of infusion pump 7, syringe pump 126, and / or micro-infusion pump 130 to stop the delivery of fluid in response to a sudden increase and / or decrease in downstream pressure for patient 2.

[0272] In some embodiments, each item, component, device, patient care device, dock, and computing device, numbered or unnumbered, as shown in FIG. 5 or as described herein, is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, facility service 8 is optional, each of services 19, 20, 21, 22, 23, 24 is optional, cloud server 25 is optional, other monitoring clients 4 are each optional, online drug database 9 is optional, drug adverse event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. In addition or alternatively, in some embodiments, each patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Similarly, system monitor 131, list band 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power are each optional in some embodiments of the present disclosure.

[0273] In addition, in some embodiments, some numbered or unnumbered items, components, devices, patient care devices, docks, and computing devices, as shown in FIG. 5 or as described herein, are shown as the only item, component, device, patient care device, dock or computing device, but multiple items, components, devices, patient care devices, docks and computing devices are contemplated. For example, a single infusion pump 7 is shown in FIG. 5, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any arbitrary number of infusion pumps 7 can be used. In addition or alternatively, in some embodiments, multiple docks 502 can be used.

[0274] In addition to, or alternatively to, the specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, but other combinations, subsets, numbers, or combinations of specific patient care devices can also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is used, and in this specific example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 are disabled, not present or available for use in the system, powered off, or not part of the system 500 of FIG. 5. In addition to, or alternatively to, in some specific embodiments, only the patient care devices used are dockable to the dock 502. For example, in a particular embodiment, the infusion pump 7 is the only device docked within the device dock 102, and only the device dock 102 receives one device, such as the infusion pump 7. In addition to, alternatively, or optionally, in some specific embodiments, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be docked, can operate without docking, and / or can operate as stand-alone patient care devices without being dockable.

[0275] In FIG. 5, the dock 502 is shown as being capable of receiving several patient care devices, but in other embodiments, the dock 502 can receive one patient care device, multiple patient care devices, or any arbitrary number of patient care devices. Also, dock compartments may not be used, for example, as shown in FIG. 5, an empty compartment 170 is shown within the dock 502. In addition, the dock 502 is shown as being capable of receiving one monitoring client 1, but in other embodiments, the dock 502 can receive two monitoring clients 1, three or more monitoring clients 1, or any arbitrary number of monitoring clients 1.

[0276] FIG. 6 is a flowchart diagram showing a method 304 for maintaining communication between a monitoring client, such as the monitoring client 1 of FIG. 5, and one or more patient care devices, such as one or more of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, according to an embodiment of the present disclosure.

[0277] The method determines whether a dock is available as a communication link between the monitoring client and the dock through a dock connector during operation 306. If the communication link of operation 306 is not available, method 304 proceeds to operation 308; otherwise, method 304 proceeds to operation 310. Operation 310 determines whether the dock is available as a communication link between the dock and the patient care device. If the communication link of operation 310 is not available, method 304 proceeds to operation 312; otherwise, method 304 proceeds to operation 314.

[0278] Operation 308 determines whether the dock is available as a communication link between the monitoring client and the dock through a wireless link. If the communication link of operation 308 is not available, method 304 proceeds to operation 310; otherwise, method 304 proceeds to operation 312.

[0279] Operation 312 determines whether the patient care device is available as a communication link between the monitoring client and the patient care device through a direct wireless link. If the communication link of operation 312 is not available, operation 316 determines that communication between the monitoring client and the patient care device is not available.

[0280] Operation 314 attempts a handshake between the monitoring client and the device using the available communication link(s). In an alternative embodiment, the handshake is not utilized, for example, some protocols do not use a handshake. Decision operation 318 determines whether the handshake was successful, and if so, method 304 proceeds to operation 320 to communicate data using the available communication link(s). If decision operation 318 determines that the handshake was not successful in operation 314, operation 316 determines that communication with the device is not available. In other embodiments, if decision operation 318 determines that the handshake was not successful in operation 314, method 304 attempts to communicate with the patient care device via an unvalidated communication link (not explicitly shown).

[0281] Method 304 is an exemplary embodiment of the present disclosure that describes a method of maintaining communication between a monitoring client and one or more patient care devices. In some embodiments, method 304 includes a schedule for communication links, although other schedules can be used, broadcast, unicast, multicast, or unicast can be used, routing algorithms can be used, distance vector routing protocols can be used, link state routing protocols can be used, optimized link state routing protocols can be used, path vector protocols can be used, static routing on a given alternative communication path can be used, and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, weights can be assigned to each communication path, and Dijkstra's algorithm can be used to communicate between monitoring client 1 and one or more patient care devices, and the weights can be determined in any known way, including as a function of bandwidth, signal quality, bit error rate, available data throughput or latency, and / or other factors that may be linear.

[0282] Next, referring to FIG. 7, a block diagram of an electronic patient care system 700 is shown having a monitoring client 1 with an integrated dock 702 for docking patient care devices 7, 126, 128, 130 according to yet another embodiment of the present disclosure. Additionally, in some embodiments, communication module 124D, and dongle 133 are all dockable to dock 702. The patient care system 700 of FIG. 7 is similar to the patient care system 100 of FIG. 1, except that the patient care system 700 includes an integrated dock 702. In some embodiments, monitoring client 1 communicates with the patient care device when docked via the dock, but if monitoring client 1 is unable to communicate with a patient care device, such as patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, monitoring client 1 can communicate wirelessly, for example, using antenna 112 of monitoring client 1.

[0283] Optionally, monitoring client 1, other monitoring client 4, and / or remote communicator 11 can be used to send an instruction or request to patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, for example, to send a bolus amount, infusion flow rate, total delivery fluid, start time of drug delivery, stop time of drug delivery, or delivery flow profile to infusion pump 7, syringe pump 126, and / or microinfusion pump 130. In some embodiments, one or more of monitoring clients 1, 4, 11 can be used to send an instruction or request, such as a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria, to pill dispenser 128 for dispensing pills. The maximum pill dispensing criteria is the maximum amount of a drug that can be delivered within a given time interval. For example, a particular drug is taken as needed (i.e., when needed), but if taken in excess, the drug may not be safe. The maximum pill dispensing criteria can prevent the drug from being taken in an unsafe level by the patient, for example, in a given amount over a given time interval.

[0284] Optionally, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 700 is operating properly or within predetermined bounds, and / or return data to the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11 for display on the displays of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate upstream pressure, change in upstream pressure, downstream pressure for patient 2, change in downstream pressure for patient 2, presence or absence of air in the infusion line, actual bolus amount delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile (if applicable) to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 may optionally return data such as, for example, the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criteria has been exceeded to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11.

[0285] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to issue an alarm and / or alert. For example, one or more of monitoring clients 1, 4, 11 can use an increase in downstream pressure of infusion pump 7, syringe pump 126, and / or micro-infusion pump 130, which is an indication of excessive clotting, infiltration, occlusion, or kinking of the tubing to the patient, or occlusion by other materials within intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of monitoring clients 1, 4, 11 can alert or alarm the user visually and / or audibly. In addition, or alternatively, a sudden decrease in downstream pressure to patient 2 is an indication that the tubing has become disconnected from the needle and / or the needle has now become disconnected from the patient, and in response, one or more of monitoring clients 1, 4, 11 can alert or alarm the user visually and / or audibly. Optionally, one or more of monitoring clients 1, 4, 11 can send an instruction to one or more of infusion pump 7, syringe pump 126, and / or micro-infusion pump 130 to stop the delivery of fluid in response to a sudden increase and / or decrease in downstream pressure to patient 2.

[0286] In some embodiments, each item, component, device, patient care device, dock, and computing device, numbered or unnumbered, as shown in FIG. 7 or as described herein, is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, facility service 8 is optional, each service 19, 20, 21, 22, 23, 24 is optional, cloud server 25 is optional, each other monitoring client 4 is optional, online drug database 9 is optional, drug adverse event network is optional, patient's personal EHR19' is optional, and / or treatment outcome database 10 is optional. In addition or alternatively, in some embodiments, each patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Similarly, system monitor 131, list band 118, RFID116, barcode 114, scanner 120, display 134, and / or AC power are each optional in some embodiments of the present disclosure.

[0287] In addition, in some embodiments, some items, components, devices, patient care devices, docks, and computing devices, numbered or unnumbered, as shown in FIG. 7 or as described herein, are shown as the only item, component, device, patient care device, dock or computing device, but multiple items, components, devices, patient care devices, docks and computing devices are contemplated. For example, a single infusion pump 7 is shown in FIG. 7, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any arbitrary number of infusion pumps 7 can be used. In addition or alternatively, in some embodiments, an integrated dock 702 can be used.

[0288] In addition to, or alternatively to, the specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 being shown, other combinations, subsets, multiplicities, or combinations thereof of specific patient care devices can also be used. For example, in some embodiments, only the infusion pump 7 of the patient care devices is being used, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 are disabled, not present or available for use in the system, powered off, or not part of the system 700 of FIG. 7. In addition to, or alternatively to, in some specific embodiments, only the patient care devices being used are dockable in the integrated dock 702. For example, in a particular embodiment, the infusion pump 7 is the only device docked within the integrated dock 702, and the integrated dock 702 only receives one device, such as the infusion pump 7. In addition to, alternatively to, or optionally, in some specific embodiments, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 are dockable, can operate without docking, and / or are not dockable and can operate as stand-alone patient care devices.

[0289] In FIG. 7, the integrated dock 702 is shown as being capable of receiving several patient care devices, but in other embodiments, the integrated dock 702 can receive one patient care device, multiple patient care devices, or any arbitrary number of patient care devices. Also, dock compartments may not be used, for example, as shown in FIG. 7, an empty compartment 170 is shown within the integrated dock 702. In addition, the integrated dock 702 is shown as being capable of receiving one integrated monitoring client 1, but in other embodiments, the integrated dock 702 can receive two integrated monitoring clients 1, three or more integrated monitoring clients 1, or any arbitrary number of integrated monitoring clients 1.

[0290] FIG. 8 is a block diagram of an electronic patient care system 800 having a hub 802, according to yet another embodiment of the present disclosure. Optionally, in some embodiments, the hub 802 provides a communication interface between the monitoring client dock 102 and the device docks 804, 806. In further additional embodiments, the hub 802 controls the patient care devices without the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11. For example, the hub 802 can communicate with the monitoring server 3, the facility service 8, the nurse station 5, the pharmacy 6, the cloud server 25, the online drug database or the drug adverse event network 9, the patient's personal EHR 19', and / or the treatment outcome database 10. The hub 802 can provide a clock such that all devices connected thereto (e.g., patient care devices, monitoring clients, remote communicators, etc.) use the hub 802's clock, real-time devices use the hub 802's clock, or time-critical devices use the hub 802's clock.

[0291] In some embodiments, a GPS and / or a ranging module (e.g., an ultrasonic ranging module) can be installed on the infusion pump 830, the monitoring client 1, the hub 802, the caregiver, and / or the patient. A predetermined setting may require that a particular group of the infusion pump 830, the monitoring client 1, the hub 802, the caregiver, and / or the patient be at a predetermined distance from each other before starting treatment and / or before configuring one of the infusion pump 830, the hub 802, and / or the monitoring client 1 in this particular embodiment.

[0292] In some embodiments, the hub 802 includes an application programming interface (API) to display a GUI, window, data, etc. on the monitoring client 1 and / or the remote communicator 11. The API can include secure data classes. In further additional embodiments, the docks 102, 804, and / or 806 include an API to display a GUI, window, data, etc. on the monitoring client 1 or the remote communicator 11. In still further additional embodiments, the dock 102, 804, or 806, or the hub 802 includes an API to display a GUI, window, data, etc. on the patient care devices 830, 810, and / or 814.

[0293] In some embodiments, the hub 802 and / or the docks 102, 804, and / or 806 can identify the type of the patient care device associated therewith (the device paired thereto, the device plugged into or docked to the hub 802 and / or the docks 102, 804, and / or 806) and load configuration data based on the type of the patient care device associated therewith.

[0294] In some embodiments, the hub 802 and / or the docks 102, 804, and / or 806 can identify the type of the patient care device associated therewith and configure the UI using, for example, html, CSS, JavaScript (registered trademark), etc. In some embodiments, the hub 802 and / or the docks 102, 804, and / or 806 can have a distributed UI system.

[0295] The user interfaces described herein can utilize a request operation framework.

[0296] Optionally, in some particular embodiments, hub 802 includes all of the safety-critical circuitry and software for communicating with monitoring client 1. For example, in this particular embodiment, hub 802 receives treatment parameters from monitoring client 1, and hub 802 ensures that the treatment parameters are safe for patient 2, for example, separate from any safety checks performed anywhere on monitoring client 1. In further additional particular embodiments, system 800 is optionally fully fault-tolerant of monitoring client 1, and for example, may ignore instructions, requests, or parameters from monitoring client 1 if the independent safety checks performed therein do not meet a predetermined criterion, such as a predetermined safe range of drug delivery of infusion pump 7.

[0297] Optionally, in further additional particular embodiments, a barcode attached to intravenous bag 170 can be scanned by scanner 120, download a predetermined prescription (e.g., from the patient's personal EHR19'), and / or include a predetermined prescription that is uploaded to hub 802 when infusion pump 830 is docked to dock 804. Thereafter, in this particular embodiment and also optionally, hub 802 initiates the infusion of intravenous bag 170 into patient 2 and monitors the progress of the treatment to ensure the safety of patient 2. In addition, alternatively or optionally, in this particular embodiment, the caregiver can interact with system 800 as shown in FIG. 8 only through hub 802. Optionally, in some embodiments, hub 802 uploads treatment, status, or patient information to monitoring client 1. For example, hub 802 can upload to monitoring client 1 treatment information received from infusion pump 830, or treatment information received from the patient's personal EHR19' corresponding to the scanned barcode on intravenous bag 170, for display to the user, for storage within monitoring client 1 for confirmation of information by the user, etc.

[0298] In some embodiments, the device dock 804 receives infusion pumps 830, 810, and 812. In some embodiments, the device dock 804 receives one, two or more, or a plurality of patient care devices. The device dock 806 receives the pill dispenser 814. In some embodiments, the device dock 806 receives one, two or more, or a plurality of patient care devices such as the pill dispenser 806. The device dock 804 includes an antenna 816 for wireless communication, and the device dock 806 includes an antenna 818 for wireless communication. Similarly, the hub 802 includes an antenna 820 for wireless communication. In addition or alternatively, the device dock 804, the hub 802, and / or the monitoring client 1 communicate with each other using a wired connection. The hub 802, and the docks 804 and 806 can communicate with each other, for example, using a USB cable, using an Ethernet cable, and / or via a wireless link. Optionally, the hub 802 can include additional accessories such as a display 822, a camera 824, a microphone 826, a scanner 120, a removable display (not shown). As described previously, the hub 802 can provide all patient safety critical functions and can operate independently of the monitoring client 1 and / or the monitoring client dock 102.

[0299] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send instructions or requests to the patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148, for example, to send a bolus amount, infusion flow rate, total delivery fluid, start time of drug delivery, stop time of drug delivery, or delivery flow profile to one or more of the infusion pumps 830, 810, 812. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests to the pill dispenser 814, such as, for example, a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria, for dispensing pills. The maximum pill dispensing criteria is the maximum amount of a drug that can be delivered within a given time interval. For example, a particular drug is taken as needed (i.e., when needed), but the drug may not be safe if taken in excess. The maximum pill dispensing criteria can prevent the drug from being taken in an unsafe level by the patient, for example, in a given amount during a given time interval.

[0300] Optionally, the patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148 may also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 800 is operating properly or within predetermined bounds, and / or return data to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 for display on the displays thereof. For example, optionally, one or more of the infusion pumps 830, 810, 812 may communicate to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 (where applicable) upstream pressure, change in upstream pressure, downstream pressure with respect to patient 2, change in downstream pressure with respect to patient 2, presence or absence of air in the infusion line, actual bolus amount delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile. In another embodiment, the pill dispenser 814 may optionally return data such as, for example, the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether a maximum pill dispensing criterion has been exceeded, to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11.

[0301] Data received from patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148 can be analyzed for any given condition to issue an alarm and / or alert. For example, one or more of monitoring clients 1, 4, 11 can use an increase in downstream pressure of one or more of infusion pumps 830, 810, 812, which is an indication of excessive clotting, infiltration, occlusion, or kinking of the tubing to the patient, or occlusion by other materials within intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of monitoring clients 1, 4, 11 can warn or alert the user visually or audibly. In addition to, or alternatively, a sudden decrease in downstream pressure for patient 2 is an indication that the tubing has come out of the needle and / or the needle has now come out of the patient, and in response, one or more of monitoring clients 1, 4, 11 can warn or alert the user visually or audibly. Optionally, one or more of monitoring clients 1, 4, 11 can send an instruction to one or more of infusion pumps 830, 810, 812 to stop the delivery of fluid in response to a sudden increase and / or decrease in downstream pressure for patient 2.

[0302] In some embodiments, each item, component, device, patient care device, dock, and computing device, numbered or unnumbered, as shown in FIG. 8 or as described herein, is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, facility service 8 is optional, each service 19, 20, 21, 22, 23, 24 is optional, cloud server 25 is optional, other monitoring clients 4 are each optional, online drug database 9 is optional, drug adverse event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. In addition or alternatively, in some embodiments, each patient care device 830, 810, 812 is optional. Similarly, system monitor 131, list band 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power are each optional in some embodiments of the present disclosure.

[0303] In addition, in some embodiments, some numbered or unnumbered items, components, devices, patient care devices, docks, and computing devices, as shown in FIG. 8 or as described herein, are shown as the only item, component, device, patient care device, dock or computing device, but multiple items, components, devices, patient care devices, docks and computing devices are contemplated. For example, a single pill dispenser 814 is shown in FIG. 8, but in some embodiments, two pill dispensers 814 can be used, multiple pill dispensers 814 can be used, or any arbitrary number of pill dispensers 814 can be used. In addition or alternatively, in some embodiments, multiple docks 804 or 806, and / or multiple monitoring client docks 102 can be used.

[0304] In addition to, or alternatively to, the specific patient care devices 830, 810, 812 shown, other combinations, subsets, pluralities, or combinations thereof of specific patient care devices can also be used. For example, in some embodiments, only the infusion pump 830 of the patient care devices is being used, and in this specific example, the other patient care devices 810, 812, 814 are disabled, not present or available for use in the system, powered off, or not part of the system 800 of FIG. 8. In addition to, or alternatively to, in some specific embodiments, only the patient care devices being used are dockable to the dock 804 or 806. For example, in a specific embodiment, the infusion pump 830 is the only device docked within the dock 804, and only the dock 804 receives one device, for example, the infusion pump 830.

[0305] In FIG. 8, the dock 804 is shown as being capable of receiving several patient care devices, but in other embodiments, the device dock 804 can receive one patient care device, multiple patient care devices, or any arbitrary number of patient care devices. Also, dock compartments may not be used (not shown in FIG. 8). In addition to, the monitoring client dock 102 is shown as being capable of receiving one monitoring client 1, but in other embodiments, the monitoring client dock 102 can receive two monitoring clients 1, three or more monitoring clients 1, or any arbitrary number of monitoring clients 1. In addition to, alternatively, or optionally, in some specific embodiments, the patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814 can be dockable, can operate without docking, and / or can be non - dockable and operate as stand - alone patient care devices.

[0306] System 800 of FIG. 8 can use any known communication method to maintain communication therewith. For example, in some embodiments, any communication schedule can be used, broadcast, unicast, multicast or unicast can be used, routing algorithms can be used, distance vector routing protocols can be used, link state routing protocols can be used, optimized link state routing protocols can be used, path vector protocols can be used, static routing on a predetermined alternative communication path can be used, and / or adaptive networks can be used. For example, in some embodiments of the present disclosure, weights can be assigned to each communication path, and Dijkstra's algorithm can be used to communicate between monitoring client 1 or hub 802 and one or more patient care devices (e.g., patient care devices 830, 810, 812, and 814), and weights can be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, available data throughput or latency, and / or other factors that may be linear thereto.

[0307] In embodiments of the present disclosure, facility service 8 and / or drug adverse event network 9 can also include a drug error reduction system (DERS). The DERS system can include a first set of predetermined criteria for triggering a soft alarm and / or a second set of predetermined criteria for triggering a hard alarm. The soft alarm can be disabled (e.g., stopped) by a caregiver using the user interface of infusion pump 830, the user interface 808 of hub 802, and / or the user interface of monitoring client 1 while the hard alarm does not interrupt treatment until the cause of the hard alarm is removed (also, it may be only an audible and / or vibrating alarm).

[0308] In still further additional embodiments of the present disclosure, the DERS system can include a first set of predetermined criteria that define soft limits, and / or a second set of predetermined criteria that define hard limits. The hard and soft limits define treatment limits, such as drug dosages, based on dimensions, weight, age, other patient parameters, or other criteria. The soft limits can be overridden by a caregiver using the user interface of infusion pump 830, the user interface of monitoring client 1, and / or the user interface 808 of hub 802 to initiate treatment even though the treatment is outside the first set of predetermined criteria, while preventing the treatment from starting until the settings are changed to meet the second set of predetermined criteria that define the hard limits.

[0309] In some embodiments, patient care devices 830, 810, 812, 814, 14, 15, 16, 17, 35 and / or 148, monitoring client 1, remote communicator 11, and dock 102 and / or 804, and / or hub 802 can include secure data classes, for example via an API.

[0310] Referring again to the drawings, FIG. 9 shows a block diagram of an electronic patient care system 900 having a stackable monitoring client 902, a stackable infusion pump 904, a stackable syringe pump 906, and another stackable patient care device 908, according to yet another embodiment of the present disclosure. The stackable devices 902-908 can communicate using a backplane and / or a bus (in some embodiments, the stackable devices 902-908 communicate via a communication module).

[0311] Optionally, a monitoring client 902, another monitoring client 4, and / or a remote communicator 11 can be used to send an instruction or request to patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148, for example, a bolus amount, an infusion flow rate, a total delivery fluid, a start time of drug delivery, a stop time of drug delivery, or a delivery flow profile, to a stackable infusion pump 904, a stackable syringe pump 906, and / or other stackable patient care devices 908. In some embodiments, one or more of the monitoring clients 902, 4, 11 can be used to send an instruction or request, such as a pill dispensing instruction, a pill type, a pill dispensing schedule, and / or a maximum pill dispensing criterion, to a pill dispenser 128 for dispensing pills. The maximum pill dispensing criterion is the maximum amount of a drug that can be delivered within a given time interval. For example, a particular drug is taken as needed (i.e., when needed), but the drug may not be safe if taken in excess. The maximum pill dispensing criterion can prevent the drug from being taken in an unsafe level by the patient, for example, in a given amount, during a given time interval.

[0312] Optionally, the patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 may also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 900 is operating properly or within predetermined bounds, and / or return data to the monitoring client 902, other monitoring clients 4 and / or the remote communicator 11 for display on the display of the monitoring client 902, other monitoring clients 4 and / or the remote communicator 11. For example, optionally, the stackable infusion pump 904, stackable syringe pump 906, and / or other stackable patient care device 908 may communicate upstream pressure, change in upstream pressure, downstream pressure for patient 2, change in downstream pressure for patient 2, presence or absence of air in the infusion line, actual bolus amount delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile (where applicable) to one or more of the monitoring client 902, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 may optionally return data such as the actual pills dispensed, actual pill type dispensed, actual pill dispensing schedule at the time of dispensing, or whether a maximum pill dispensing criterion has been exceeded to the stackable monitoring client 902, other monitoring clients 4, and / or the remote communicator 11.

[0313] Data received from patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 can be analyzed for any given condition to issue an alarm and / or alert. For example, one or more of monitoring clients 902, 4, 11 can use an increase in downstream pressure of stackable infusion pump 904 and / or stackable syringe pump 906, which is an indication of excessive clotting, infiltration, blockage or kinking of tubing to the patient, or blockage by other materials within intravenous bag 170. In response to a sharp increase in downstream pressure, one or more of monitoring clients 902, 4, 11 can visually and / or audibly warn or alert the user. In addition or alternatively, a sharp decrease in downstream pressure for patient 2 is an indication that the tubing has come out of the needle and / or the needle has now come out of the patient, and in response, one or more of monitoring clients 902, 4, 11 can visually and / or audibly warn or alert the user. Optionally, one or more of monitoring clients 902, 4, 11 can send an instruction to one or more of stackable infusion pump 904 and / or stackable syringe pump 906 to stop fluid delivery in response to a sharp increase and / or decrease in downstream pressure for patient 2.

[0314] Stackable monitoring client 902, stackable device 908, stackable infusion pump 904, and stackable syringe pump 906 can be daisy-chain connected together via connectors coupled to the top and bottom of each device. For example, instead of stackable syringe pump 906, it can be stacked on top of monitoring client 902, such that the bottom connector of stackable syringe pump 906 is electrically coupled to the top connector of monitoring client 902.

[0315] Daisy Chain can be created, for example, through electrical conductors within each of the stackable monitoring client 902, stackable patient care device 908, stackable infusion pump 904, and stackable syringe pump 906, thereby maintaining continuous electrical contact between each of these devices.

[0316] In addition or alternatively, the stackable devices 902, 908, 904, 906 can optionally maintain wireless communication with each other. For example, the stackable monitoring client 902 can detect that the daisy-chain connected conductor is electrically non-responsive due to an internal short circuit within one of the stackable devices 902, 908, 904, 906, and the stackable monitoring client 902 can query each of the stackable devices 908, 904, 906 to determine which device has failed. After making a determination, the stackable monitoring client 902 can wirelessly communicate with an insulated disconnect circuit within the failed device among the stackable devices 902, 908, 904, 906 to electrically disconnect the failed device from the daisy-chain connected conductor. In addition or alternatively, one or more of the stackable devices 902, 908, 904, 906 can send an alert, and / or display a message warning that one of the stackable devices 902, 908, 904, 906 has failed and / or that one of the stackable devices 902, 908, 904, 906 is communicating wirelessly rather than via the daisy-chain connected wired communication link.

[0317] In addition to, or alternatively, the stackable monitoring client 902, the stackable device 908, the stackable infusion pump 904, and the stackable syringe pump 906 can each relay or retransmit information to the respective device below or above it within the daisy chain. For example, the stackable infusion pump 904 can communicate all of the data received from the stackable syringe pump 906 by buffering the data in an internal memory and communicating the information when it receives a signal from the stackable patient care device 908 indicating that the stackable patient care device 908 is ready to receive additional data. In some embodiments, each item, component, device, patient care device, dock, and computing device, numbered or unnumbered, as shown in FIG. 8 or described herein, is optional. For example, in some embodiments, the monitoring client 1 is optional, the monitoring server 3 is optional, the facility service 8 is optional, each service 19, 20, 21, 22, 23, 24 is optional, the cloud server 25 is optional, the other monitoring clients 4 are each optional, the online drug database 9 is optional, the drug adverse event network is optional, the patient's personal EHR 19' is optional, and / or the treatment outcome database 10 is optional. In addition to, or alternatively, in some embodiments, each patient care device 830, 810, 812 is optional. Similarly, the system monitor 131, the list band 118, the RFID 116, the barcode 114, the scanner 120, the display 808, and / or the AC power are each optional in some embodiments of the present disclosure.

[0318] In addition, in some embodiments, several numbered or unnumbered items, components, devices, patient care devices, and computing devices, such as those shown in FIG. 9 or as described herein, are shown as a single item, component, device, patient care device, or computing device, but a number of items, components, devices, patient care devices, and computing devices are contemplated. For example, a single pill dispenser 128 is shown in FIG. 9, but in some embodiments, two pill dispensers 128 can be used, a number of pill dispensers 128 can be used, or any arbitrary number of pill dispensers 128 can be used.

[0319] In addition or alternatively, specific patient care devices 904, 906, 908 are shown, but other combinations, subsets, numbers, or combinations of specific patient care devices can also be used. For example, in some embodiments, only the stackable infusion pump 904 among the patient care devices is used, and in this particular example, the other patient devices 906, 908 may be disabled, not present or available for system use, powered off, or not part of the system 900 of FIG. 9. In addition or alternatively, in some specific embodiments, only the patient care devices used are stacked. For example, in a particular embodiment, the infusion pump 904 is the only device stacked. In addition or alternatively, patient care devices that are not stacked, such as patient care devices 904, 906, and / or 908, can continue to operate when operating as stand-alone devices. In addition, alternatively, or optionally, in some specific embodiments, patient care devices 14, 15, 16, 17, 35, 904, 906, 908, 128, 148 can be dockable, can operate without docking, and / or are not dockable and can operate as stand-alone patient care devices.

[0320] In FIG. 9, the stack is shown to be capable of stacking several patient care devices, but in other embodiments, the stack can receive one patient care device, a plurality of patient care devices, or any arbitrary number of patient care devices. In addition, the stack is shown to be capable of receiving one monitoring client 902, but in other embodiments, two stackable monitoring clients 902, three or more stackable monitoring clients 902, or any arbitrary number of stackable monitoring clients 902 can be stacked within the system 900.

[0321] The system 900 of FIG. 9 can use any known communication method to maintain communication therewith. For example, in some embodiments, any communication schedule can be used, broadcast, anycast, multicast or unicast can be used, routing algorithms can be used, distance vector routing protocols can be used, link state routing protocols can be used, optimized link state routing protocols can be used, path vector protocols can be used, static routing on a given alternative communication path can be used, and / or adaptive networks can be used. For example, in some embodiments of the present disclosure, weights can be assigned to each communication path, and Dijkstra's algorithm can be used to communicate between the monitoring client 902 and one or more patient care devices (e.g., patient care devices 904, 906, 908), and the weights can be determined in any known way, including as a function of bandwidth, signal quality, bit error rate, available data throughput or latency, and / or other factors that may be linear with respect thereto.

[0322] Referring to FIGS. 1, 3, 5, 7, 8 and 9, various update technologies and / or techniques can be utilized to update hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices. For example, in some embodiments, a patient care device can be coupled to a computing device (in some embodiments, a personal computer, or any device that can be used in a manner similar to a personal computer, such as, but not limited to, a tablet) by a bus converter that converts, for example, RS232 format data to I2C format data. In some embodiments, a processor in a hub, dock, device, insulin pump, infusion pump, and / or patient care device can execute an update program to control or organize, for example, the downloading of software into flash memory by a supervisor processor and / or a command processor. In some embodiments, the computing device can organize the downloading of software into the flash memory of a hub, dock, device, insulin pump, infusion pump, and / or patient care device. The software update obtained by the computing device can be sent into a flash memory (not shown) accessible by a supervisor processor and / or a command processor. In some embodiments, the software update can be a command line program that can be automatically invoked by a script process.

[0323] In some embodiments, a hub, dock, device, insulin pump, infusion pump, and / or patient care device may be or may have the ability of a web-connected remote interface that can include, but is not limited to, the ability to download applications, download software updates, upload information, and / or transmit information to various machines through, but not limited to, a web-based secure portal, and / or through email, and / or via a wireless communication protocol. Thus, in various embodiments, the remote interface application can run on any functional device and is not limited to so-called dedicated devices. Further, in some embodiments, the remote interface can communicate with one or more devices that can include, but are not limited to, one or more of a hub, dock, device, insulin pump, infusion pump, patient care device, Bluetooth or other communication device, patient care device, and / or any other device, for example, using radio frequency (RF) communication, which can be enabled by Bluetooth or can be enabled in other ways.

[0324] In some embodiments, the charging station can include a charging area for hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices for a remote interface that can include a USB plug. In some embodiments, the charging station can include a USB port, in some embodiments, a mini-USB port, and in some embodiments, enable a charging station for receiving power to charge hubs, docks, devices, insulin pumps, infusion pumps, patient care devices, and / or the remote interface through USB. In addition and / or alternatively, the USB port can be configured for data transfer to / from the remote interface and / or hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices by connection to a computer or other device and / or a computer-type device. In embodiments including a USB port, while the remote interface is being charged, the system can call a personal computer and / or a web portal to check for updated software and, if available, download software updates, for example, via the USB connection. These updates can then be transferred to the hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices during pairing.

[0325] Accordingly, the user can connect the remote interface of the hub, dock, device, insulin pump, infusion pump, and / or patient care device to a personal computer, and / or, in some embodiments, upload data from the remote interface to, for example, a web portal. In some embodiments, this can be accomplished during “recharging” of the remote interface using a USB connection to the personal computer that can, in addition to charging / recharging the remote interface, synchronize data from the personal computer, 1908 and / or the web portal, and / or upload / download it. At this time, the system can determine whether software updates are available for one or more of the devices and / or for the remote interface. The user can select “update download,” and these can also be downloaded to the remote interface of the hub, dock, device, insulin pump, infusion pump, and / or patient care device when charging and / or whenever the remote interface is connected, either directly or indirectly, to the personal computer and / or, in particular, the web portal designated for the system. As discussed above, the remote interface can communicate with various devices. Accordingly, software updates can be communicated to any one or more of the devices of the remote interface. This includes, but is not limited to, many advantages such as simply connecting the remote interface to the personal computer / web portal for both uploading data / information from all of the devices and / or downloading updates and / or applications to any of the devices from the personal computer and / or from the Internet / web portal. This may be desirable for many reasons, including, but not limited to, the ability to efficiently and easily update all devices from one connection, and / or the ability to view all of the data from all devices in one location, and / or the ability to download information and / or settings from a personal computer / web portal to any of the devices via a remote interface.

[0326] Accordingly, in some embodiments, because the personal computer / web portal includes all of the information from all devices, including, but not limited to, the remote interface, a new "remote interface" can be introduced into the system at any time. This can be accomplished by connecting the new remote interface to the personal computer / web portal and downloading all of the information regarding the system to the remote interface. In some embodiments, this may first require removing the old remote interface from the "authenticating device", but in other embodiments, the system can "permit" an additional remote interface with the permission of the user. Accordingly, the system includes the ability to download all information and applications to any Internet connection and / or remote interface that is capable of communicating with the devices and / or of connecting to the personal computer and / or web portal.

[0327] In addition, this enables a remote interface to download any application from the Internet to any device within the system. Accordingly, in various embodiments of the system, a user can change any device (including some parameters such as the ability to wirelessly communicate with and connect to a personal computer and / or a web portal) into a device that can control various devices, such as an infusion pump, and / or receive data from and / or control a CGM sensor / transceiver, and / or other analyte sensors, and / or other devices such as a hub, dock, device, insulin pump, infusion pump, and / or patient care device. In some embodiments, the remote interface and / or one or more applications on the remote interface can be protected by a password or otherwise and are paired with one or more devices, such as an infusion pump and / or a CGM sensor and / or one or more other devices.

[0328] In some embodiments, including but not limited to, information on the remote interface, including uploading data to an Internet site (web portal) that can be password protected, can be uploaded and / or synchronized with another device and / or computer and / or machine. Accordingly, a user can access information from any device and / or download information to any device including any device-specific application, and thus, including but not limited to, download user information, including information such as history, preferred settings, etc., to any device.

[0329] FIG. 10 is a flowchart diagram of a method 600 for communicating patient care parameters of a patient care device to a monitoring server, according to an embodiment of the present disclosure. Method 600 includes operations 602-608. The patient care device of method 600 may optionally be any patient care device disclosed herein, for example, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or other patient care devices disclosed herein.

[0330] Operation 602 establishes a communication link between the patient care device and the monitoring server. Operation 604 communicates the patient care parameters to the monitoring server, for example, over a local area network and / or the Internet, through WiFi, through a monitoring client, one or more hubs, or a dock. Operation 606 de-identifies the patient care parameters. Operation 606 can be performed automatically and electronically, for example, within the monitoring server of FIGS. 1, 3, 5, 7, 8, and / or 9. For example, the patient's name can be removed and replaced with a random serial number or other identifier that cannot be used to determine the patient's identification information within the monitoring server. Operation 608 stores the de-identified patient care parameters within a database, for example, within the monitoring server such as an SQL database, a relational database, an associative database, a cloud server, etc.

[0331] FIG. 11 is a flowchart diagram of a method 701 for collecting patient care parameters from a number of patients as determined by a patient care device within a monitoring server, according to an embodiment of the present disclosure. Method 701 includes operations 703-713. In some embodiments, operations 703-713 are all optional. The patient care device may be any patient care device disclosed herein, such as the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or other patient care devices disclosed herein.

[0332] Operation 703 establishes a communication link between a monitoring server, such as the monitoring server 3 of FIGS. 1, 3, 5, 7, 8, or 9, and a plurality of patient care devices associated with a plurality of patients. Optionally, a number of patient care devices can be associated with a single patient and / or a number of patient care devices can be associated with different respective patients.

[0333] Operation 705 communicates a plurality of patient care parameters from the plurality of patient care devices to the monitoring server. Operation 707 anonymizes the patient care parameters, and operation 709 stores these patient care parameters within a database within the monitoring server, such as an SQL database, a relational database, an associative database, etc. Operation 707 can be performed automatically and / or electronically. Operation 711 treats a subset of the patients among the plurality of patients. For example, patients with high blood pressure can be treated with a drug designated to lower blood pressure. Operation 713 analyzes a subset of the plurality of patient care parameters associated with the plurality of patients to determine the effectiveness of the treatment. For example, all patients who received the blood pressure drug of operation 711 can have their blood pressure compared to a blood pressure reading after a predetermined time, such as 6 months, to determine if the treatment was effective for one or more of the patients.

[0334] FIG. 12 is a flowchart diagram of a method 801 for recovery of a patient care device when the operation of the patient care device is interrupted, according to an embodiment of the present disclosure. For example, the patient care device may be unplugged from the dock, the power may be cut off, or a hardware or software failure may temporarily disable one or more processors or other circuitry within the patient care device. In addition or alternatively, one or more processors on the patient care device may implement method 801 such that the patient care device is hot swappable.

[0335] Method 801 includes operations 803-823. Each of operations 803-823 is optional in some embodiments. Operation 803 receives one or more patient care parameters associated with the patient care device. The patient care device of method 801 may be any patient care device disclosed herein, for example, one or more of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, or the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9.

[0336] Operation 805 stores one or more patient care parameters in the non-volatile memory of the patient care device. The patient care parameters may be any values associated with patient care, including patient treatment parameters or patient status parameters. For example, the infusion rate for an infusion pump is a patient treatment parameter.

[0337] Operation 807 receives one or more operation parameters for the patient care device. The operation parameters may be anything related to the operation of the device. For example, the operation parameters may be a speed limit for the motor of an infusion pump, an infusion pump speed, a watt limit on wireless communication, a battery discharge rate or speed limit, an update frequency, etc. Operation 809 stores one or more operation parameters in the non-volatile memory of the patient care device.

[0338] Operation 811 calculates one or more additional operation parameters for the patient care device. The calculated operation parameters are any parameters calculated to operate the patient care device, such as the gain coefficients of a proportional-integral-derivative (PID) control loop having an adaptive gain coefficient used in automatic gain control. Operation 813 stores one or more additional operation parameters in the non-volatile memory of the patient care device.

[0339] Operation 815 determines that the operation of the patient care device has been interrupted, such as power loss to the patient care device, a malfunction in the patient care device, or a voltage drop CPU reset. Operation 817 determines that the operation of the patient care device can be resumed.

[0340] Operation 819 loads one or more received or calculated operation parameters into the operating memory of the patient care device, and operation 821 loads one or more patient care parameters into the operating memory of the patient care device. Operation 823 resumes the operation of the patient care device.

[0341] Next, referring to FIG. 13, a flowchart diagram of a method 900 for pairing a monitoring client having a user interface to a patient care device according to an embodiment of the present disclosure is shown. Method 900 includes operations 902-912. The monitoring client of method 900 may be the monitoring client 1 or the remote communicator 11 of FIGS. 1, 3, 5, 7, or 8, the monitoring client 902 of FIG. 9, the remote communicator 11 of FIGS. 1, 3, 5, 7, 8, or 9, a mobile phone, a handheld computer, a tablet computer, a laptop computer, a personal computer, a personal digital assistant, or the like. Method 900 describes pairing between a monitoring client and a patient care device. In some embodiments, however, Method 900 is used to pair a hub (e.g., hub 802 of FIG. 8) to a patient care device (e.g., patient care devices 830, 810, 812, and 814), pair a first patient care device (e.g., patient care device 830 of FIG. 8) to a second patient care device (e.g., patient care device 814 of FIG. 8), such that the user interface of the first patient care device can be used to control the second patient care device, and / or pair a system monitor (e.g., system monitoring 131 of FIGS. 1, 3, 5, 7, 8, or 9) to a patient care device (e.g., patient care devices 7, 170, 126, 128, 148, 14, 15, 16, 17, or 170 as shown in FIGS. 1, 3, 5, and 7, or patient care devices 830, 810, 812, 814, 14, 15, 16, 17, or 148 of FIG. 8, and / or patient care devices 904, 906, 908, 14, 15, 16, 17, or 148 of FIG. 9).

[0342] Operation 902 positions a monitoring client having a user interface (e.g., a display, touch screen, display, button, user input accelerometer, etc.) within the operating distance of a patient care device. Operation 904 displays the identification information of the patient care device on the user interface. The patient care device can be identified, for example, by a serial number, device type, or visual display on the user input of the patient care device using a standard or custom discovery protocol. Operation 906 selects a patient care device for pairing using the user interface. For example, the user within operation 906 can touch the touch screen of the monitoring client to display the selection of the patient care device.

[0343] Operation 908 pairs the patient care device with the monitoring client. For example, pairing of the patient care device to the monitoring client can utilize Bluetooth, Bluetooth Low Energy (IEEE 802.15.1), WiFi, infrared communication, near field communication (NFC ISO 13157), IR communication, or optics. As will be apparent in view of the present disclosure, a handshake sequence can be utilized, or not, and a custom pairing protocol can be utilized. Operation 910 communicates patient care parameters between the patient care device and the monitoring client, whereby, for example, the patient care device can be controlled or monitored by the monitoring client.

[0344] Operation 912 optionally communicates additional patient care parameters to another patient care device in an operable manner through the patient care device. In operation 912, when the patient care device is operably coupled or communicating operably with another patient care device, the patient care device can act as a relay or router, whereby the monitoring client can communicate with the other patient care device. In addition or alternatively, the patient care device can use information from another patient care device for its operation, for example, an infusion pump can use the flow rate determined by a flow meter, or the temperature from a temperature probe, and / or the infusion pump can relay information from the flow meter to the monitoring client. In addition, the monitoring client optionally can communicate with a number of patient care devices coupled to the paired patient care device, either in parallel or in series. In addition or alternatively, in some embodiments of the present disclosure, in method 900, the monitoring client communicates with the patient care device using a venous catheter. The communication can occur via electrical communication using the fluid within the venous catheter as a conductive medium through an electrical conductor embedded or attached to the venous catheter, using sound waves traveling through the venous catheter, or optically using the fluid within the catheter as an optical waveguide. Pairing can be set (e.g., between a monitoring client, a hub, a dock, a patient care device and / or a system monitor comprising one or more of a monitoring client, a hub, a dock, a patient care device and / or a system monitor) using communication via the venous catheter and using another communication link, such as Bluetooth, Bluetooth Low Energy, WiFi, etc.

[0345] In further additional embodiments of the present disclosure, the pairing of a first device (e.g., a monitoring client, a hub, a patient care device, or a system monitor) to a second device (e.g., a monitoring client, a hub, a patient care device, or a system monitor) can be configured and / or initialized using a first communication link, whereby the devices are paired using a second communication link. For example, short-range communication or IR communication can be used to set up a pairing between devices, such as using Bluetooth, Bluetooth Low Energy, or WiFi. The pairing setup (e.g., via short-range communication or IR communication) can command requests on a monitoring client, a hub, a patient care device, and / or a system that monitors requests for user confirmation of the pairing, such as a pairing via Bluetooth. In some embodiments, when a patient care device is paired to a hub, a monitoring client, and / or a dock, the ID and software version number are sent to the hub, the monitoring client, and / or the dock, and a server, such as a monitoring server 3, middleware, a cloud server, or another server, is queried to determine whether the software on the patient care device is up to date. If the software is not up to date, the hub, the monitoring client, the dock, or the patient care device itself (e.g., directly) downloads the updated software and programs the patient care device. The patient care device can communicate to the user when the software is up to date and / or, optionally, provide the user with options on a touch screen to update the patient care device if the software is not up to date. The communication link used to set up the pairing (e.g., NFC), and / or the communication link used for the pairing (e.g., Bluetooth, or Bluetooth Low Energy) can communicate the updated software, the ID, the software version number, and provide notifications, etc.For example, one pairing that can be used in a pump patient care device or an insulin pump can be found in (1) the patent application entitled "INFUSION PUMP METHODS AND SYSTEMS" by Mandro et al., filed on March 25, 2010, with Attorney Docket No. I06 and Application No. 12 / 731,843; (2) the patent application entitled "METHODS AND SYSTEMS FOR CONTROLLING AN INFUSION PUMP" by Bryant et al., filed on April 4, 2009, with Attorney Docket No. G98 and Application No. 12 / 416,662; and / or (3) the patent application entitled "INFUSION PUMP ASSEMBLY" by Kamen et al., filed on December 31, 2009, with Attorney Docket No. G75 and Application No. 12 / 347,985. The contents of all three documents are incorporated herein by reference.

[0346] FIG. 14 is a flowchart diagram of a method 1000 for monitoring the operation of a patient care device using a wearable system monitor paired with the patient care device, according to an embodiment of the present disclosure. Method 1000 includes operations 1014-1040 and can utilize various devices 1002, 1004, 1006, 1008, 1100, 1112 to facilitate the pairing of the wearable system monitor of method 1000 to the patient care device. In some embodiments, each of operations 1014-1040 is optional.

[0347] The wearable system monitor of method 1000 may be the wearable system monitor 131 of FIGS. 1, 3, 5, 7, 8, and 9. The pairing of the system monitor of method 1000 for monitoring one or more patient care devices can be performed using any one or more of devices 1002 - 1012, or using any suitable device disclosed herein. For example, the wearable system monitor of method 1000 can be paired with a patient care device using the user interface of monitoring device 1002, the user interface of remote communicator 1004, the user interface of communication device 1006, the user interface of patient care device 1008, the user interface of another patient care device 1010, or the user interface of wearable system monitor 1012.

[0348] The patient care device of method 1000 may be any patient care device disclosed herein, such as the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or other patient care devices disclosed herein.

[0349] The system monitor of method 1000 can be used in the stand - alone system that can be used in the systems 100 of FIG. 1, 300 of FIG. 3, 500 of FIG. 5, 700 of FIG. 7, 800 of FIG. 8, 900 of FIG. 9, and / or can be used in any other suitable system or group of devices disclosed herein.

[0350] Action 1014 identifies the caregiver (e.g., provider) using one or more of a voice recognition algorithm, a face recognition algorithm, a barcode, an RFID tag, near field communication, simple login, a secure signature, etc. For example, the identification of the caregiver in Action 1040 can be performed by a mounted camera and / or microphone by a monitoring client, a monitoring client docking station, a device docking station, a communication module, another dock, or a hub. Also, as a security check, the monitoring client, hub, dock, or patient care device can request that the user enter in a font as displayed to prevent font corruption errors. In addition or alternatively, in some embodiments, after one or more failed logins or authentications, if the device may take and store a picture, the picture may be transmitted for storage to a middleware server. Action 1016 records the presence of the caregiver in one or more of Devices 1002 - 1012. The log entry can be stored in any one of Devices 1002 - 1012, the patient care devices described herein, the monitoring clients described herein, the wearable system monitors described herein, the remote communicators described herein, and / or the hubs described herein. The log of Action 1016 may be for purposes such as caregiver compliance, diagnostic purposes, etc. For example, if a caregiver is scheduled to appear and does not, Action 1016 can record that the caregiver did not appear at the scheduled time.

[0351] The face recognition algorithm of operation 1014 can relay the features of the face of any caregiver, such as analyzing relative dimensions, shape, eye position, nose, jaw, cheekbones, or other facial features. The face recognition algorithm of operation 1014 can use three-dimensional face recognition, skin texture analysis, or other face recognition algorithms. In addition or alternatively, in some embodiments, the voice recognition algorithm of operation 1014 can use hidden Markov models, dynamic time warping-based voice recognition, or one or more other voice recognition algorithms.

[0352] Operation 1018 removes the wearable system monitor from the wearable dock. For example, the system monitor 131 of FIG. 1 can be worn on a patient's arm, and thus can be attached to the patient with a wristband similar to a watch wristband. A part of the wearable system monitor can be removed from a dock (also referred to herein as a "wearable dock") having a wristband and a snap-fit base member to which the wearable system monitor snap-fits. When the wearable system monitor is removed from its dock, operation 1020 starts a timer. The timer and related operations are each optional in method 1000 of FIG. 14.

[0353] The timer of operation 1020 maintains a track of the time the wearable system monitor is outside its dock. Operation 1022 stops the treatment if a predetermined amount of time has elapsed after the wearable system monitor is undocked from the wearable dock. For example, the wearable system monitor of method 1000 can send a signal to an infusion pump to stop pumping. When the wearable system monitor is docked again, operation 1024 resumes the treatment if the treatment was interrupted, for example, by removing the wearable system monitor from its wearable dock after a predetermined amount of time has elapsed.

[0354] As described previously, operation 1018 removes the wearable system monitor from the wearable dock. Operation 1026 identifies the patient using one or more of, for example, a voice recognition algorithm, a face recognition algorithm, a barcode, an RFID tag, near field communication, simple login, caregiver input, etc. Operation 1026 may be similar to operation 1014, may utilize the same software utilized in operation 1014, and / or may utilize one of devices 1002 - 1020. However, note that in some embodiments, the patient identification procedure can include more than just the caregiver's identification information, for example, by using biometrics or other patient-specific identifying information. Using such patient identification criteria can ensure that a particular treatment is being given to the correct patient and / or provide compliance with given regulations. Operations 1014 and / or 1026 can be performed using a passkey device on the patient and / or caregiver.

[0355] Operation 1028 determines whether the caregiver is authorized to pair the wearable system monitor, for example, to pair the wearable system monitor to a patient care device. If the caregiver is not authorized, then method 1000 subsequently prevents additional pairing (or editing of pairing settings) of the wearable system monitor. If the caregiver is authorized to pair the wearable system monitor, operation 1030 enables the caregiver to select one or more patient care devices for pairing with the wearable system monitor. The caregiver authority can be used to, for example, ensure that a particular treatment is being given to the correct patient and / or provide compliance with given regulations.

[0356] The caregiver can provide a list of patient care devices available for pairing on one or more user interfaces of devices 1002 - 1012. During operation 1030, the caregiver selects a wearable system monitor (e.g., the patient wearable system monitor of operation 1018) and a patient care device to pair with each other. Operation 1032 pairs the wearable system monitor with the patient care device, and operation 1034 records the pairing of operation 1032 within the wearable system monitor, including the identification information of the caregiver and the patient. In additional specific embodiments, the pairing of the wearable system monitor with the patient care device can be used in parallel or serial pairing of the patient care device with another device (e.g., a monitoring client, a hub, another patient care device, etc.). As will be appreciated in view of the present disclosure, any suitable pairing protocol (e.g., Bluetooth or IEEE 802.11) can be used. In addition to, or alternatively, operation 1034 can record the pairing within one or more of devices 1002 - 1012.

[0357] Operation 1036 reattaches the wearable system monitor to the wearable dock. Operation 1038 uses the wearable system monitor to identify and authenticate the wearable dock, for example, to determine whether the wearable system monitor and the wearable dock are authorized to dock with each other. For example, operation 1038 can ensure that the wearable system monitor is docked to the correct patient's wearable dock. For example, if the wearable system monitor is docked to the wrong patient's wearable dock, the wearable system monitor recognizes the mistake and, in some embodiments, sends a signal to the patient care device associated with the patient care device to prevent the associated treatment from proceeding by stopping the operation, and can send an alert to a monitoring client, such as monitoring clients 1, 4, or 11 in FIGS. 1, 3, 5, 7, 8, monitoring clients 9, 4, or 11 in FIG. 9, or other monitoring clients disclosed herein. Operation 1024 can resume treatment if the treatment is interrupted, or operation 1040 can treat the patient according to any update settings 1040.

[0358] In some particular embodiments, if a caregiver is identified in operation 1016 and / or a patient is identified in operation 1026, the caregiver can update the treatment settings, for example, on a monitoring client, a hub, a remote communicator, or a patient care device.

[0359] FIG. 15 is a flowchart diagram of a method 1100 for displaying a user interface using a user interface template according to an embodiment of the present disclosure. Method 1100 includes operations 1102-1132. In some embodiments, each of operations 1102-1132 is optional.

[0360] The monitoring client of method 1100 may be one or more of the monitoring clients 1, 4, or 11 of FIGS. 1, 3, 5, 7, 8, the monitoring clients 9, 4, or 11 of FIG. 9, or other monitoring clients disclosed herein. The patient care device of method 1100 may be one or more of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or other patient care devices disclosed herein.

[0361] Method 1100 describes using a user interface template with a monitoring client, but the monitoring client can be replaced with a hub, communication module, another patient care device, or other suitable device having a user interface. The user interface template of the user interface of method 1100 provides a specific area on a predetermined display for displaying patient care parameters. For example, a user interface template for an infusion pump can define a specific area for display on a GUI, such as the current fluid flow rate. The user interface template can also define an area on the display of the monitoring client for displaying the current fluid flow rate, such as received from an infusion pump. The user interface template can include layout information such as instructions on how to display information, descriptions of various widgets, various widgets, graphs, labels for graph axes, labels for the display, buttons, and / or labels for providing control or visual information of one or more patient care devices to the user. The user interface template may be a template that describes a QT-based template, and / or HTML or CSS can be used.

[0362] Operation 1102 identifies or selects a patient care device to communicate with a monitoring client having a user interface. For example, in operation 1102, the monitoring client can automatically identify a predetermined infusion pump previously specified by the patient's treating provider. In addition or alternatively, in operation 1102, the provider can be given a list of patient care devices to select to display information regarding the operation of the selected patient care device(s) on the user interface of the monitoring client.

[0363] Operation 1104 determines whether the patient care device has a stored user interface template. For example, an infusion pump can include a flash memory having a user interface template stored therein. If the patient care device has a stored user interface template, operation 1106 communicates the stored user interface template from the patient care device to a monitoring client having a user interface. Operation 1108 displays the user interface template on the user interface of the monitoring client. Operation 1110 communicates patient care parameters between the patient care device and the monitoring client. Operation 1112 displays the patient care parameters on the displayed user interface template according to the user interface template. For example, a user interface template for an infusion pump can include space for the current infusion rate, and in this example, operation 1112 uses the user interface template to display the current infusion rate (patient care parameter) on the display.

[0364] If it is determined in operation 1104 that the patient care device does not have a user interface template stored in it, method 1100 determines whether the monitoring client has a user interface template to be used to display the patient care parameters of the patient care device. In addition to or alternatively, operation 1104 can issue an alarm via the monitoring client and / or the patient care device. Operation 1114 determines the type of the patient care device. When the type is determined, operation 1116 determines whether a user interface template is stored in the monitoring client according to the type of the patient care device. If there is a user interface template, operation 1118 displays the user interface template on the user interface of the monitoring client. Operation 1120 communicates the patient care parameters between the patient care device and the monitoring client. Operation 1122 displays the patient care parameters on the displayed user interface template according to the user interface template. For example, patient care parameters such as infusion rate can be displayed within a predetermined area of the user interface as specified by the user interface template.

[0365] If the type is not determined by operation 1114 or is not placed within the monitoring client based on the type determined by the user interface template, then operation 1124 will subsequently display a selectable list of multiple user interface templates on the user interface of the monitoring client. In addition to or as an alternative to this, operation 1114 can issue an alarm or alert via the monitoring client and / or the patient care device. Operation 1126 enables the user to select a user interface template from the multiple user interface templates using the user interface of the monitoring client. Operation 1128 displays the user interface template on the user interface of the monitoring client. Operation 1130 communicates patient care parameters between the patient care device and the monitoring client. Operation 1132 displays the patient care parameters on the displayed user interface template according to the user interface template.

[0366] In some embodiments of the present disclosure, the patient care device of method 1100 can also store one or more fonts for display on the monitoring client, for example, using the user interface templates described above. The fonts can be stored in any format such as JPEG, BMP, image format, pre-stored font, etc., and can be transmitted for use within the area to provide display of the operation parameters (e.g., rather than transmitting a value, an image indicating the number or value to be subsequently displayed on the monitoring client is transmitted). In some embodiments, the fonts stored within the monitoring client can be used, whereby the values of the operation parameters are transmitted to the monitoring client for display within the template using the fonts stored within the monitoring client.

[0367] FIG. 16 is a flowchart diagram of a method 1134 for downloading an application for controlling a patient care device according to an embodiment of the present disclosure. In the method 1134 of FIG. 16, a monitoring device is described as an exemplary device for controlling a patient care device, but the monitoring device can be replaced by and / or supplemented by a dock, a hub, a communication module, a remote communicator, a communication device, etc.

[0368] The method 1134 includes operations 1136-1146. In some embodiments, each of the operations 1136-1146 is optional. The monitoring client of the method 1134 may optionally be one of the monitoring clients 1, 4, or 11 of FIGS. 1, 3, 5, 7, 8, the monitoring clients 9, 4, or 11 of FIG. 9, or one of the other monitoring clients disclosed herein. The patient care device of the method 1134 may optionally be one of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or one of the other patient care devices disclosed herein. The server of the method 1134 may optionally be one of the monitoring servers 3 of FIGS. 1, 3, 5, 7, 8, or 9.

[0369] Operation 1136 docks the patient care device within the dock. For example, the infusion device 7 of FIGS. 1, 3, 5, or 7, the infusion devices 830, 810, or 812 of FIG. 8, or the infusion device 904 of FIG. 9 can be docked within their respective docks. In operation 1138, the monitoring client identifies the patient care device. For example, the patient care device can communicate to the monitoring client, for example, an ID number, serial number, description, prescription, treatment plan, patient treatment parameters, etc., for example, by a discovery protocol. The docked patient care device can store therein treatment information (e.g., drug dose, infusion rate, total fluid volume, or other patient treatment parameters) that can be associated with or correspond to the patient, respectively.

[0370] In operation 1140, the monitoring client queries the server for an application (e.g., for setting an infusion rate) to control the patient care device. In operation 1142, the monitoring client downloads the application. The communication between the monitoring client and the server can be encrypted. For example, the server can encrypt the application before transmitting it to the monitoring client, and the monitoring client can decrypt the application using a sufficient encryption key. In addition or alternatively, all communication can be encrypted. During operation 1144, the monitoring client executes the application. In operation 1146, the monitoring client is communicatively and operably coupled to the patient care device through the application by executing the application on one or more processors. The monitoring client can place the application within a sandbox (as described below). In such an embodiment, the application includes a set of processor-executable instructions configured to be executed by one or more processors on the monitoring client. The application can include instructions for displaying a user interface on the display of the monitoring client, for example, using the user interface template of method 1100 of FIG. 15. In addition or alternatively, in some embodiments, the application can be used to control the patient care device by optionally transmitting parameters or values to the patient care device, such as bolus amount, infusion rate, total fluid for delivery, start time of drug delivery, stop time of drug delivery, delivery rate profile, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria.

[0371] FIG. 17 is a flowchart diagram of a method 1200 for ensuring data integrity when communicating data (e.g., requests) for a patient care device, according to an embodiment of the present disclosure. Method 1200 includes operations 1202-1222. In some embodiments, each of operations 1202-1222 is optional. The patient care device of method 1200 can be any patient care device disclosed herein, such as the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIGS. 1, 3, 5, or 7, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or other patient care devices disclosed herein.

[0372] The request is optional and can originate from any authorized, authenticated, and / or identified monitoring client, such as the monitoring clients 1 or 4 of FIGS. 1, 3, 5, 7, or 8, the remote communicator 11 of FIGS. 1, 3, 5, 7, 8, or 9, a mobile phone, a handheld computer, a tablet computer, a laptop computer, a personal computer, a personal digital assistant, etc.

[0373] Operation 1202 presents a request for the patient care device using the user interface of the monitoring client. For example, using the touch screen of the monitoring client 1 of FIG. 1, the user presents an infusion rate for the infusion pump 7. In some embodiments, the request is optional and can be a parameter related to the patient care device, such as a bolus amount, an infusion rate, a total delivery fluid, a start time of drug delivery, a stop time of drug delivery, a delivery rate profile, a pill dispensing instruction for dispensing pills, a pill type, a pill dispensing schedule, and / or a maximum pill dispensing criterion.

[0374] Operation 1204 is optional. Operation 1204 displays a "pending request" on the user interface of the monitoring client. Operation 1206 formats the request for the patient care device. For example, operation 1206 can prepare the request to meet the communication requirements of the patient care device.

[0375] Operation 1208 determines a check value for the request. For example, using a cyclic redundancy check algorithm, a check value corresponding to the request is determined. The check value calculated by the cyclic redundancy check algorithm depends on the request. A 1-bit change in the request also changes the check value calculated by the cyclic redundancy check algorithm. Similarly, a multi-bit change also changes the check value. In addition or alternatively, in other embodiments, parity bits (even or odd) or other data integrity checks can be used.

[0376] Operation 1210 adds the check value to the request. Operation 1212 is optional, and operation 1212 requests confirmation from the user to communicate the request using the user interface. The request for confirmation may be a pop-up dialog box on the touch screen that displays "Did you confirm the injection rate of 90 milliliters per hour?" and has a box for selecting "Confirm". The text and format shown in operation 1212 may be different fonts, different font sizes, and / or different ...

Claims

1. A system for patient care comprising one of a monitoring client and a base, establishing a first communication link via a physical connection between the monitoring client and the other one of the monitoring client and the base, configured to update an interface program via the first communication link, if the one of the monitoring client and the base is the monitoring client, transmitting, via the first communication link, the version number of the interface program on the monitoring client to the base, configured to determine whether the interface program on the monitoring client is the latest version, or, if the one of the monitoring client and the base is the base, retrieving an updated version of the interface program from a server, and being configured to overwrite the interface program on the base with the updated version of the interface program, a system characterized by this.

2. The system according to claim 1, wherein the one of the monitoring client and the base establishes a second communication link for data communication between the one of the monitoring client and the base and the other one of the monitoring client and the base using the first communication link.

3. The system according to claim 2, wherein the monitoring client is configured to receive the data via the second communication link.

4. The system according to claim 1, wherein the monitoring client is configured to display data transmitted from the base.

5. The system according to claim 1, wherein the monitoring client is configured to initialize patient treatment.

6. The system according to claim 1, wherein the monitoring client is configured to monitor and / or control the base.

7. The system according to claim 1, wherein the monitoring client is configured to store and / or transmit error parameters and / or operation parameters for transmission to a server and / or the base.

8. The system according to claim 1, wherein the base is configured to treat a patient. Claim 9 The system according to claim 1, wherein the base is selected from an infusion pump, a pill dispenser, a micro-infusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO2 capnometer, an intravenous bag, a drip flow meter, and a dialysis machine, and combinations thereof. Claim 10 The system according to claim 2, wherein the second communication link is wireless. Claim 11 The system according to claim 2, wherein the base is configured to monitor the quality of the second communication link. Claim 12 The system according to claim 2, wherein communication via the second communication link is permitted when the quality of the second communication link exceeds a threshold value. Claim 13 The system according to claim 2, wherein the monitoring client is configured to enter a headless state when the quality of the second communication link drops below a threshold value. Claim 14 The system according to claim 13, wherein one and / or the other of the monitoring client and the base is configured to exit the headless state when the link quality value becomes greater than the threshold value. Claim 15 The system according to claim 13, wherein the monitoring client is configured to display a message on a user interface based on the headless state. Claim 16 The system according to claim 15, wherein the message relates to the distance between one and the other of the monitoring client and the base. Claim 17 Establishing the second communication link includes determining whether the base is paired with another monitoring client, and / or when the monitoring client is connected to the base by a physical connection, interrupting any pairing between the other monitoring client and the base. The system according to claim 2. Claim 18 The base is configured to generate a configuration file, The monitoring client is configured to read the configuration file, The system according to claim 2, wherein the second communication link complies with the configuration file. Claim 19 The system according to claim 18, wherein the configuration file is transmitted via the first communication link. **Claim 20** The system according to any one of claims 1 to 19, wherein the monitoring client includes a tablet computer.

Images