Systems, methods, and devices for electronic patient care

Abstract

Disclosed are systems, methods, and apparatus for electronic patient care, particularly systems for electronic patient care, the system comprising: a gateway configured to provide at least one of: routing functionality, medical device software updates, and network services; and a medical device configured to operably communicate with the gateway using the network service.

Description

[0001] Divisional application

[0002] This application is a divisional application of the Chinese patent application with application number 202010535030.8, and the Chinese patent application with application number 202010535030.8 is a divisional application of the Chinese patent application with application number 201380072039.8. The application date of the above applications is December 20, 2013, and the name of the invention is “Systems, methods and devices for electronic patient care”.

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application is a nonprovisional application that claims the benefit of U.S. Provisional Patent Application No. 61 / 740,474 (Attorney Docket No. J80), filed on December 21, 2012, and entitled System, Method, and Apparatus for Communicating Data, which is hereby incorporated by reference in its entirety.

[0005] This application is also a continuation-in-part of U.S. Patent Application No. 13 / 723,253, filed on December 21, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2013-0191413-A1 (Attorney Docket No. J85), published on July 25, 2013, which claims priority to and the benefit of:

[0006] U.S. Provisional Patent Application No. 61 / 578,649, filed on December 21, 2011, and entitled “System, Method, and Apparatus for Infusing Fluid” (Attorney Docket No. J02);

[0007] U.S. Provisional Patent Application No. 61 / 578,658, filed on December 21, 2011, and entitled “System, Method, and Apparatus for Estimating Liquid Delivery” (Attorney Docket No. J04);

[0008] U.S. Provisional Patent Application No. 61 / 578,674, filed on December 21, 2011, and entitled System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J05);

[0009] U.S. Provisional Patent Application No. 61 / 651,322, filed May 24, 2012, and entitled “System, Method, and Apparatus for Electronic Patient Care” (Attorney Docket No. J46); and

[0010] U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed on August 3, 2012, and entitled System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, each of which is hereby incorporated by reference in its entirety.

[0011] U.S. Patent Application No. 13 / 723,253 is a continuation-in-part of U.S. Patent Application No. 13 / 333,574, filed on December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2012-0185267-A1 (Attorney Docket No. 197), published on July 19, 2012, and

[0012] PCT application PCT / US11 / 66588, filed December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care (Attorney Docket No. 197WO), both of which are hereby incorporated by reference in their entireties.

[0013] U.S. patent application Ser. No. 13 / 333,574 is a continuation-in-part of U.S. patent application Ser. No. 13 / 011,543, filed on Jan. 21, 2011, and entitled Electronic Patient Monitoring System, which is now U.S. Publication No. US-2011-0313789-A1 (Attorney Docket No. 152), published on Dec. 22, 2011, and claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544 (Attorney Docket No. H53), filed on Jan. 22, 2010, and entitled Electronic Order Intermediation System for a Medical Facility, both of which are hereby incorporated by reference in their entireties.

[0014] This application is also a continuation-in-part of U.S. Patent Application No. 13 / 723,239, filed on December 21, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2013-0297330-A1 (Attorney Docket No. J77), published on November 7, 2013, which claims priority to and the benefit of:

[0015] U.S. Provisional Patent Application No. 61 / 578,649, filed on December 21, 2011, and entitled “System, Method, and Apparatus for Infusing Fluid” (Attorney Docket No. J02);

[0016] U.S. Provisional Patent Application No. 61 / 578,658, filed on December 21, 2011, and entitled “System, Method, and Apparatus for Estimating Liquid Delivery” (Attorney Docket No. J04);

[0017] U.S. Provisional Patent Application No. 61 / 578,674, filed on December 21, 2011, and entitled System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J05);

[0018] U.S. Provisional Patent Application No. 61 / 651,322, filed May 24, 2012, and entitled “System, Method, and Apparatus for Electronic Patient Care” (Attorney Docket No. J46); and

[0019] U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed on August 3, 2012, and entitled System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, each of which is hereby incorporated by reference in its entirety.

[0020] U.S. Patent Application No. 13 / 723,239 claims priority to and the benefit of, and is a continuation-in-part of:

[0021] U.S. Patent Application No. 13 / 333,574, filed December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2012-0185267-A1 (Attorney Docket No. I97), published July 19, 2012, is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, filed January 21, 2011, and entitled Electronic Patient Monitoring System, now U.S. Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), published December 22, 2011, which claims the benefit of U.S. Provisional Patent Application No. 13 / 011,543, filed January 22, 2010, and entitled Electronic Order Intermediation System for a Medical Facility. 61 / 297,544 (Attorney Docket No. H53); and

[0022] PCT Application No. PCT / US11 / 66588, filed on December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now International Publication No. WO 2013 / 095459 (Attorney Docket No. 197WO), published on September 12, 2013, each of which is hereby incorporated by reference in its entirety.

[0023] This application is also a continuation-in-part of U.S. Patent Application No. 13 / 723,242, filed on December 21, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2013-0317753-A1 (Attorney Docket No. J78), published on November 28, 2013, which claims priority to and the benefit of:

[0024] U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, is hereby incorporated by reference in its entirety.

[0025] This application is also a continuation-in-part of U.S. patent application Ser. No. 13 / 900,655, filed May 23, 2013, and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2013-0317837-A1 (Attorney Docket No. K66), published November 28, 2013, which claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, both of which are hereby incorporated by reference in their entireties.

[0026] U.S. Patent Application No. 13 / 900,655, also a continuation-in-part application, claims priority to and the benefit of:

[0027] U.S. Patent Application No. 13 / 480,444, filed May 24, 2012, and entitled Blood Treatment Systems and Methods, now U.S. Publication No. US-2013-0037485-A1, filed February 14, 2013 (Attorney Docket No. J43); and

[0028] PCT Application No. PCT / US12 / 00257, filed on May 24, 2012, and entitled Blood Treatment Systems and Methods, is now International Publication WO / 2012 / 161744 (Attorney Docket No. J43WO), published on November 29, 2012.

[0029] This application is also a continuation-in-part of PCT Application No. PCT / US13 / 42350, filed on May 23, 2013, and entitled System, Method, and Apparatus for Electronic Patient Care (Attorney Docket No. K66WO), which claims priority to and the benefit of U.S. Provisional Patent Application No. 61 / 651,322, filed on May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care (Attorney Docket No. J46), both of which are hereby incorporated by reference in their entireties.

[0030] PCT Application No. PCT / US13 / 42350, also a continuation-in-part application, claims priority to and the benefit of:

[0031] U.S. Patent Application No. 13 / 480,444, filed May 24, 2012, and entitled Blood Treatment Systems and Methods, now U.S. Publication No. US-2013-0037485-A1, filed February 14, 2013 (Attorney Docket No. J43); and

[0032] PCT Application No. PCT / US12 / 00257, filed on May 24, 2012, and entitled Blood Treatment Systems and Methods, is now International Publication WO / 2012 / 161744 (Attorney Docket No. J43WO), published on November 29, 2012.

[0033] This application may also be related to one or more of the following patent applications filed on December 21, 2012, all of which are hereby incorporated by reference in their entirety:

[0034] Nonprovisional Application No. 13 / 723,238, entitled System, Method, and Apparatus for Clamping (Attorney Docket No. J47);

[0035] Nonprovisional Application No. 13 / 723,235, entitled System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J74);

[0036] PCT Application No. PCT / US12 / 71131, entitled System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J74WO);

[0037] Nonprovisional Application No. 13 / 724,568, entitled System, Method, and Apparatus for Estimating Liquid Delivery (Attorney Docket No. J75);

[0038] Nonprovisional Application No. 13 / 725,790, entitled System, Method, and Apparatus for Infusing Fluid (Attorney Docket No. J76);

[0039] PCT Application No. PCT / US12 / 71490, entitled System, Method, and Apparatus for Infusing Fluid (Attorney Docket No. J76WO);

[0040] Nonprovisional Application No. 13 / 723,244, entitled System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Attorney Docket No. J79);

[0041] PCT Application No. PCT / US12 / 71142, entitled System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Attorney Docket No. J79WO);

[0042] Nonprovisional Application No. 13 / 723,251, entitled System, Method, and Apparatus for Estimating Liquid Delivery (Attorney Docket No. J81); and

[0043] PCT Application No. PCT / US12 / 71112, entitled System, Method, and Apparatus for Estimating Liquid Delivery (Attorney Docket No. J81WO).

[0044] This application is also related to one or more of the following patent applications, all of which are incorporated herein by reference in their entirety:

[0045] U.S. Provisional Patent Application No. 61 / 738,447, filed on December 18, 2012, and entitled “System, Method, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification” (Attorney Docket No. J32);

[0046] U.S. Provisional Patent Application No. 13 / 840,339, filed on March 15, 2013, and entitled Apparatus for Infusing Fluid (Attorney Docket No. K14);

[0047] PCT Application No. PCT / US13 / 32445, filed on March 15, 2013, entitled Apparatus for Infusing Fluid (Attorney Docket No. K14WO);

[0048] U.S. patent application No. 13 / 833,432, filed on March 15, 2013, and entitled Syringe Pump and Related Method (Attorney Docket No. K21);

[0049] U.S. patent application No. 13 / 836,497, filed on March 15, 2013, and entitled System and Apparatus for Electronic Patient Care (Attorney Docket No. K22);

[0050] U.S. patent application No. 13 / 833,712, filed on March 15, 2013, and entitled “System, Method, and Apparatus for Clamping” (Attorney Docket No. K23);

[0051] U.S. patent application No. 13 / 834,030, filed on March 15, 2013, and entitled “System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow” (Attorney Docket No. K28);

[0052] U.S. patent application No. 61 / 860,398, filed on July 31, 2013, and entitled System, Method, and Apparatus for Bubble Detection in a Fluid Line Using a Split-Ring Resonator (Attorney Docket No. K31);

[0053] U.S. patent application No. 61 / 900,431, filed on November 6, 2013, and entitled “System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow” (Attorney Docket No. K52);

[0054] U.S. Patent Application No. 61 / 894,801, filed on October 23, 2013, and entitled Syringe Pump and Related Method (Attorney Docket No. K88);

[0055] U.S. patent application No. 61 / 843,574, filed July 8, 2013, and entitled “System, Method, and Apparatus for Clamping” (Attorney Docket No. K75);

[0056] U.S. patent application No. 13 / 971,258, filed on August 20, 2013, and entitled “Electronic Patient Monitoring System” (Attorney Docket No. K84);

[0057] U.S. Patent Application No. 61 / 904,123, filed on November 14, 2013, and entitled Syringe Pump and Related Method (Attorney Docket No. L33);

[0058] U.S. patent application No. 14 / 101,848, filed on December 10, 2013, and entitled “System, Method, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification” (Attorney Docket No. L05);

[0059] U.S. patent application entitled “System, Method, and Apparatus for Communicating Data” filed on December 20, 2013 (Attorney Docket No. L49);

[0060] PCT application entitled System, Method, and Apparatus for Communicating Data, filed on December 20, 2013 (attorney docket number L49WO);

[0061] U.S. patent application entitled “Computer-Implemented Method, System, and Apparatus for Electronic Patient Care” filed on December 20, 2013 (Attorney Docket No. K50);

[0062] PCT application entitled Computer-Implemented Method, System, and Apparatus for Electronic Patient Care filed on December 20, 2013 (Attorney Docket No. K50WO); and

[0063] U.S. patent application entitled System, Method, and Apparatus for Electronic Patient Care (Attorney Docket No. L52), filed December 20, 2013. Technical Field

[0064] The present disclosure relates to patient care and, more particularly, to a system, method, and apparatus for electronic patient care. Background Art

[0065] Providing patient care in a hospital typically requires the interaction of numerous professionals and caregivers (e.g., physicians, nurses, pharmacists, technicians, nurse practitioners, etc.) and any number of medical devices / systems required for a given patient's treatment. While systems exist that aim to facilitate the care process, such as those containing electronic medical records ("EMRs") and computer-assisted physician order entry ("CPOE"), the process of providing comprehensive care to a patient, including prescribing and delivering medical treatments such as medications, involves several non-trivial issues. Summary of the Invention

[0066] In an exemplary embodiment involving the prescribing and administration of medications, an electronic patient care system may include a first data collection module (e.g., a monitoring client) and a second order entry module (e.g., a stationary or portable monitoring client), the second order entry module having a user interface for sending orders or receiving patient-related information. The first module may be configured to receive and store measured parameters related to the patient's current condition (i.e., patient condition parameters), such as blood pressure, heart rate, heart rhythm, temperature, blood oxygenation, respiratory rate, or ventilation. The first module may also be configured to receive information regarding pre-stored parameters related to the patient from a first database (e.g., an EHR database containing patient-related information). The parameters may include patient condition parameters such as drug allergies or sensitivities, other currently taken medications in the patient's tissues, age, weight, height, and renal or liver function. The first module may also be configured to obtain drug information regarding the prescribed medication and / or pre-stored medication from a second database (e.g., a drug information database), such as known drug interactions and the effects of the medication or pre-stored medication on blood pressure, pulse, heart rate, or respiratory rate. The first module can be configured to compare the patient's currently measured patient condition parameters and received pre-stored patient condition parameters with known normal ranges and create a table of patient condition parameters found to be outside of the normal range. The first module can then compare the table of patient condition parameters with a table of corresponding parameters obtained from a medication information database. If a match is found between the table of patient condition parameters and the table of corresponding parameters, the first module can then retrieve one or more pre-entered and stored messages for transmission to the second (order entry) module. These messages can include, for example, warnings to the user of the second module regarding the specific medication being prescribed, the patient's pre-stored medications, and the patient's current and pre-stored medical conditions. Optionally, once the second module has received a warning and the user of the second module has acknowledged the warning via an input signal from the user interface, further repetition of the warning can be avoided.

[0067] In other embodiments, the electronic patient care system can provide the user with editable default values ​​derived from standard medications and dosing instructions obtained from a drug information database, and can alert the user to modifications that may be indicated based on the patient's current and pre-existing medical conditions, allergies, existing medications, or other patient condition parameters. Preferably, the electronic patient care system minimizes the amount of typing required by the user.

[0068] In other embodiments, the first module or another module of the electronic patient care system can also be used to identify the ordered medication to be delivered to the patient's bedside (using, for example, a barcode and reader, or an RFID tag and scanner) and verify that the appropriate medication and dosage are being prepared and delivered to the patient. In one embodiment, the first module can also interact with a patient care device that performs the treatment, such as an infusion pump or pill dispenser, via a wired or wireless communication link. In the case of an infusion pump, the first module or another connected module can provide the infusion pump with patient treatment parameters (e.g., infusion settings including infusion rate or infusion pressure) and receive various operating parameters from the infusion pump, such as the presence of air in the infusion line, the amount of solution remaining in an IV bag connected to the infusion pump, or the fluid pressure in the infusion line. If these operating parameters are found to be abnormal, the first module can be configured to respond by signaling the infusion pump to stop the infusion, by signaling a mechanical occlusion device to occlude the IV line, and / or by alerting a healthcare provider or other person of the abnormality directly via an alert contained in the first module or by sending an alert to the second module. In yet another embodiment, the first module can also be configured to communicate with various patient care devices used to monitor the patient's condition and determine patient condition parameters, such as blood pressure monitors, electrocardiogram monitors, pulse oximetry monitors, and temperature monitors. The various monitored parameters are monitored and / or recorded by the mobile device and / or recorded within the EMR. In some cases, the first module can be programmed to issue an alert to the patient or others when the monitored patient condition parameter falls outside a predetermined range. In some embodiments, the first module can send a signal to the monitoring client to take an unplanned measurement via the patient care device to obtain another patient condition parameter. The first module can communicate with various health care providers at various locations, and in one embodiment, the first module is capable of notifying its assigned patient of an anomaly and recommending corrective action through, for example, an audible alert or a recorded message.

[0069] In one embodiment, a system for preparing a micropump includes a monitoring client, a pharmacy computer, a compounding robot, a micropump, and a data downloader. The monitoring client is configured to transmit a prescription order via a user interface. The pharmacy computer is in operable communication with the monitoring client to receive the prescription order. The compounding robot is configured to dispense the prescription into at least one liquid corresponding to the prescription order. The micropump is configured to receive the at least one liquid corresponding to the prescription order. The data downloader is configured to download the prescription order into a memory of the micropump.

[0070] In some embodiments, the compounding robot fills the micropump with the at least one liquid. The compounding robot can be in operable communication with a data download device, and the compounding robot can instruct the data download device to download the prescription order to the memory of the micropump. The data download device can receive the prescription order from the compounding robot and / or the pharmacy computer. In some embodiments, the compounding robot receives the prescription order from the pharmacy computer.

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

[0072] The sandbox component is configured to control access to at least one of the hardware resources and the software resources. The hub is further configured to identify the patient care device and execute an application for monitoring the patient care device. The hub executes the application within the sandbox component so that the application accesses at least one of the hardware resources and the software resources through the sandbox component.

[0073] The hub may be further configured to control a patient care device, which may be one or more of an infusion pump, a pill dispenser, a micropump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a carbon dioxide monitor, an IV bag, and / or a drip flow meter.

[0074] The hub can be configured to receive an identifier (e.g., a serial number, a code (encrypted or unencrypted), or other identifying value) from a patient-care device and download an application from a server associated with the identifier. The hub can also be configured to receive an identifier from a patient-care device and update an application from a server associated with the identifier.

[0075] The hardware resources may be hard drives, memories, buzzers, microphones, speakers, and cameras. The software resources may be variables, secure data objects, secure variables, secure APIs, APIs, and software representations of hardware components.

[0076] In yet another embodiment, a system for electronic patient care includes a hub. The hub is configured to monitor a patient care device. The sandbox may be configured to control access to at least one of hardware resources and software resources. The hub is further configured to identify the patient care device and execute an application for monitoring the patient care device. The hub executes the application within the sandbox component such that the application accesses at least one of the hardware resources and software resources through the sandbox component. The hub may be further configured to control the patient care device. The hub may be further configured to receive an identifier from the patient care device and download an application from a server associated with the identifier. The hub may be further configured to receive an identifier from the patient care device and update the application from the server associated with the identifier.

[0077] The hardware resources may be hard drives, memories, buzzers, microphones, speakers, and cameras. The software resources may be variables, secure data objects, secure variables, secure APIs, APIs, and software representations of hardware components.

[0078] In yet another embodiment, a system for electronic patient care includes a monitoring client. The monitoring client is configured to monitor a patient care device. The monitoring client includes an operating system component configured to access at least one of hardware resources of the monitoring client and software resources of the monitoring client. 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 the patient care device and execute an application for monitoring the patient care device. The monitoring client executes the application within the sandbox component, allowing the application to access at least one of the hardware resources and the software resources through the sandbox component. The monitoring client is further configured to control the patient care device.

[0079] The patient care device may be an infusion pump, a pill dispenser, a micropump, an ECG monitor, a blood pressure monitor, a pulse oximeter and / or a carbon dioxide monitor, an IV bag, and a drip flow meter.

[0080] The monitoring client may be further configured to receive an identifier from the patient-care device and download the application from the server associated with the identifier. The monitoring client may be further configured to receive an identifier from the patient-care device and update the application from the server associated with the identifier.

[0081] The hardware resources may be hard drives, memories, buzzers, microphones, speakers, and cameras. The software resources may be variables, secure data objects, secure variables, secure APIs, APIs, and software representations of hardware components.

[0082] 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 hardware resources and software resources. The monitoring client may be further configured to identify the patient care device and execute an application for monitoring the patient care device. The monitoring client executes the application within the sandbox component, allowing the application to access 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.

[0083] The patient care device may be an infusion pump, a pill dispenser, a micropump, an ECG monitor, a blood pressure monitor, a pulse oximeter and / or a carbon dioxide monitor, an IV bag, and a drip flow meter.

[0084] The monitoring client may be further configured to receive an identifier from the patient-care device and download the application from the server associated with the identifier. The monitoring client may be further configured to receive an identifier from the patient-care device and update the application from the server associated with the identifier.

[0085] The hardware resources may be hard drives, memories, buzzers, microphones, speakers, and cameras. The software resources may be variables, secure data objects, secure variables, secure APIs, APIs, and software representations of hardware components.

[0086] 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 the patient and the patient care device (e.g., an infusion pump). The hub is also configured to download at least one treatment parameter (e.g., an infusion medication 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 based on at least one of the following: reading an RFID tag using an RFID interrogator, reading voice using voice recognition software coupled to a microphone, reading a face using facial recognition software coupled to a camera, reading a biometric parameter from a biometric reading, reading an identifier, or reading a barcode read by a barcode reader. In one embodiment, the hub may download the at least one treatment parameter using one or more of the identification techniques described herein.

[0087] 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 the patient and the 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 medication and / or an infusion rate or rate profile) from the electronic medical record and program the patient care device with the at least one treatment parameter. The monitoring client identifies the patient based on at least one of the following: reading an RFID tag using an RFID interrogator, reading voice using voice recognition software coupled to a microphone, reading a face using facial recognition software coupled to a camera, reading a biometric parameter from a biometric reading, reading an identifier, or reading a barcode from a barcode reader. In one specific embodiment, the monitoring client may download the at least one treatment parameter using one or more of the identification techniques described herein.

[0088] In yet another embodiment, a system for electronic patient care includes a monitoring client, a monitoring client base, a patient-care device, and a device base. The monitoring client is configured to transmit at least one patient-care parameter. The monitoring client base is configured to receive the monitoring client for docking the monitoring client to the monitoring client base. The patient-care device is configured to transmit at least one patient-care parameter. The device base is configured to receive the patient-care device for docking the patient-care device to the device base.

[0089] In one embodiment, the monitoring client base and the device base are configured to communicate one of: wirelessly, and via a cable operatively coupled to the monitoring client base and the device base.

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

[0091] In another embodiment, the monitoring client base is configured to communicate wirelessly with the monitoring client, and wherein the monitoring client operably communicates with the patient-care device by wirelessly transmitting at least one patient-care parameter with the monitoring client base via a cable to the base and the docked patient-care device.

[0092] In another embodiment, the monitoring client is operable to transmit at least one patient-care parameter to the monitoring client base using wireless communication when the monitoring client determines one of the following situations: communication via cable is unavailable; and the monitoring client is removed from the monitoring client base.

[0093] In another embodiment, the device base is configured to communicate wirelessly with a monitoring client, and wherein the monitoring client operably communicates with the patient-care device by wirelessly transmitting at least one patient-care parameter to the docked patient-care device using the device base.

[0094] In another embodiment, the monitoring client operatively transmits at least one patient care parameter utilizing wireless communication with the device base when the monitoring client determines at least one of the following: communication via the cable is unavailable; communication between the monitoring client and the monitoring client base is unavailable; and the monitoring client is removed from the monitoring client base.

[0095] In another embodiment, the patient-care device is configured to communicate wirelessly with a monitoring client, and wherein the monitoring client wirelessly transmits at least one patient-care parameter with the patient-care device.

[0096] In another embodiment, the monitoring client operatively communicates at least one patient-care parameter wirelessly with the patient-care device when the monitoring client determines at least one of the following: communication via the cable is unavailable; communication between the monitoring client and the monitoring client base is unavailable; communication between the device base and the patient-care device is unavailable; the monitoring client is removed from the monitoring client base.

[0097] In another embodiment, the monitoring client base and the base are configured to wirelessly transmit at least one patient parameter. The system may further include a cable operatively coupled to the monitoring client base and the device base; and wherein the monitoring client base and the base are configured to communicate wirelessly when at least one of the device base, the monitoring client base, and the monitoring client determines that the cable is not available as a communication link.

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

[0099] In another embodiment, the patient care device is one of the following: an infusion pump, a pill dispenser, a micropump, an ECG monitor, a blood pressure monitor, a pulse oximeter and capnometer, an IV bag, and a drip flow meter.

[0100] In another embodiment, the patient care parameter is at least one of: an intravenous pump flow parameter, an electrocardiogram parameter, a blood pressure parameter, a pulse oximeter parameter, a capnography parameter, an intravenous bag parameter, and a drip flow meter value. The patient care parameter may be a patient condition parameter and / or a patient treatment parameter.

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

[0102] In another embodiment, a cable is operably connected to a monitoring client base and a device base; wherein the monitoring client is configured to transmit at least one patient-care parameter to the patient-care device via the cable when the patient-care device is docked to the device base and the monitoring client is docked to the monitoring client base.

[0103] In yet another embodiment, a system for electronic patient care includes a monitoring client, a patient-care device, and a device base. The monitoring client is configured to transmit at least one patient-care parameter. The patient-care device is configured to transmit at least one patient-care parameter. The device base is configured to receive the patient-care device for docking the patient-care device to the device base and to receive the monitoring client for docking the monitoring client to the device base.

[0104] In yet another embodiment, a system for electronic patient care includes: a patient-care device configured to transmit at least one patient-care parameter; a monitoring client configured to transmit the at least one patient-care parameter; and a device base configured to receive the patient-care device for docking the patient-care device to the device base. The device base and the monitoring client are integrated together.

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

[0106] In yet another embodiment, a system for electronic patient care includes: a patient-care device configured to transmit at least one patient-care parameter; a hub client configured to transmit the at least one patient-care parameter; and a device base configured to receive the patient-care device for docking the patient-care device to the device base. The hub can be plugged into the device base to establish a communication link therebetween. The system can also include a monitoring client operable to communicate with the hub to receive the at least one patient-care parameter. The patient therapy parameter can be operable to be transmitted to the hub, and the hub transmits the patient therapy parameter to the patient-care device.

[0107] In a particular embodiment, the hub may include a user interface, and the hub may require user authentication before sending patient therapy parameters to the patient-care device.

[0108] In a particular embodiment, the monitoring client may include a user interface, and the monitoring client may require user authentication before sending patient treatment parameters to the patient-care device through the hub.

[0109] In a particular embodiment, a patient-care device may include a user interface, and the patient-care device may require user verification of patient treatment parameters before treating the patient.

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

[0111] The hub may be further configured to identify the patient-care device and execute an application for monitoring the patient-care device.The hub may execute the application within the sandbox component so that the application accesses at least one of the hardware resources and the software resources through the sandbox component.

[0112] 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 in communication with the at least one patient monitor to receive at least one patient parameter from the at least one patient monitor; and a monitoring server in operable communication with the monitoring client to receive at least one patient parameter from the monitoring client.

[0113] In another embodiment, the system may further include a remote communicator in operable communication with the at least one patient monitor to receive at least one patient parameter.

[0114] The at least one patient monitor may include at least one of an electrocardiogram (ECG) monitor, a blood pressure monitor, a pulse oximeter (POO) monitor, and a carbon dioxide (CO2) monitor. The monitoring client may be configured to download patient information based on a specified unique patient identifier. The unique patient identifier may be encoded in a barcode disposed on the wristband. The unique patient identifier may be encoded on an RFID tag (e.g., an RFID reader) coupled to the wristband. The patient information may include a patient condition or patient care parameters. The unique patient identifier may be operable to be transmitted to the monitoring server to obtain electronic permission for transmitting patient-specific data. A subset of the patient-specific data may be stored in a memory of the monitoring client. The monitoring client may be adapted to determine whether a new medical order meets predetermined criteria based on the subset of patient-specific data stored in the memory.

[0115] In another embodiment, the system further comprises a portable monitoring client adapted to submit a new medical order to the monitoring client. At least one of the monitoring client and / or the remote communicator may be adapted to transmit the new medical order to the monitoring server, and wherein the monitoring server may be adapted to determine whether the new medical order meets another predetermined criterion.

[0116] In another embodiment, the new medical order may be a medication order, and the monitoring server may be adapted to determine whether the new medical order meets another predetermined criterion by determining whether a currently prescribed medication conflicts with the medication order. The monitoring server may communicate with a database to determine whether the new medical order meets the another predetermined criterion. The monitoring server may be configured to send an alert to the monitoring client when the new medical order does not meet the another predetermined criterion.

[0117] In another embodiment, the system may include remote communications adapted for operable communication with at least one of the monitoring client and the monitoring server.

[0118] In another embodiment, the monitoring client may be one of the following: a desktop-based device, a portable device, a handheld controller, a notebook PC, a netbook PC, a tablet PC, and a smart phone. The monitoring client includes a touch screen.

[0119] In another embodiment, the system may further include an infusion pump, and the monitoring client is in operable communication with the infusion pump. The infusion pump may be attached to the monitoring client. The infusion pump may be detachable from the monitoring client.

[0120] In another embodiment, the system further comprises a base configured to dock the monitoring client to the infusion pump.

[0121] In another embodiment, the monitoring client is in operable communication with the infusion pump via a wireless link.

[0122] In another embodiment, the monitoring server is configured to communicate with a plurality of databases, and wherein at least one of the plurality of databases comprises a different data format or communication protocol than another database of the plurality of databases.

[0123] In another embodiment, the monitoring server is adapted to format data from the plurality of databases for downloading the data to the monitoring client. Optionally, in a specific embodiment, the monitoring client may transmit at least one patient parameter to the monitoring server. In a specific embodiment, the patient parameter may be one or more of the following and / or may include at least one of the following: treatment progress of an infusion pump, an electrocardiogram signal, a blood pressure signal, a pulse oximeter signal, a capnography signal, and / or a temperature signal.

[0124] In another embodiment, the monitoring server may be configured to download operating instructions to the infusion pump via the monitoring client.

[0125] The monitoring client may receive a user request to read patient parameters and may query the monitoring device to receive the patient parameters.

[0126] In another embodiment, the system may further include a portable monitoring client. The portable monitoring client may be in operable communication with the monitoring client for directly transmitting patient information, thereby bypassing the monitoring server. The portable monitoring client may be configured to change at least one parameter of the infusion pump and transmit the changed at least one parameter to the monitoring server.

[0127] Changes to patient orders submitted via a portable monitoring client may be sent to another portable monitoring client.

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

[0129] The system may further comprise another monitoring client adapted to receive information from the patient specific database.

[0130] The information may include at least one of: patient orders, patient medications, progress notes, monitoring data from a patient monitor, and treatment data from an attached device.

[0131] The monitoring server may be configured to query an electronic health record database to receive patient information from the database.The monitoring server may be further configured to populate the monitoring client with a set of predefined information based on the patient information.

[0132] The set of predefined information may include at least one of the following: patient age, height, weight, diagnosis, current medication, medication class, medication allergy history, and sensitivity.

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

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

[0135] In some specific embodiments, the method may further include sending the alert from the monitoring client to a portable remote communicator device having a display.

[0136] In another embodiment, an electronic patient-care system includes: a monitoring client configured to transmit at least one patient-care parameter; a patient-care device configured to transmit at least one patient-care parameter; and a communication interface configured to facilitate communication between the monitoring client and at least one patient-care device by detecting the presence of at least one patient-care device and converting communication signals from the device into a communication protocol associated with the monitoring client.

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

[0138] In another specific embodiment, the communication interface is further configured to provide power suitable for each of the devices. In yet another specific embodiment, the system further comprises one or more databases accessible to the monitoring client, the one or more databases allowing at least one of: centralized storage of patient information, and / or downloading of information that can be used in the treatment of a patient associated with the monitoring client.

[0139] In another particular embodiment, the communication interface is further configured to perform fault checking to perform at least one of: evaluating data integrity of communications with the patient-care device, evaluating whether the monitoring client is operating properly, evaluating whether the patient-care device is operating properly, and / or evaluating whether the communication interface is operating properly.

[0140] In another embodiment, an electronic patient-care system includes: a hub client configured to transmit at least one patient-care parameter; a patient-care device configured to transmit the 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 communication signals from the device into a communication protocol associated with the hub.

[0141] In a particular embodiment, the communication interface is further configured to discover the presence of additional other patient-care devices that are distinct from one another and to convert communication signals from these devices to a communication protocol associated with the hub.

[0142] In another specific embodiment, the communication interface is further configured to provide power suitable for each of the devices. In yet another specific embodiment, the system further comprises one or more databases accessible to the hub, the one or more databases allowing at least one of: centralized storage of patient information, and / or downloading of information that can be used in the treatment of a patient associated with the hub.

[0143] In another particular embodiment, the communication interface is further configured to perform fault checking to perform at least one of: evaluating data integrity of communications with the patient-care device, evaluating whether the monitoring client is operating properly, evaluating whether the patient-care device is operating properly, and / or evaluating whether the communication interface is operating properly.

[0144] In another embodiment, an electronic patient-care system includes: a base configured to transmit at least one patient-care parameter; a patient-care device configured to transmit at least one patient-care parameter; and a communication interface configured to facilitate communication between the base and at least one patient-care device by detecting the presence of at least one patient-care device and converting communication signals from the device into a communication protocol associated with the base.

[0145] In a particular embodiment, the communication interface is further configured to discover the presence of additional other patient-care devices that are different from each other and convert communication signals from these devices to a communication protocol associated with the base.

[0146] In another specific embodiment, the communication interface is further configured to provide power suitable for each of the devices. In yet another specific embodiment, the system further comprises one or more databases accessible to the base, the one or more databases allowing at least one of: centralized storage of patient information, and / or downloading of information that can be used in the treatment of a patient associated with the base.

[0147] In another particular embodiment, the communication interface is further configured to perform fault checking to perform at least one of: evaluating data integrity of communications with the patient-care device, evaluating whether the monitoring client is operating properly, evaluating whether the patient-care device is operating properly, and / or evaluating whether the communication interface is operating properly.

[0148] In one embodiment, a patient care device includes a body; a channel within the body configured to receive a rod; and two friction members coupled to the body and configured to frictionally lock the body to the rod within the channel.

[0149] In one embodiment, a hub includes: a patient-care device interface; a power supply 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, the transceiver configured to provide communication between the processor and the patient-care device. In certain embodiments, the processor may be configured to disable the patient-care device when in a warning state.

[0150] In one embodiment, a base includes: a patient-care device interface; a power supply 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, the transceiver configured to provide communication between the processor and the patient-care device. In certain embodiments, the processor can be configured to disable the patient-care device when in a warning state.

[0151] In one embodiment, a communication module includes: a patient-care device interface; a power supply 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, the transceiver configured to provide communication between the patient-care device and another device. In certain embodiments, the processor can be configured to disable the patient-care device when in a warning state.

[0152] In another embodiment, a patient care system includes a base, a plurality of modular patient care devices configured to dock with the base, and a retractable display for monitoring a client. The modular patient care devices can be mated to the base along a horizontal surface, in a staggered manner, or via connectors.

[0153] In yet another embodiment, an electronic patient care system comprises a first module configured to receive and store information relating to a patient, the information comprising data relating to a first parameter of the patient measured by a device connected to the patient and data relating 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 order from a user via a user interface associated with the second module, the second module being further configured to send the treatment order to the first module, wherein the first module is further configured to: a) obtain medication information regarding the medication or other medications from the second database, the medication information comprising data providing restrictions under which such medications are generally taken; b) determine whether the medication order must (in this particular embodiment) be confirmed by the second module based on the medication information, the value of the first parameter, and the value of the second parameter; and c) send a pre-established message from the first module to the second module for display on the user interface, the message confirming or warning regarding the acceptability of the medication order.

[0154] The drug information may include drug interaction information, drug allergy information, blood pressure impact information, heart rate impact information, heart rhythm impact information or respiratory impact information, and wherein the first parameter or the second parameter includes data related to the patient's current medication, known drug allergy history, current blood pressure, current pulse rate, current heart rhythm, current respiratory rate or current ventilation.

[0155] The pre-established message may include a warning regarding a potential effect of the ordered medication, the warning including measured data regarding the first parameter, received data regarding the second parameter, or medication information obtained by the first module.

[0156] The first module may be configured to generate a signal that the medication order or a modified medication order should be carried out after the pre-established message has been sent and a confirmation signal has been received from the second module, the confirmation signal being triggered by an input signal from the user interface.

[0157] In another embodiment, a patient-care device includes a first communication link and a second communication link; and a base includes the first communication link and the second communication link. When the patient-care device and the base are within a predetermined range, the patient-care device and the base are paired using the first communication link and maintain communication using the second communication link after pairing. Pairing using the first communication link may be pairing the patient-care device and the base for use with the second communication link. The first communication link may be near-field communication, and the second communication link may be Bluetooth, Bluetooth Low Energy, WiFi, or other communication link.

[0158] In another embodiment, a patient-care device includes a first communication link and a second communication link; and a monitoring client includes the first communication link and the second communication link. When the patient-care device and the monitoring client are within a predetermined range, the patient-care device and the monitoring client are paired using the first communication link and maintain communication using the second communication link after pairing. Pairing using the first communication link may be pairing the patient-care device and the monitoring client for use with the second communication link. The first communication link may be near-field communication, and the second communication link may be Bluetooth, Bluetooth Low Energy, WiFi, or other communication link.

[0159] In some embodiments, the patient-care device includes a memory having a user interface template stored therein. The user interface template can be transmitted to a base, a hub, and / or a monitoring client for display on a user interface of the base, the hub, and / or the 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).

[0160] In yet another embodiment, an infusion pump includes attachable electronic components including at least one processor, a power regulator, and a control system.

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

[0162] In yet another embodiment, a wearable system monitor includes a watchdog component and a transceiver. The wearable system monitor may include 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 base, a hub, a monitoring client, and / or a patient-care device.

[0163] In another embodiment, a method includes one or more of the following steps: establishing a communication link between a patient-care device and a monitoring server; transmitting patient-care parameters to the monitoring server; reverse-identifying the patient-care parameters; and / or storing the reverse-identified patient-care parameters in the monitoring server.

[0164] In another embodiment, a method includes one or more of the following steps: establishing a communication link between a monitoring server and a plurality of patient-care devices associated with a plurality of patients; transmitting a plurality of patient-care parameters from the plurality of patient-care devices to the monitoring server; reverse-identifying the patient-care parameters; storing the patient-care parameters in the monitoring server; treating the plurality of patients with a treatment regimen; and analyzing a subset of the plurality of patient-care parameters associated with the plurality of patients to determine the efficacy of the treatment.

[0165] In yet another embodiment, a patient-care device (eg, an infusion pump) may be hot-swappable in at least one of the base, hub, and / or monitoring client connection.

[0166] In yet another embodiment, a method for a hot-swappable patient-care device having, for example, an infusion pump, includes one or more of the following steps: 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 a working memory; and resuming operation of the patient-care device. In another embodiment, the method may include determining that operation of the patient-care device can be resumed.

[0167] In yet another embodiment, a method for a hot-swappable patient-care device having, for example, an infusion pump, includes one or more of the following steps: 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 a working memory; and resuming operation of the patient-care device. In another embodiment, the method may include determining that operation of the patient-care device can be resumed.

[0168] In yet another embodiment, a method for pairing includes: positioning a monitoring client and / or hub having a user interface within an operative distance of a patient-care device (e.g., an infusion pump); displaying an identity of the patient-care device on the user interface; selecting a patient-care device for pairing using the user interface; pairing the patient-care device with the monitoring client and / or hub; and / or transmitting patient-care parameters to the monitoring client and / or hub. In yet another embodiment, the method may optionally include transmitting, via the patient-care device, additional patient-care parameters operatively with another patient-care device, e.g., to the monitoring client and / or hub.

[0169] In another embodiment, a method includes docking a patient-care device into a base; identifying the patient-care device; querying a server for an application for controlling the patient-care device; downloading the application into the base, hub, and / or monitoring client; executing the application using the base, hub, and / or monitoring client; and using the application to control the patient-care device.

[0170] In another embodiment, a method includes: placing a patient-care device in operable communication with a hub; the hub can identify the patient-care device; the hub can query a server for an application for controlling the patient-care device; the hub can download the application into the hub; the hub can execute the application; and the hub can use the application to control the patient-care device.

[0171] In another embodiment, a method includes placing a patient-care device in operable communication with a base; the base can identify the patient-care device; the base can query a server for an application for controlling the patient-care device; the base can download the application into the base; the base can execute the application; and the base can use the application to control the patient-care device.

[0172] In another embodiment, a method includes placing a patient-care device in operable communication with a monitoring client; the monitoring client can identify the patient-care device; the monitoring client can query a server for an application for controlling the patient-care device; the monitoring client can download the application into the monitoring client; the monitoring client can execute the application; and the monitoring client can use the application to control the patient-care device.

[0173] In yet another embodiment, a method may include submitting a request on a user interface of a communication device; confirming the request; sending the request; receiving the request with a check value; and, before sending, confirming that the check value complies with the request.

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

[0175] In yet another embodiment, the hub is in operable communication with at least one of an electronic medical record, DERS, CPOE, and / or the Internet to control and / or monitor the patient-care device.

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

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

[0178] In one embodiment, a patient-care device includes a screen and an accelerometer. The patient-care device is configured to display the screen in an upright posture determined using the accelerometer.

[0179] In yet another embodiment, an electronic patient-care system includes a monitoring client and a base configured to couple to a pole. An adapter can be coupled to the base. The adapter can include at least one electronic coupler for enabling operable communication between a patient-care device and the monitoring client. The monitoring client can be slid into the adapter.

[0180] In yet another embodiment, an 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 to the monitoring client. For example, the monitoring client cannot direct the patient care device to perform unsafe operations.

[0181] For the purposes of the following embodiments, the base device can be a medical device, a base, a bracket, a hub, a pill dispenser, a syringe pump, an infusion pump, a micro pump, a communication module, an ECG monitor, a blood pressure monitor, a pulse oximeter, a carbon dioxide monitor, a communication repeater, etc.

[0182] In another embodiment, a method implemented by a set of operable processor-executable instructions includes: determining whether a monitoring client is connected to a base device through a physical connection; establishing a communication link between the monitoring client and the base device through the physical connection; if necessary, updating interface programs on the monitoring client and the base device through the first communication link; establishing a second communication link between the monitoring client and the base device using the first communication link; and transmitting data from the base device to the monitoring client using the second communication link.

[0183] In another embodiment, the method, implemented by a set of operable processor-executable instructions, is performed when the processor is located on a monitoring client.

[0184] In another embodiment, the method, implemented as a set of operable processor-executable instructions, is performed when the processor is located on a base device.

[0185] In another embodiment, the method implemented by a set of operable processor-executable instructions is performed when the act of transmitting data from the base device to the monitoring client using the second communication link includes transmitting the data to the monitoring client using the second communication link by the base device.

[0186] In another embodiment, the method, implemented by a set of operable processor-executable instructions, is performed when the act of transmitting data from the base device to the monitoring client using the second communication link includes the monitoring client receiving the data using the second communication link.

[0187] In another embodiment, the method, implemented by a set of operable processor-executable instructions, further comprises displaying data on the monitoring client based on the data transmitted from the base device.

[0188] In another embodiment, the method, implemented by a set of operable processor-executable instructions, further comprises: initiating treatment of the patient using the monitoring client.

[0189] In another embodiment, the method implemented by a set of processor-executable instructions operable to initiate treatment of a patient using a monitoring client also includes treating the patient using a base unit.

[0190] In another embodiment, the method implemented by a set of processor-executable instructions operable to initiate treatment of a patient using a monitoring client also includes treating the patient using a hemodialysis system as a base unit.

[0191] In another embodiment, the method implemented by a set of operable processor-executable instructions further includes: the monitoring client sending a start therapy signal to the base unit.

[0192] In another embodiment, the method implemented by a set of operable processor-executable instructions further includes removing a physical connection between the monitoring client and the base device.

[0193] In another embodiment, the method implemented by a set of operable processor-executable instructions further includes removing the physical connection between the monitoring client and the base device, and further includes continuing communication between the monitoring client and the base device using a second communication link.

[0194] In another embodiment, the method implemented by a set of operable processor-executable instructions also includes removing the physical connection between the monitoring client and the base device, continuing communication between the monitoring client and the base device using a second communication link, and monitoring a link quality value of the second communication link.

[0195] In another embodiment, the method, implemented by a set of operable processor-executable instructions, further comprises transmitting data between the monitoring client and the base device as long as the link quality value is above a predetermined threshold.

[0196] In another embodiment, the method implemented by a set of operable processor-executable instructions further includes: when the link quality value drops below a first predetermined threshold, causing the monitoring client to enter a headless state.

[0197] In another embodiment, the method implemented by a set of operable processor-executable instructions further includes: when the link quality value drops below a first predetermined threshold, causing the monitoring client to enter a headless state, wherein the monitoring client displays a message on a user interface in response to the headless state.

[0198] In another embodiment, the method implemented by a set of operable processor-executable instructions includes: when the link quality value drops below a first predetermined threshold, causing the monitoring client to enter a headless state, wherein the message instructs the user to move the monitoring client closer to the base device.

[0199] In another embodiment, the method implemented by a set of operable processor-executable instructions, which includes causing the monitoring client to enter a headless state when the link quality value drops below a first predetermined threshold, also includes: periodically determining the corresponding link quality value to determine whether the corresponding link quality value is above the first predetermined threshold.

[0200] In another embodiment, the method implemented by a set of operable processor-executable instructions, which includes causing the monitoring client to enter a headless state when a link quality value drops below a first predetermined threshold, also includes: leaving the headless state when the link quality value is above the first predetermined threshold.

[0201] In another embodiment, the method implemented by a set of operable processor-executable instructions, which includes causing the monitoring client to enter a headless state when the link quality value drops below a first predetermined threshold, also includes: leaving the headless state when the link quality value is above a second predetermined threshold that is greater than the first predetermined threshold.

[0202] In another embodiment, the method implemented by a set of operable processor-executable instructions includes the following steps: if necessary, updating the interface program on the monitoring client through the first communication link, including: transmitting the version number of the interface program from the monitoring client to the basic device through the first communication link; determining whether the interface program on the monitoring client is the latest version; the basic device obtaining an updated version of the interface program from the server; and overwriting the interface program with the updated version of the interface program.

[0203] In another embodiment, the method is implemented by a set of operable processor-executable instructions, wherein the step of establishing a second communication link between the monitoring client and the base device using the first communication link includes: determining whether the base device, if paired with another monitoring client, would interrupt any pairing between the other monitoring client and the base device if necessary; using the base device to generate a configuration file; transmitting the configuration file from the base device to the monitoring client using the first communication link; reading the configuration file received from the base device by the monitoring client; and pairing the base device with the monitoring client for wireless communication, thereby establishing the second communication link between the monitoring client and the base device based on the configuration file.

[0204] In another embodiment, the method implemented by a set of operable processor-executable instructions includes: when a link quality value drops below a predetermined threshold, causing the monitoring client to enter a headless state; suspending data transmission between the base device and the monitoring client; and displaying a message on a graphical user interface requesting a user to move the monitoring client closer to the base device.

[0205] In another embodiment, the method, implemented by a set of operable processor-executable instructions, includes: placing the base device into a headless state when a link quality value drops below a predetermined threshold; pausing data transfer between the base device and the monitoring client; and indicating that the base device has entered the headless state.

[0206] In another embodiment, the method, implemented by a set of operable processor-executable instructions configured for execution by a processor, includes: transmitting data between the monitoring client and the base device as long as a link quality value is above a predetermined threshold; entering a headless state if the link quality value drops below the predetermined threshold; remaining in the headless state as long as the link quality value remains below the predetermined threshold; determining whether the link quality value returns above the predetermined threshold; and exiting the headless state if the link quality value has returned above the predetermined threshold.

[0207] In another embodiment, the method, implemented by a set of operable processor-executable instructions configured for execution by a processor, includes: transmitting data between the monitoring client and the base device as long as the link quality value is above a first predetermined threshold; entering a headless state if the link quality value drops below the first predetermined threshold; remaining in the headless state as long as the link quality value remains below a second predetermined threshold; determining whether the link quality value increases above the second predetermined threshold; and exiting the headless state if the link quality value exceeds the second predetermined threshold.

[0208] In one embodiment of the present disclosure, a system for communicating between a monitoring client and a base device includes: a base device having a communication component, wherein the communication component is configured to: transmit data between the monitoring client and the base device as long as a link quality value is above a predetermined threshold; enter a headless state if the link quality value drops below the predetermined threshold; remain in the headless state as long as the link quality value remains below the predetermined threshold; determine whether the link quality value returns to above the predetermined threshold; and exit the headless state if the link quality value has returned to above the predetermined threshold.

[0209] In one embodiment of the present disclosure, a system for communicating between a monitoring client and a base device includes a base device having a communication component, wherein the communication component is configured to: transmit data between the monitoring client and the base device as long as a link quality value is above a first predetermined threshold; enter a headless state if the link quality value drops below the first predetermined threshold; remain in the headless state as long as the link quality value remains below a second predetermined threshold; determine whether the link quality value increases above the second predetermined threshold; and exit the headless state if the link quality value exceeds the second predetermined threshold.

[0210] In one embodiment of the present disclosure, a system for communication between a monitoring client and a base device includes a base device having an update component, wherein the update component is configured to: determine whether the monitoring client is connected to the base device through a physical connection; establish a first communication link between the monitoring client and the base device through the physical connection; if necessary, update interface programs on the monitoring client and the base device through the first communication link; establish a second communication link between the monitoring client and the base device using the first communication link; and transmit data from the base device to the monitoring client using the second communication link.

[0211] In one embodiment of the present disclosure, the base device is one of the following: a medical device, a base, a stand, a hub, a pill dispenser, a syringe pump, an infusion pump, a micro pump, a communication module, an ECG monitor, a blood pressure monitor, a pulse oximeter, a carbon dioxide monitor, and a communication repeater.

[0212] In one embodiment of the present disclosure, the updating component is executed in a sandbox. In some embodiments, the sandbox can be located in at least one of the hub, the base, and the bracket.

[0213] In one embodiment of the present invention, a system enabling electronic patient care includes a monitoring client connected to a base device via a physical connection, at least one of the monitoring client and the base device having a processor configured to at least one of: establish a first communication link between the monitoring client and the base device via the physical connection; update interface programs on the monitoring client and the base device via the first communication link; and establish a second communication link between the monitoring client and the base device, the second communication link utilizing the first communication link.

[0214] In one embodiment of the present disclosure, the processor is located on the monitoring client. In one embodiment of the present disclosure, the processor is located on the base device. In one embodiment of the present disclosure, the second communication link transmits data from the base device to the monitoring client. In one embodiment of the present disclosure, the monitoring client receives the data using the second communication link. In one embodiment of the present disclosure, the monitoring client is configured to display the data transmitted from the base device. In one embodiment of the present disclosure, the monitoring client is configured to initiate treatment for a patient. In one embodiment of the present disclosure, the base device is configured to treat a patient. In one embodiment of the present disclosure, the base device is a hemodialysis system.

[0215] In one embodiment of the present disclosure, the basic device is a patient care device. In one embodiment of the present disclosure, the patient care device is selected from the group consisting of: an infusion pump, a pill dispenser, a micro pump, an ECG monitor, a blood pressure monitor, a pulse oximeter and a carbon dioxide monitor, an intravenous bag, and a drip flow meter.

[0216] In one embodiment of the present disclosure, the system further comprises a monitoring client configured to send a start treatment signal to the base unit. In one embodiment of the present disclosure, the communication link between the monitoring client and the base unit is wireless. In one embodiment of the present disclosure, the base unit is configured to monitor a link quality value of the second communication link. In one embodiment of the present disclosure, the system is configured to transmit data between the monitoring client and the base unit as long as the link quality value is above a predetermined threshold.

[0217] In one embodiment of the present disclosure, the monitoring client is configured to enter a headless state when a link quality value falls below a first predetermined threshold. In one embodiment of the present disclosure, the monitoring client is configured to display a message on a user interface in response to the headless state. In one embodiment of the present disclosure, the message instructs a user to move the monitoring client closer to the base device. In one embodiment of the present disclosure, the base device is configured to periodically determine the corresponding link quality value to determine whether the corresponding link quality value is above the first predetermined threshold.

[0218] In one embodiment of the present disclosure, the infrastructure device is configured to leave the headless state when the link quality value is higher than a first predetermined threshold. In one embodiment of the present disclosure, the infrastructure device is configured to leave the headless state when the link quality value is higher than a second predetermined threshold that is greater than the first predetermined threshold.

[0219] In one embodiment of the present disclosure, at least one of the monitoring client and the basic device is configured to update at least the interface program through a first communication link, so that at least one of the following items is performed: the monitoring client is configured to transmit the version number of the interface program to the basic device through the first communication link; the monitoring client is further configured to determine whether the interface program on the monitoring client is the latest version; the basic device is configured to obtain an updated version of the interface program from the server; and the basic device is further configured to overwrite the interface program with the updated version of the interface program.

[0220] In one embodiment of the present disclosure, the system is configured to establish a second communication link between a monitoring client and a base device using the first communication link, so that at least one of the following items is performed: the processor is configured to determine whether the base device is paired with another monitoring client; the processor is further configured to interrupt any pairing between the other monitoring client and the base device when necessary; the base device is configured to generate a configuration file; the first communication link is configured to transmit the configuration file from the base device to the monitoring client; the monitoring client is configured to read the configuration file received from the base device; and the base device is paired to the monitoring client for wireless communication, and the base device is paired to the monitoring client for wireless communication so as to establish a second communication link between the monitoring client and the base device according to the configuration file.

[0221] In yet another embodiment, a tablet computer includes one or more processors and a memory having a set of processor-executable instructions operable to cause the one or more processors to: determine whether the tablet computer is connected to a base device via a physical connection; establish a first communication link between the tablet computer and the base device via the physical connection; if necessary, update an interface program on the tablet computer via the first communication link; establish a second communication link between the tablet computer and the base device using the first communication link; and transmit data from the base device to the tablet computer using the second communication link.

[0222] The tablet computer can be configured to: (1) monitor the operation of the base device; (2) control the operation of the base device; (3) receive error conditions from the base device; (4) monitor the operation of the base device to determine whether any error conditions exist; (5) monitor the operation of the base device to determine whether an unsafe condition exists; (6) store errors or operating parameters for transmission to a server; (7) store errors or operating parameters for transmission to the base device for storage in the base device; (8) store errors or operating parameters for transmission to the base device for relay to a server; and / or (9) provide patient entertainment selected from the group consisting of: video games, movies, pre-recorded songs, and web browsing while the patient receives treatment. BRIEF DESCRIPTION OF THE DRAWINGS

[0223] These and other aspects will become more apparent from the following detailed description of various embodiments of the present disclosure, which proceeds with reference to the accompanying drawings, in which:

[0224] Figure 1 is a block diagram of an electronic patient care system having two docks according to one embodiment of the present disclosure;

[0225] Figure 2 is a diagram illustrating a method for Figure 1 A flowchart of a method for maintaining communication between a monitoring client and a patient-care device;

[0226] Figure 3 is a block diagram of an electronic patient-care system having two bases for wireless communication therebetween according to another embodiment of the present disclosure;

[0227] Figure 4 is a diagram illustrating a method for Figure 3 A flowchart of a method for maintaining communication between a monitoring client and a patient-care device;

[0228] Figure 5 is a block diagram of an electronic patient-care system having a base for docking a monitoring client and a patient-care device together according to yet another embodiment of the present disclosure;

[0229] Figure 6 According to one embodiment of the present disclosure, Figure 5 A flowchart of a method for maintaining communication between a monitoring client and a patient-care device;

[0230] Figure 7 is a block diagram of an electronic patient-care system having a monitoring client with an integrated base for docking a patient-care device therewith according to yet another embodiment of the present disclosure;

[0231] Figure 8 is a block diagram of an electronic patient care system having a hub according to yet another embodiment of the present disclosure;

[0232] Figure 9 is a block diagram of an electronic patient-care system having a stackable monitoring client and a stackable patient-care device according to another embodiment of the present disclosure;

[0233] Figure 10 is a flowchart of a method for transmitting patient care parameters of a patient care device to a monitoring server according to one embodiment of the present disclosure;

[0234] Figure 11 is a flowchart of a method for aggregating patient care parameters of a plurality of patients in a monitoring server according to one embodiment of the present disclosure;

[0235] Figure 12 is a flowchart of a method of restoring a patient care device when operation of the patient care device is interrupted according to one embodiment of the present disclosure;

[0236] Figure 13 is a flow chart of a method for pairing a monitoring client with a patient-care device according to one embodiment of the present disclosure;

[0237] Figure 14 is a flow chart of a method for monitoring operation of a patient-care device using a wearable system paired with a patient-care device according to one embodiment of the present disclosure;

[0238] Figure 15 is a flowchart of a method for displaying a user interface using a user interface template according to an embodiment of the present disclosure;

[0239] Figure 16 is a flowchart of a method for downloading an application for controlling a patient care device according to one embodiment of the present disclosure;

[0240] Figure 17 is a flow chart of a method for ensuring data integrity when transmitting data for a patient-care device according to one embodiment of the present disclosure;

[0241] Figure 18 is a block diagram of an electronic patient care system according to yet another embodiment of the present disclosure;

[0242] Figure 19 is a block diagram of an electronic patient care system according to another embodiment of the present disclosure;

[0243] Figure 20 According to one embodiment of the present disclosure Figure 19A block diagram of a base of an electronic patient care system;

[0244] Figure 21 An electronic patient-care system having a tablet computer docked into a base having a cable electrically coupled to a patient-care device is shown according to one embodiment of the present disclosure;

[0245] Figure 22 An electronic patient-care system having a tablet computer docked into a base for wireless communication with a patient-care device is shown according to one embodiment of the present disclosure;

[0246] Figure 23 An electronic patient-care system having a modular infusion pump docked to a base having a monitoring client having a retractable user interface is shown according to one embodiment of the present disclosure;

[0247] Figure 24 An embodiment according to the present disclosure is shown Figure 23 A side view of the electronic patient care system;

[0248] Figure 25 An electronic patient-care system according to another embodiment of the present disclosure is shown having modular infusion pumps docked to a base having a monitoring client having a retractable user interface, the infusion pumps being arranged in a staggered manner;

[0249] Figure 26 An electronic patient-care system according to yet another embodiment of the present disclosure is shown, the electronic patient-care system having modular infusion pumps docked into a base along a common horizontal plane, and the base including a monitoring client having a retractable user interface;

[0250] Figure 27 Another embodiment according to the present disclosure is shown Figure 26 A side view of the electronic patient care system;

[0251] Figure 28 An electronic patient-care system according to another embodiment of the present disclosure is shown, the electronic patient-care system having a hub coupled to a scanner and a base, the electronic patient-care system further comprising modular infusion pumps docked into the base along a common horizontal plane, and the base including a monitoring client having a retractable user interface;

[0252] Figure 29 Another embodiment according to the present disclosure is shown Figure 28 A side view of the electronic patient care system;

[0253] Figure 30-32 Several views showing a clutch system for mounting an electronic patient care system on a pole according to one embodiment of the present disclosure;

[0254] Figure 33 shows an infusion pump and base coupled to a pole according to one embodiment of the present disclosure;

[0255] Figure 34 An infusion pump and an open connector are shown, to which another infusion pump is coupled, according to one embodiment of the present disclosure.

[0256] Figure 35 An embodiment according to the present disclosure is shown Figure 33 an infusion pump, wherein two additional infusion pumps are each coupled to a corresponding open connector;

[0257] Figure 36 An embodiment according to the present disclosure is shown Figures 33-35 A top view of one of the infusion pumps and the hub;

[0258] Figure 37 shows a square hub with several connectors according to one embodiment of the present disclosure;

[0259] Figure 38 An electronic patient-care system having a hub coupled to a pole is shown according to another embodiment of the present disclosure;

[0260] Figure 39 An electronic patient-care system according to another embodiment of the present disclosure is shown having a hub coupled to a pole and a portable base including a quick-release handle to detach the portable base from the hub;

[0261] Figure 40 An electronic patient-care system according to another embodiment of the present disclosure is shown having a hub coupled to a pole and a base coupled to the hub;

[0262] Figure 41 An electronic patient-care system having a hub coupled to a pole is shown according to another embodiment of the present disclosure;

[0263] Figure 42 An electronic patient-care system having a monitoring client coupled to a hub having a slot for receiving a patient-care device is shown according to another embodiment of the present disclosure;

[0264] Figure 43 Another embodiment of the present disclosure is shown. Figure 42A close-up view of the T-connector of the hub's notch connection is shown;

[0265] Figure 44 An electronic patient-care system having a stackable patient-care device and a stackable container for receiving an infusion bag is shown according to another embodiment of the present disclosure;

[0266] Figure 45 An electronic patient-care system according to another embodiment of the present disclosure is shown having a plurality of stackable patient-care devices that are stackable next to another stack of patient-care devices;

[0267] Figure 46 An electronic patient care system having a stackable patient care device having a syringe pump patient care device having a single syringe is shown according to another embodiment of the present disclosure;

[0268] Figure 47 An electronic patient care system having a stackable patient care device having a syringe pump patient care device having two syringes is shown according to another embodiment of the present disclosure;

[0269] Figure 48 An electronic patient-care system having stackable patient-care devices, each having a display, is shown according to another embodiment of the present disclosure;

[0270] Figure 49 According to another embodiment of the present disclosure Figure 48 A close-up view of the handle of an electronic patient care device;

[0271] Figure 50 is a close-up view of an infusion line port according to another embodiment of the present disclosure, showing the infusion line port passing through Figure 48 infusion lines for electronic patient care system setups;

[0272] Figure 51 Another embodiment of an electronic patient-care system according to another embodiment of the present disclosure is shown, illustrating removal of a stackable patient-care device;

[0273] Figure 52 shows an electronic patient-care system prepared for transport according to another embodiment of the present disclosure;

[0274] Figure 53An electronic patient care system with stackable patient care devices according to another embodiment of the present disclosure is shown;

[0275] Figure 54 An electronic patient-care system having stackable patient-care devices that can be stacked from bottom to top is shown according to another embodiment of the present disclosure;

[0276] Figure 55 An electronic patient-care system according to another embodiment of the present disclosure is shown, the electronic patient-care system being coupled to a pole and having stackable patient-care devices that can be stacked from top to bottom;

[0277] Figure 56 showing a perspective view of a clutch system having a release handle for frictionally gripping to a lever according to another embodiment of the present disclosure;

[0278] Figure 57 Another embodiment according to the present disclosure is shown Figure 56 A rear view of the clutch system showing the transparent back;

[0279] Figure 58 Another embodiment according to the present disclosure is shown Figure 56 A top cross-sectional view of a clutch system;

[0280] Figure 59 is a block diagram of a system for controlling an infusion pump according to one embodiment of the present disclosure;

[0281] Figure 60 is a block diagram of an electronic patient-care system having a hub for communicating with a plurality of electronic patient-care devices according to one embodiment of the present disclosure;

[0282] Figure 61 is a block diagram of an electronic patient-care system having a dock that can be connected to a patient-care device via a USB connection according to one embodiment of the present disclosure;

[0283] Figure 62 is a process diagram illustrating several stages of electronic patient care according to one embodiment of the present disclosure;

[0284] Figures 63-66 Several arrangements of an electronic patient care system according to one embodiment of the present disclosure are shown;

[0285] Figure 67 A timing diagram illustrating electronic patient care therapy using an infusion pump according to one embodiment of the present disclosure;

[0286] Figures 68A-68BA flowchart showing a method according to an embodiment of the present disclosure is shown for illustrating Figure 67 Timing diagram of

[0287] Figures 69-70 shows another arrangement of an electronic patient care system according to one embodiment of the present disclosure;

[0288] Figure 71 A timing diagram illustrating electronic patient care therapy using an infusion pump according to one embodiment of the present disclosure;

[0289] Figures 72A-72B A flowchart showing a method according to an embodiment of the present disclosure is shown for illustrating Figure 71 Timing diagram of

[0290] Figure 73 Another timing diagram illustrating electronic patient care therapy using an infusion pump according to one embodiment of the present disclosure;

[0291] Figure 74 A flowchart showing a method according to an embodiment of the present disclosure is shown for illustrating Figure 73 Timing diagram of

[0292] Figure 75 Yet another timing diagram illustrating an electronic patient care system treatment using an infusion pump according to another embodiment of the present disclosure;

[0293] Figure 76 A flowchart showing a method according to an embodiment of the present disclosure is shown for illustrating Figure 75 Timing diagram of

[0294] Figures 77-78 Several arrangements of an electronic patient care system according to one embodiment of the present disclosure are shown;

[0295] Figure 79 another timing diagram illustrating electronic patient care therapy using an infusion pump according to another embodiment of the present disclosure;

[0296] Figures 80A-80B A flowchart showing a method according to an embodiment of the present disclosure is shown for illustrating Figure 79 Timing diagram in ;

[0297] Figure 81 another timing diagram illustrating electronic patient care therapy using an infusion pump according to another embodiment of the present disclosure;

[0298] Figures 82A-82B A flowchart showing a method according to an embodiment of the present disclosure is shown for illustrating Figure 81 Timing diagram in ;

[0299] Figures 83-89 Several additional embodiments of electronic patient care systems according to several embodiments of the present disclosure are shown;

[0300] Figure 90 A block diagram illustrating circuitry of an embodiment of a hub according to one embodiment of the present disclosure;

[0301] Figure 91 A block diagram illustrating a circuit for interfacing with an infusion pump according to one embodiment of the present disclosure;

[0302] Figure 92 Another embodiment of an electronic patient-care system having a plurality of patient-care devices docked in a base in vertical alignment according to one embodiment of the present disclosure is shown;

[0303] Figure 93 A block diagram illustrating circuitry of an embodiment of a hub according to one embodiment of the present disclosure;

[0304] Figure 94 A block diagram illustrating a circuit of a communication module according to one embodiment of the present disclosure;

[0305] Figures 95-98 Several embodiments of an electronic patient-care system having an infusion pump coupled to a communication module are shown according to several embodiments of the present disclosure;

[0306] Figures 99-101 Several block diagrams illustrating circuitry of a base according to several embodiments of the present disclosure;

[0307] Figure 102 A block diagram illustrating a battery pack according to one embodiment of the present disclosure;

[0308] Figures 103-104 shows further embodiments of circuitry of a base according to further embodiments of the present disclosure;

[0309] Figures 105-116 shows several embodiments of an attachable pump attached to a monitoring client according to further embodiments of the present disclosure;

[0310] Figure 117 A backplane for use with an infusion pump according to one embodiment of the present disclosure is shown;

[0311] Figure 118 An embodiment according to the present disclosure is shown Figure 117 A cross-sectional view of a back panel;

[0312] Figures 119-120 shows several embodiments of an attachable pump attached to a monitoring client according to further embodiments of the present disclosure;

[0313] Figure 121 A communication module according to an embodiment of the present disclosure is shown;

[0314] Figure 122 shows a communication module attached to a patient monitoring device according to one embodiment of the present disclosure;

[0315] Figure 123 An embodiment according to the present disclosure is shown Figure 121 A circuit diagram of a communication module;

[0316] Figure 124 A diagram showing a circuit for converting near field communication to UHF according to one embodiment of the present disclosure;

[0317] Figures 125-127 Several antennas according to further embodiments of the present invention are shown;

[0318] Figure 128 A patient wristband according to one embodiment of the present disclosure is shown, having an RFID tag attached thereto;

[0319] Figure 129 According to one embodiment of the present disclosure, Figure 128 The split-ring resonator used on the wristband;

[0320] Figure 130 shows a near-field antenna according to one embodiment of the present disclosure;

[0321] Figure 131 An embodiment according to the present disclosure is shown Figure 130 The equivalent circuit of the open resonator;

[0322] Figure 132 shows a checklist of 5 Rs (correct) that may be displayed on a monitoring client according to one embodiment of the present disclosure;

[0323] Figure 133 FIG. 1 shows an occlusion situation list that can be displayed on a monitoring client according to an embodiment of the present disclosure;

[0324] Figure 134 A display screen illustrating a monitoring client in operable communication with several infusion pumps according to one embodiment of the present disclosure;

[0325] Figure 135 is an illustration of a display screen on a portable monitoring client of a health care provider showing a list of patients whose information the provider can access according to one embodiment of the present disclosure;

[0326] Figure 136is an illustration of a display screen on a healthcare provider's portable monitoring client showing a device associated with a particular patient with current data from the device and one-touch access to a portion of the patient's medical information in accordance with one embodiment of the present disclosure;

[0327] Figure 137 is an illustration of a display screen on a healthcare provider's portable monitoring client showing data entry fields for a medication prescription for use with an IV infusion pump according to one embodiment of the present disclosure;

[0328] Figure 138 is an illustration of a display screen on a portable monitoring client of a healthcare provider showing a risk prediction and a suggested course of action associated with a prescribed medication generated by the monitoring client in accordance with one embodiment of the present disclosure;

[0329] Figure 139 is an illustration of a display screen on a portable monitoring client of a health care provider showing a medication prescription ready for submission by a prescribing provider according to one embodiment of the present disclosure;

[0330] Figure 140 is an illustration of a display screen on a portable monitoring client of a healthcare provider showing how a monitoring system according to one embodiment of the present disclosure may display to a prescribing provider confirmation that the prescription has been sent to a pharmacist;

[0331] Figure 141 A perspective view showing a micro pump coupled to an adapter according to one embodiment of the present disclosure;

[0332] Figure 142 shows a perspective view of a wireless hub device that wirelessly relays data from a patient-care device to a monitoring client, another hub, or a base station in accordance with one embodiment of the present disclosure;

[0333] Figure 143 shows a front perspective view of an electronic patient-care system having a plurality of modular patient-care devices coupled to a monitoring client via an adapter and a base, according to one embodiment of the present disclosure;

[0334] Figure 144 An embodiment according to the present disclosure is shown Figure 143 A side perspective view of an electronic patient care system;

[0335] Figure 145 An embodiment according to the present disclosure is shown Figure 143 a close-up perspective view of an interface of one of the patient care devices shown;

[0336] Figure 146An embodiment according to the present disclosure is shown Figure 143 Top view of the electronic patient care system;

[0337] Figure 147 A diagram illustrating a system for an electronic patient care system according to one embodiment of the present disclosure;

[0338] Figure 148 A block diagram illustrating an electronic patient care system according to one embodiment of the present disclosure;

[0339] Figure 149 An embodiment according to the present disclosure is shown Figure 147 and / or Figure 148 Block diagram of the beside portion of the electronic patient care system

[0340] Figure 150 An embodiment according to the present disclosure is shown Figure 147 、 148 and / or a block diagram of a base / hub of 149;

[0341] Figure 151 is a diagram illustrating an embodiment according to the present disclosure Figure 148 and / or a block diagram of an infusion pump circuit of 149;

[0342] Figure 152 is a block diagram illustrating sensors coupled to various structures of an infusion pump according to one embodiment of the present disclosure;

[0343] Figures 153A-153B shows a flow chart illustrating a method for communication between a tablet computer and a base device according to one embodiment of the present disclosure;

[0344] Figure 154 is a flowchart illustrating a method for updating an interface program according to one embodiment of the present disclosure;

[0345] Figure 155 is a flow chart illustrating a method for establishing a second communication link between a tablet computer and a base device according to one embodiment of the present disclosure;

[0346] Figure 156 is a flowchart illustrating a method of transmitting data between a tablet computer and a base device as long as a link quality value of a second communication link is greater than a threshold value according to one embodiment of the present disclosure; and

[0347] Figure 157 is a flowchart illustrating a method of entering a headless state if a link quality value drops below a threshold according to one embodiment of the present disclosure. DETAILED DESCRIPTION

[0348] Disclosed is a technology for facilitating patient care. According to an exemplary embodiment, the technology can be implemented in, for example, a system having one or more patient care devices that are communicatively coupled to a monitoring client. The patient care devices can include any number of different functions and / or can be produced by different manufacturers. In one such case, a communication interface between a client monitoring station and the various patient care devices allows discovery and protocol conversion as well as various other functions, such as power supply, compliance, and user interface, to name a few. The patient care device can be an infusion pump, a micropump, an insulin pump, a syringe pump, a pill dispenser, a dialysis machine, a ventilator, an ultrasound, an electrocardiogram monitor, a blood pressure monitor, a pulse oximeter, a carbon dioxide monitor, a drip counter, a flowmeter, an optical Doppler device, a heart rate monitor, an IV bag, a hemodialysis machine, a peritoneal dialysis machine, an intestinal dialysis machine, a patient thermometer, and / or other bedside patient care devices. The entire contents of all of the following applications are hereby incorporated by reference: U.S. Patent Application No. 11 / 704,899, filed February 9, 2007, and entitled Fluid Delivery Systems and Methods, now U.S. Publication No. US-2007-0228071-A1, published October 4, 2007 (Attorney Docket No. E70); U.S. Patent Application No. 11 / 704,896, filed February 9, 2007, and entitled Pumping Fluid Delivery Systems and Methods Using Force Application Assembly, now U.S. Publication No. US-2007-0219496, published September 20, 2007 (Attorney Docket E71); U.S. Patent Application No. 11 / 704,886, filed February 9, 2007, and entitled Patch-Sized Fluid Delivery Systems and Methods, now U.S. Publication No. US-2007-0219481 (Attorney Docket No. E72); U.S. Patent Application No. 11 / 704,897, filed February 9, 2007, and entitled Adhesive and Peripheral Systems and Methods for Medical Devices, now U.S. Publication No. US-2007-0219597 (Attorney Docket No. E73), published September 20, 2007; U.S. Patent Application No.12 / 347,985, filed December 31, 2008, and entitled Infusion Pump Assembly, now U.S. Publication No. US-2009-0299277, published December 3, 2009 (Attorney Docket No. G75); U.S. Patent Application No. 12 / 347,982, filed December 31, 2008, and entitled Wearable Pump Assembly, now U.S. Publication No. US-2009-0281497, published November 12, 2009 (Attorney Docket No. G76); U.S. Patent Application No. 12 / 347,981, filed December 31, 2008, and entitled Infusion Pump Assembly, now U.S. Publication No. US-2009-0275896, published November 5, 2009 (Attorney Docket No. G77); U.S. Patent Application No. 12 / 347,984, filed December 31, 2008, and entitled Pump Assembly With Switch, now U.S. Publication No. US-2009-0299289, published December 3, 2009 (Attorney Docket No. G79); U.S. Patent Application No. 12 / 249,882, filed October 10, 2008, and entitled Infusion Pump Assembly, now U.S. Publication No. US-2010-0094222, published April 15, 2010 (Attorney Docket No. F51); U.S. Patent Application No. 12 / 249,636, filed October 10, 2008, and entitled System and Method for Administering an Infusible Fluid, now U.S. Publication No. US-2010-0094261, published April 15, 2010 (Attorney Docket No. F52); U.S. Patent Application No. 12 / 249,621, filed October 10, 2008, and entitled Occlusion Detection System and Method, now U.S. Publication No. US-2010-0090843, published April 15, 2010 (Attorney Docket No. F53); U.S. Patent Application No. 12 / 249,600, filed October 10, 2008, and entitled Multi-Language / Multi-Processor Infusion Pump Assembly, now U.S. Publication No.US-2010-0094221 (Attorney Docket No. F54); U.S. Patent No. 8,066,672, issued November 29, 2011, entitled "An Infusion Pump Assembly with a Backup Power Supply" (Attorney Docket No. F55); U.S. Patent No. 8,016,789, issued December 13, 2011, entitled "Pump Assembly with a Removable Cover Assembly" (Attorney Docket No. F56); and U.S. Patent No. 7,306,578, issued December 11, 2007, entitled "Loading Mechanism for Infusion Pump" (Attorney Docket No. C54). This technology can be used to enable seamless communication and fail-safe operation. Numerous other features, functions, and applications will become apparent based on this disclosure.

[0349] General Overview

[0350] As mentioned above, the process of providing comprehensive patient care, such as prescribing and delivering medications, is associated with several significant issues. For example, there is a high risk of critical information not being transmitted correctly, treatment decisions being made without ready access to complete information, and / or delays in implementing prescriptions due to unnecessary duplication and inefficient processes.

[0351] More specifically, medical errors can lead to hundreds of thousands of deaths and harm tens of thousands, or even millions, of people each year in the United States alone. Hospitals under financial pressure may experience an increased incidence of medication errors. The medications associated with the most dangerous errors include insulin, anesthetics, heparin, and chemotherapy drugs. Sources of medication errors include taking the wrong medication, taking the wrong concentration, delivering the medication at the wrong ratio, or delivering the medication via the wrong route (medications can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, to the eye or ear, intrathecally, intraperitoneally, or even intravesically). Even with correct prescribing and labeling, medications can still be taken incorrectly due to poor handwriting, miscommunication of prescribed medications, and mispronunciation of medications with similar names. The trend toward using electronic medical records (EMRs) and barcode systems for medications has been shown to reduce the incidence of medication errors. For example, EMR systems can facilitate computerized physician order entry (CPOE) and flag prescriptions that do not match a 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 the process of prescribing, preparing, and taking medications.

[0352] Furthermore, a significant portion (e.g., up to one-third) of all medication errors resulting in significant harm involve medication infusion devices such as infusion pumps. The wrong medication may be administered, incorrect parameters (e.g., drug concentration or infusion rate) may be entered, or existing infusion parameters may be incorrectly altered. Almost half of all deaths associated with infusion pumps are due to user error, and the majority of these errors are likely due to errors in the programming of the infusion pump.

[0353] Effective monitoring systems can monitor and regulate at any stage of the medication prescribing and administration process to help minimize any of the many adverse events that may result from treatment. The medication treatment process can be conceptually divided into three phases: the prescription phase, the medication preparation phase, and the medication administration phase. Errors can occur when writing or entering medication prescriptions, when medications are retrieved for use or mixed in solution, or when medications are administered to patients.

[0354] Therefore, according to one embodiment of the present disclosure, an electronic patient-care system is disclosed, comprising: a monitoring client configured to transmit at least one patient-care parameter; a patient-care device configured to transmit the 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 discovering the presence of the at least one patient-care device and converting communication signals 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 may be implemented by a communication module described below. The communication interface may further be configured to discover the presence of additional patient-care devices that differ from one another (e.g., by different manufacturer, functionality, and / or communication protocol) and convert communication signals from those devices into a communication protocol associated with the monitoring client or a hub. Thus, the communication interface allows a monitoring client, such as a tablet computer, to effectively serve as a common, universal user interface that healthcare providers can use when providing treatment to patients associated with the monitoring client. One or more databases accessible to the monitoring client allow for centralized storage of patient information (in any format and database structure desired by the healthcare facility or database maintainer) and for downloading information that can be used by healthcare providers in treating patients associated with the monitoring client. The communication interface can be implemented in a variety of ways using wired and / or wireless technologies and allows seamless communication and fail-safe operation of multiple patient care devices. Some patient care devices, hubs, bases and / or monitoring clients can communicate simultaneously over two or more communication links and / or simultaneously over two channels (in some embodiments, the data may be redundant). In some embodiments, the communication module can allow the patient care device to be used portably, for example, by including a battery and sufficient circuitry for mobile operation of a patient care device such as an infusion pump. Additionally or alternatively, the patient wristband can include a battery that can be inserted into the communication module to power the patient care device (or in some embodiments, it can be inserted directly into the patient care device). The communication module can be recharged wirelessly.

[0355] In some embodiments, data such as patient care parameters (in some embodiments, for example, real-time parameters) may be sent to a cloud server for storage and may be stripped of identifying information.

[0356] System Architecture

[0357] like Figure 1As shown, the electronic patient care system 100 includes: one or more monitoring clients 1, 4, each of which can be assigned to an independent patient 2 and physically close to the patient; and a remote monitoring server 3 for uploading information from the multiple various monitoring clients 1, 4 and for downloading information and instructions from various sources to the monitoring clients 1, 4. When in the patient's room, the health care provider can directly interact with the monitoring client 1 to obtain information about the patient 2 or enter commands related to the patient 2. Multiple monitoring clients 1 can interact with a single monitoring server 3. The monitoring server 3 may include middleware (e.g., Figure 1 Additionally or alternatively, providers at remote locations (e.g., a doctor's office, a nurse's station 5, a hospital pharmacy 6, etc.) may interact with individual monitoring clients 1 through a communication link with the monitoring server 3 or directly via a hospital local area network with each monitoring client 1, 4 as a node.

[0358] The remote communicator 11, other monitoring client 4, nurse station 5, or doctor's office can enter a prescription, which is sent to update the patient's personal EHR 19 or sent to the pharmacy 6 for filling. The prescription can be for a pill, for an infusion of fluid, or for other treatment. The prescription can be for infusion of fluid using the infusion pump 7, syringe pump 126, or micropump 130, or for dispensing pills using the pill dispenser 128.

[0359] The pharmacy 6 may include one or more computers connected to a network (e.g., the Internet) to receive a prescription and queue the prescription within the one or more computers. The pharmacy may use the prescription to: (1) mix the medication (e.g., using an automated mixing device connected to the one or more computers that can mix fluids or produce pills; or manually by a pharmacist observing a queue at the one or more computers); (2) prefill the fluid reservoir of the syringe pump 126; (3) program the syringe pump 126 (e.g., program a treatment regimen into the syringe pump 126); (4) prefill the micropump 130; (5) program the micropump 130; (6) prefill the IV bag 170; (7) program the infusion pump 7; (8) prefill the pill dispenser 128; (9) or program the pill dispenser 128 at the pharmacy according to the prescription. The automated mixing device can automatically fill one or more of the syringe pump 126, IV bag 170, or micropump 130 with fluid, and / or can automatically fill the pill dispenser 128 with pills. The automated mixing device can generate a barcode, RFID tag, and / or data. The information in the barcode, RFID tag, and / or data can include treatment plans, prescriptions, and / or patient information.

[0360] The automated mixing device can: (1) attach a bar code to the infusion pump 7, syringe pump 126, micro pump 130, pill dispenser 128, or IV bag 170; (2) attach an RFID tag to the infusion pump 7, syringe pump 126, micro pump 130, pill dispenser 128, or IV bag 170; and / or (3) use the information or data to program an RFID tag or memory within the infusion pump 7, syringe pump 126, micro pump 130, pill dispenser 128, or IV bag 170. The data or information can be sent to a database (e.g., the patient's EHR 19 or the patient's personal EHR 19'), which associates the prescription with the infusion pump 7, syringe pump 126, micro pump 130, pill dispenser 128, or IV bag 170, for example, using the serial number or other identifying information in the bar code, RFID tag, or memory.

[0361] The infusion pump 7, syringe pump 126, micropump 130, or pill dispenser 128 can have a scanner (e.g., an RFID reader or barcode scanner) that determines: (1) whether the syringe pump 126 or IV bag 170 has the correct fluid; (2) whether the micropump 130 has the correct fluid; (3) whether the pill dispenser 128 has the correct pill; (4) whether the therapy programmed into the infusion pump 7, syringe pump 126, micropump 130, or IV bag 170 corresponds to the fluid within the syringe pump 126, micropump 130, or IV bag 170; (5) whether the therapy programmed into the pill dispenser 128 corresponds to the pill within the pill dispenser 128; and / or (6) whether the therapy programmed into the infusion pump 7, syringe pump 126, micropump 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, micropump 130 and / or pill dispenser 128 can read one or more serial numbers from an RFID tag or barcode and ensure that the value matches a value found in internal memory (e.g., a value downloaded via an automated mixing device) or that the value matches a value found in a patient's electronic medical record (e.g., via a patient serial number determined by scanning a patient's RFID tag or scanning a patient barcode stored in the patient's EHR 19 or the patient's personal EHR 19').

[0362] For example, a scanner of the infusion pump 7, syringe pump 126, micro pump 130, or pill dispenser 128 can scan a bar code of another patient care device to obtain the serial number of the patient care device, scan a patient's bar code to determine the patient's serial number, and can query the electronic medical record data to determine whether the serial number of the patient care device corresponds to the patient's serial number stored in the electronic medical record (e.g., the medical record may have been updated by the pharmacy 22 or the pharmacy's automated compounding device).

[0363] Additionally or alternatively, the monitoring client 6 can scan the infusion pump 7, syringe pump 126, pill dispenser 128, micropump 130, or IV bag 170 to determine: (1) whether the syringe pump 126 or IV bag 170 has the correct fluid; (2) whether the micropump 130 has the correct fluid; (3) whether the pill dispenser 128 has the correct pill; (4) whether the therapy programmed into the infusion pump 7, syringe pump 126, micropump 130, or IV bag 170 corresponds to the fluid within the syringe pump 126, micropump 130, or IV bag 170; (5) whether the therapy programmed into the pill dispenser 128 corresponds to the pill within the pill dispenser 128; and / or (6) whether the therapy programmed into the infusion pump 7, syringe pump 126, micropump 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). Additionally or alternatively, the monitoring client 1, infusion pump 7, syringe pump 126, micro pump 130 or pill dispenser 128 may query the electronic medical record database 19 or 19' and / or pharmacy 22, for example, using a bar code serial number on the infusion pump 7, syringe pump 126, micro pump 130, pill dispenser 128 or IV bag 170, to verify the prescription or download the prescription.

[0364] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be configured to send commands or requests to the patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, such as a bolus dose, an infusion flow rate, a total fluid volume to be delivered, a start time for drug delivery, a stop time for drug delivery, or a delivery flow rate profile, to the infusion pump 7, syringe pump 126, and / or micropump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be configured to send commands or requests to the bolus dispenser 7, such as a bolus dispense command for dispensing a bolus, a bolus type, a bolus dispense schedule, and / or a maximum bolus dispense standard. The maximum bolus dispense standard can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications can be obtained on demand (i.e., when necessary); however, excessive medications can be unsafe, and the maximum bolus dispense standard can prevent a patient from obtaining medication at unsafe levels, such as by obtaining a predetermined amount within a predetermined time interval.

[0365] Optionally, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also transmit data back to the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 to: determine whether an alarm or warning should be issued or sent; determine whether a treatment or condition is safe for the patient; determine whether the system 100 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11. For example, the infusion pump 7, syringe pump 126, and / or micropump 130 may optionally transmit to one or more of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 (as appropriate): upstream pressure; change in upstream pressure; pressure downstream of the patient 2; change in pressure downstream of the patient 2; presence of air in the infusion line; actual bolus delivered; actual infusion flow rate; actual total fluid delivered; actual start time of medication delivery; actual stop time of medication delivery; or actual delivery flow rate profile. In another embodiment, the pill dispenser 128 can optionally transmit data back to the monitoring client 1, other monitoring clients 4, and / or remote communicator 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule dispensed, or whether a maximum pill dispensing criteria was exceeded.

[0366] Data received from patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined conditions that trigger alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micropump 130 as an indication of one of the following: excessive coagulation, infiltration, occlusion, or kinking in the tubing leading to the patient; or an occlusion caused downstream by material such as contaminants found within IV bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can provide a visual or audible warning or alarm to the user. These warnings and / or alarms can also notify a nurse to take other appropriate actions, such as providing a recommendation to change the needle when the pressure downstream of the patient rises above a predetermined threshold, or providing a recommendation to check for kinks in the line when the pressure downstream of the patient rises above a predetermined threshold.

[0367] Additionally or alternatively, a sudden drop in pressure downstream of the patient 2 may indicate that the tubing has become detached from the needle and / or that the needle is now out of the patient; and in response, one or more of the monitoring clients 1, 4, 11 may provide a visual or audible warning or alert to the user to reattach the tubing to the needle or insert a new needle to continue the infusion. The warning may also indicate that prompt action is needed, for example, because the patient may be bleeding, such as when the tubing becomes detached from the needle and when the patient is bleeding through an unattached needle coupler.

[0368] In some embodiments, in addition or alternatively, the pressure upstream of one or more infusion pumps 7 can be monitored for any upstream occlusions. For example, contaminants on an IV bag 170 can block the tubing upstream of the infusion pump 7. During each attempt by the infusion pump 7 to pump fluid from the IV bag 170, the pressure upstream of the infusion pump 7 can drop below the pressure that would be present if there were no upstream occlusion. Thus, one or more of the monitoring clients 1, 4, 11 can issue a warning or alarm when the upstream pressure drops below a predetermined threshold and advise or request the caregiver to alleviate the occlusion, for example by replacing the tubing or IV bag 170.

[0369] Optionally, one or more of the monitoring clients 1, 4, 11 can send a command to one or more of the infusion pump 7, syringe pump 126 and / or micropump 130 to stop delivery of fluid in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2.

[0370] like Figure 1 As shown, and as in some embodiments, the system 100 includes a monitoring client base 102 and a device base 104. The monitoring client base 102 is configured to receive a monitoring client 1, and the device base 104 is configured to receive one or more patient care devices to facilitate bedside patient care (as described in more detail below). Although the device base 104 is shown as being capable of receiving several patient care devices, in other embodiments, the device base 104 can receive one patient care device, multiple patient care devices, or any number of patient care devices. In addition, although the monitoring client base 102 is shown as being capable of receiving one monitoring client 1, in other embodiments, the monitoring client base 102 can receive two monitoring clients 1, more than two monitoring clients 1, or any number of monitoring clients 1.

[0371] In this example embodiment, a cable 110 is coupled to both bases 102, 104 to provide a communication link therebetween. The cable 110 may be permanently attached to or attachable to one or both of the bases 102, 104. Additionally or alternatively, the cable 110 may include one or more connectors (not explicitly shown) for plugging the cable into one or both of the bases 102, 104.

[0372] In some embodiments, bases 102 and 104 can communicate with each other using one or more wires and / or waveguides in cable 110. For example, in one embodiment of the present disclosure, cable 110 includes fiber optic waveguides to provide an optical communication link between bases 102 and 104. In other embodiments, as will be understood based on this disclosure, cable 110 can be replaced with one or more wireless communication links (e.g., Bluetooth, etc.) if desired. Still other embodiments may employ a combination of wired and wireless communication channels between bases 102 and 104. Any number of suitable wired connection types may be used in various embodiments.

[0373] In some embodiments, the communication link between the bases 102 and 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. Additionally or alternatively, in some embodiments, the communication link established between the bases 102 and 104 can utilize a wireless connection, a wired connection, a connectionless protocol such as the User Datagram Protocol ("UDP"), or a connection-based protocol such as the Transmission Control Protocol ("TCP"). For example, the communication between the bases 102 and 104 can be based on one or more of the following: 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.

[0374] When the monitoring client 1 is docked to the monitoring client base 102, the monitoring client 1 can access communications between the bases 102 and 104. For example, in some embodiments of the present disclosure, the monitoring client 1 can communicate with circuitry, such as memory, within the device base 104 via a communications link provided by the cable 110. Additionally or alternatively, the monitoring client 1 can communicate with any device docked to the device base 104 via a communications link provided by the cable 110 and / or one or more wireless communications links (described in greater detail below).

[0375] Further references Figure 1In the illustrated example embodiment, device base 104 may include various accessories, each of which is optional, such as an attachable display 134, a camera 136, and a microphone 138. Similarly, monitoring client base 102 may include various accessories, each of which is optional, such as a camera 140 and a microphone 142. Monitoring client 1 may include various accessories, each of which is optional, such as a camera 144 and a microphone 146. Cameras 136, 140, and 144 may be used, for example, by facial recognition software to identify or recognize the presence of a provider (e.g., a nurse, nurse practitioner, doctor, etc.) and / or a patient. Additionally or alternatively, microphones 138, 142, and 146 may be used, for example, by voice recognition software to identify or recognize the presence of a provider and / or a patient. As will be appreciated in light of this disclosure, cameras 136, 140, 144 and microphones 138, 142, and 146 may also be used, for example, to allow a patient to communicate with a remote care provider, and / or to confirm the patient's identity (e.g., using voice and / or facial recognition technology, retinal scans, etc.) before beginning treatment to ensure that the correct patient receives the correct treatment.

[0376] like Figure 1 As shown, in some embodiments, monitoring client 1, monitoring client base 102, and device base 104 each have respective antennas 112, 106, and 108 for wireless communication (each antenna 112, 106, and / or 108 is optional). If cable 110 is unplugged or communication between bases 102, 104 via cable 110 is interrupted or impaired, monitoring client base 102 and device base 104 can continue to communicate with each other using the wireless communication link established via antennas 106, 108. Furthermore, when monitoring client 1 is removed from monitoring client base 102, monitoring client 1 can communicate directly with device base 104, for example, and / or monitoring client 1 can communicate with device base 104 via wireless communication with monitoring client base 102, with monitoring client base 102 relaying the communication via cable 110 or via the wireless communication link between bases 102, 104. As described above, the communication between the monitoring client 1 and the device base 104 may be utilized by the monitoring client 1 to communicate with various devices docked to the device base 104 .

[0377] In some embodiments, monitoring client 1 can electronically determine whether one or more electrical contacts of one or more connectors are electrically engaged with monitoring client base 102 to determine whether cable 110 is available for use as a communication link, for example by measuring a voltage or impedance between two electrical contacts of a connector of monitoring client 1 that is docked to monitoring client base 102 and provides electrical communication between monitoring client base 102 and monitoring client 1. Furthermore, if monitoring client 1 determines that cable 110 is not electrically coupled to cable 110, monitoring client 1 can determine that cable 110 is unavailable. Additionally or alternatively, in some embodiments, a magnet in base 102 engages a Hall effect sensor in monitoring client 1, which monitoring client 1 uses to determine whether it is docked, allowing monitoring client 1 to assume that cable 110 is unavailable for use as a communication link when monitoring client 1 is undocked. Additionally or alternatively, circuitry within monitoring client base 102 can signal monitoring client 1 when the cable is unavailable for use as a communication link. In some embodiments, the monitoring client 1 may periodically "ping" the device base 104 via the cable 110; if the monitoring client does not receive a response from the device base 104 within a predetermined amount of time, the monitoring client 1 will assume that the cable 110 is unavailable as a communication link.

[0378] If the monitoring client 1 determines that the cable 110 is not available as a communication link, the monitoring client 1 may use a speaker and / or a vibration motor to issue a warning or alarm, may send a warning or alarm signal to the remote communicator 11 to warn or alarm the remote communicator using the speaker and / or vibration motor, and / or the monitoring client 1 may attempt to communicate with the patient-care device via other communication links. The term "warning" as used herein is intended to include "soft" warnings, such as warnings that do not attract human attention until a predetermined amount of time has passed and the cause of the warning still exists.

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

[0380] In one embodiment of the present disclosure, each monitoring client 1 is assigned to a specific patient 2 and can be desktop-based, portable, or handheld, and can have a display and user input capabilities. The monitoring client 1 can be portable and facilitate efficient data viewing and input; it can be a notebook PC, netbook PC, tablet PC, or "smartphone" with or without a touchscreen. Additionally or alternatively, in some embodiments, the monitoring client 1 and / or remote communicator 11 can be docked or connected to a cable connected to a larger display, thereby adapting the larger display (e.g., a 24-inch display) to the display of the monitoring client 1 and / or remote communicator 11. The larger display can have input capabilities, such as touchscreen capabilities, stylus input capabilities, keyboard input capabilities, and remote control input capabilities, which are transmitted to the monitoring client 1 and / or remote communicator 11. For example, viewing of X-ray files or patient imaging files can be facilitated by docking the monitoring client 1 and / or remote communicator 11 to a viewing dock connected to a larger display, allowing caregivers to view patient imaging files using the larger display. The viewing base can also charge the monitoring client and / or the remote communicator 11.

[0381] The monitoring client 1 can run a Linux-based operating system, an Android-based operating system, a BlackBerry-based operating system, a tablet-based operating system, iOS, iPad OS, iPhone OS, and the like. A particular monitoring client 1 can be assigned to a particular patient 2 using any of a variety of methods, including (but not limited to) a unique patient identifier encoded on an RFID tag 116 or barcode 114 embedded in a wristband 118. The device base 104 includes a scanner 120 for determining the unique patient identifier from the barcode 114 or RFID tag 116. The scanner 120 can be a laser barcode scanner, a CCD-based barcode scanner, a near-field communicator or reader / writer, an RFID reader, and the like. In other embodiments, the unique patient identifier can be based on the patient's biometric data. In one such example, biometric capabilities (e.g., facial and / or voice recognition, retinal scanning, blood type monitoring, fingerprint scanning, etc.) can be built into or associated with the monitoring client 1. The device base 104 can transmit the unique patient identifier to the monitoring client base 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 treatment of the patient 2.

[0382] The monitoring client 1 may include one or more of a microprocessor, a microcontroller, logic devices, digital circuits, and analog circuits to transceive (e.g., send or receive) information related to a patient's care, condition, illness, or treatment. For example, the monitoring client 1 may send or receive patient care parameters, such as patient condition parameters and / or patient treatment parameters. Some exemplary patient condition parameters include measurements of blood pressure, temperature, heart rate, pulse oximetry, carbon dioxide level, blood oxygen level, patient alertness, patient consciousness, and patient responsiveness. Some exemplary patient treatment parameters include medications to be administered, medication or fluid flow rates, medication administration schedules, or other bedside treatment parameters.

[0383] In some embodiments, for example, the monitoring client 1 can be physically associated with, permanently attached to, attachable to, detachable from, or both attachable and detachable from the infusion pump 7. This can be accomplished through a docking interface between two devices (e.g., the monitoring client base 102 and the device base 104). In one such embodiment, the monitoring client 1 communicates with the pump 7 (or other patient care device) in a variety of ways, including, for example, wirelessly via electrical contacts in the bases 102, 104, via electrical connectors, or via transceivers on each device using respective antennas 112, 122A. Additionally or alternatively, the infusion pump can include pre-programmed therapy data that is uploaded to the monitoring client 1 when the infusion pump 7 becomes in operable communication with the monitoring client 1, indicating a specific therapy for a specific patient.

[0384] Monitoring client 1 can also communicate with one or more databases within facility 8, with databases external to facilities 9 and 10, and / or with healthcare providers (e.g., including physicians, nurses, and pharmacists) using portable communicators 11. This can be accomplished via a wired connection (e.g., a Category 5 LAN connector, USB, wired Ethernet, etc.) to facility server 8 via a connector within the patient's room, or wirelessly 12 (e.g., WiFi, 3G, 4G, EVDO, WiMax, etc.). In one embodiment, access to internal or external facility databases is mediated 13 by monitoring server 3 (e.g., using middleware), which can then centralize software and application programming interfaces for communicating with databases with separate organization, formatting, and communication protocols. Thus, in one embodiment of the present disclosure, any software updates can be largely limited to monitoring server 3, thereby reducing maintenance requirements for individual monitoring clients 1, 4, and 11. Optionally, monitoring client 1 can communicate with a patient treatment device, such as an infusion pump 7, to receive information about treatment progress (e.g., operating parameters) and provide operating instructions to the patient treatment device. In another embodiment, the monitoring client 1 may also communicate with patient care devices used for diagnostic or monitoring purposes to receive patient condition parameters (e.g., an electrocardiogram ("ECG") monitor 14, a blood pressure ("BP") monitor 15, a pulse oximeter or carbon dioxide monitor 16, or other devices such as a temperature monitor, etc.), to receive readout information from these devices, and possibly command these devices 14, 15, 16, 17 to obtain readings when desired by the provider or algorithm.

[0385] In one embodiment of the present disclosure, the facility services 8 and / or the adverse drug event network 9 may also include a medication error reduction system ("DERS"). The DERS system may 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. Soft alarms can be deactivated (e.g., turned off) by a caregiver using the user interface of the infusion pump 7 and / or the monitoring client 1 (and may only be audible and / or vibrating alarms), while hard alarms cause treatment to be stopped until the cause of the hard alarm is resolved.

[0386] In another embodiment of the present disclosure, the DERS system may include a first set of predetermined criteria for defining soft limits and / or a second set of predetermined criteria for defining hard limits. The hard and soft limits define treatment limits, such as drug dosage limits based on size, weight, age, other patient parameters, or other criteria. A caregiver can use the user interface of the infusion pump 7 and / or monitoring client 1 to override these soft limits to start treatment even if the treatment is outside the first set of predetermined criteria, while hard limits prevent treatment from starting until the settings are changed to meet the second set of predetermined criteria for defining the hard limits.

[0387] Can be Figure 1 As further seen in the example embodiment, system 100 also includes communication modules 124A-124K, each of which has a corresponding antenna in antennas 122A-122K. In some embodiments, each communication module 124A-124K is optional, and / or each device may have integrated communication capabilities. Each communication module 124A-124K includes a connector for connecting to a corresponding device. In other embodiments, each communication module 124A-124K is connected to the corresponding device. Figure 1 is shown as being permanently integrated with the device to which it is attached.

[0388] Each communication module 124A-124K optionally includes one or more transceivers for communicating with each other, with the device base 104, with the monitoring client base 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 Figure 8 ) and / or any other device with sufficient wireless communication capabilities. In some specific embodiments, the communication modules 124A-124K may operate as a wireless mesh network using, for example, IEEE 802.14.4, Zigbee, XBee, Wibree, and IEEE 802.11. More generally, any wireless communication protocol may be used to enable communication between the modules 124A-124K and other components of the system 100 (e.g., bases 102 and 104, monitoring clients 1, 4, 11, etc.), such as to allow for device discovery, handshaking, and / or inter-device communication as described herein, regardless of whether in a static topology, a dynamic topology, or an ad hoc topology (to accommodate, for example, the mobility of the monitoring clients 1, 4, 11 and / or the various medical devices associated with the base 104).

[0389] In other embodiments, each patient-care device may not include any modules or may include more than two modules (e.g., communication modules). For example, each module may have a specific function, such as WiFi, and the user may select multiple modules, each with a specific function, and then connect them together. This set of modules can then be applied to a patient-care device, such as an infusion pump. Consider another example: each module may have a primary processor, a backup processor, and functional circuitry that is in operable communication with each other. This functional circuitry may include a wireless transceiver, a battery, an interface to a touchscreen or display (e.g., the display may be attached to the housing), a wired connection, Bluetooth, Bluetooth Low Energy, WiFi, 3G, 4G, a coprocessor, a control system (e.g., for controlling the infusion pump), medication with fluid measurement circuitry, and so on. The selected modules can, for example, be connected together in a daisy-chain fashion and then connected to the infusion pump. In this example, the selected modules may be in operable communication with each other via a CAN bus, a wired connection, and / or wirelessly, for example, to coordinate their behavior and / or functionality.

[0390] Each module can include a speaker and a microphone. When several modules are connected to each other, they can coordinate their operations so that one module can send an audible signal to the speaker while another module uses the microphone to determine whether the speaker is functioning correctly. Each of the several modules can use its speaker at a different frequency, so that any one of the modules can sense sound via its microphone and demodulate different frequencies to test several of the speakers simultaneously. The first module can request this test from the second module, and the second module can send the results of the test to the first module.

[0391] Continue to see Figure 1Optionally, one or more of the communication modules 124A-124K may also include one or more batteries to power the device to which it is connected. For example, the communication module 124A may be connected to the infusion pump 7 to provide power thereto. Depending on the purpose and function of the device with which it is associated, the communication modules 124A-124K may include other structures and functions. For example, in some embodiments, control of the infusion occurs at the infusion pump, and input related to the desired delivery occurs at the infusion pump; therefore, in some embodiments of the present disclosure, the communication module 124A implements a control algorithm, such as a proportional-integral-derivative ("PID") control loop, to control the infusion pump 7. In such a case, the monitoring client 1 may, for example, transmit a fluid flow rate signal to the communication module 124A (e.g., via a wireless link). The communication module 124A then applies a signal corresponding to the fluid flow rate signal via electrical contacts coupled to the motor (not explicitly shown) of the infusion pump 7 to achieve the desired flow rate. In some embodiments, the infusion pump 7 provides one or more feedback signals from a flow meter provided within the infusion pump 7 to the communication module 124A, thereby enabling the communication module 124A to control the operation of the infusion pump 7 (e.g., certain aspects of the operation, such as a PID control system, etc.). The results can be transmitted to the monitoring client 1 for display to the user using a GUI, such as a QT-based GUI (in some embodiments, the monitoring client 1 is a tablet computer). Additionally or alternatively, in some embodiments, the drip flow meter 148 can be used to wirelessly transmit the flow rate to the communication module 124A via the communication module 124K and antenna 122K associated with the drip flow meter 148.

[0392] It will be appreciated from this disclosure that 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, see further Figure 1 , communication module 124B is operably coupled to syringe pump 126, and communication module 124C is operably coupled to pill dispenser 128. Additionally 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 / capnometer 16, communication module 124H is operably coupled to other monitor 17, communication module 124I is operably coupled to patient IV access 35, and communication module 124K is operably coupled to drip flow meter 148. Each communication module 124A-124K may provide, for example, an appropriate control system, control algorithm, battery power, or other functionality for the corresponding patient-care device 7, 14, 15, 16, 17, 35, 126, 128, or 148 to which it is coupled.

[0393] Additionally or alternatively, in some embodiments, the communication module 124D is docked in the device base 104 and operatively coupled to the device base 104, for example, via a bus or backplane for communicating with any device attached to the device base 104, and for communicating with electronic circuitry within the device base 104, electronic circuitry within the monitoring-client base 102, and / or the monitoring client 1. Optionally, the communication module 124D can provide communication and / or power to any device docked in the device base 104 (e.g., the infusion pump 7, the syringe pump 126, the pill dispenser 128, or the micropump 130). Note that the functionality of the communication module 124D can also be integrated into the circuitry of the device base 104 itself.

[0394] Additionally or alternatively, in some embodiments, each communication module 124 is optionally configured to provide sufficient power to its respective device 7, 14, 15, 16, 17, 35, 126, 128, 148, which power may be supplemented by one or more wired power sources, such as a power source accessible via a bus or backplane within the device base 104. As described above, in some embodiments of the present disclosure, the communication module 124D provides sufficient power to the devices 7, 126, 128, 130, and 133.

[0395] As described above, in some embodiments, each communication module 124 is configured with power supply circuitry (e.g., a voltage converter, a voltage regulator circuit, a rectifier and filter circuit, a step-down circuit, a step-up circuit, a buck-boost circuit, a switching power supply, etc.) that provides sufficient power to the corresponding device 7, 126, 128, and 130. In some such cases, this power supply circuitry can be configurable to allow for various power supply characteristics (e.g., voltage levels, maximum load / current requirements, and A / C frequencies) associated with the various different patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. Any number of power supply and management schemes will become apparent in light of this disclosure.

[0396] Optionally, in other embodiments of the present disclosure, a power module 132 having one or more battery cells (e.g., lithium-ion battery cells) is attached to the device base 104 to provide sufficient power to the devices 7, 126, 128, 130, 133 for the entire duration of treatment. Additionally or alternatively, the power module 132 can be plugged into an outlet in the patient's room (at a Figure 1124B, 124C). In such cases, when available, this outlet power can be used to power devices in base 104 and charge batteries included in power module 132 (which can occur simultaneously); when outlet power is lost or unavailable, batteries within power module 132 and / or communications modules 124A, 124B, 124C can provide power to docked devices.

[0397] Optionally, the example system 100 may include a dongle 133. The dongle 133 is docked at Figure 1 The dongle 133 may be located in the device base 104, or in other embodiments, the dongle 133 may be located remotely from the device base 104 and / or monitoring client 1. The dongle 133 may provide a communication link or protocol for unavailable wireless devices. For example, as new wireless protocols, technologies, standards, and methods become available over time, the dongle 133 may be used to provide a bridge, router, or repeater between the new communication protocols and convert information sent under one protocol to another protocol so that the new protocol device can communicate with the patient care device 7, 14, 15, 17, 35, 126, 128, 130, the device base 104, the communication module 124D, the monitoring client base 102, the monitoring client 1, Figure 8 The dongle 133 can utilize the patient care device 7, 14, 15, 17, 35, 126, 128, 130, the device base 104, the communication module 124D, the monitoring client base 102, the monitoring client 1, Figure 8 The hub 802 and / or one or more of the other devices may use a wireless protocol, technology, standard, or method to retransmit data received from the new communication link in a format known or used by another device (e.g., the monitoring server 3 or the monitoring client 1). The dongle 133 may also provide a communication bridge to a cellular communication link (e.g., an EVDO or CDMA-based cellular system).

[0398] In some embodiments, the dongle 133 can transmit patient care parameters (eg, patient treatment parameters or patient condition parameters) from one or more patient care devices and retransmit them to the monitoring client 1, Figure 8 Alternatively, in some embodiments, the dongle 133 may include a wired attachment connector (e.g., an RS-232 connector) and may be connected to a conventional device to provide data to one or more other patient care devices, the monitoring client 1, the patient care device ... Figure 8 The hub 802 and / or monitoring server 3 of the present invention provide communication from the traditional device. The traditional device can be, for example, a traditional patient care device, a traditional computing device, or other device using a traditional wired communication protocol.

[0399] Optionally, the system 100 may also include a wearable system monitor 131 for monitoring the operation of various devices, bases, monitoring clients and / or servers. Figure 8 The hub 802 can be used to program, interact with, and / or pair the wearable system monitor 131. The wearable system monitor 131 can be worn by the patient 2 or by the provider, and multiple wearable system monitors 131 can be used. The wearable system monitor 131 can interrogate the various devices to ensure their correct operation. For example, in one example 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 base 102, the device base 104, and / or Figure 8 The hub 802 communicates with the hub 802 to determine if there are any failures, errors, irregularities, data corruption, communication degradation, incomplete operation, slow operation or other problems.

[0400] Communications from the wearable system monitor 131 may include one or more interrogation signals to determine whether the interrogated device is functioning correctly, functioning within predetermined operating parameters, and / or is in an undesirable condition or state. The system monitor 131 may send an interrogation signal to one or more devices, such as the monitoring server 3, the monitoring client 1, or the monitoring server 3. Figure 8 The system monitor 131 may communicate the detected condition or error to the hub 802 to alert the provider, initiate a shutdown process, and / or initiate other appropriate remedial actions related to the malfunctioning device. For example, the system monitor 131 may use the transceiver of the communication module 124J to communicate with the monitoring client 1 and the monitoring server 3 via a WiFi router connected to the network and / or the Internet, other monitoring clients 4, other devices equipped with the communication module 124, or the remote communicator 11 to signal warnings and / or alarms due to abnormalities or the absence of query responses. The warnings and / or alarms may cause the device to audibly emit a sound or visually issue a warning and / or alarm. In some embodiments of the present disclosure, the system monitor 131 provides a call button (not explicitly shown) to allow the patient 2 to issue a request to the care provider. For example, the request is routed to the monitoring client 1 or the remote communicator 11 to visually and / or audibly indicate the request to the user of the device.

[0401] The system monitor 131 can implement its functionality in a variety of ways, including, for example: (1) expecting a response to a query within a predetermined amount of time; (2) incrementing a counter within the device being queried and requesting the value of the counter after the increment from the device; (3) challenge-response queries; and / or (4) other system monitoring techniques or methods.

[0402] As described above, in some embodiments, the system monitor 131 expects to receive a response to the query within a predetermined amount of time after querying a patient-care device paired with the system monitor 131. For example, the system monitor 131 may send a text string message "SYSTEM MONITOR QUERY" to the infusion pump 7. In this example, the infusion pump 7 receives the message labeled "SYSTEM MONITOR QUERY" from the system monitor 131 and processes the message using one or more processors in the infusion pump 7. When the infusion pump 7 processes the message, a software routine in the infusion pump 7 executes code that sends a response message back to the system monitor 131; for example, the response message may be a text string message "SYSTEM MONITOR RESPONSE" sent to the system monitor 131. In this example, the system monitor 131 may expect to receive a response message within a predetermined amount of time (e.g., 2 seconds), and if the system monitor 131 does not receive a response message within 2 seconds, the system monitor 131 alerts and / or sends an alert to other devices (e.g., the system monitor 131 may broadcast the warning or error message, or may cause the alarm or warning to be audibly or visually provided to the processor via the remote communicator 11).

[0403] As described above, in some embodiments, system monitor 131 increments a counter within the interrogated device and requests a subsequent counter value from the device. For example, system monitor 131 may send a request to a patient-care device, such as an infusion pump 7, by sending a message to the device, such as "Increment Counter." The device's processor receives the "Increment Counter" message, reads a value from a memory location within the device, increments the value found at the memory location, and stores the new value in the same memory location, overwriting the previous value. Thereafter, in this example, the processor reads the new value from the memory location and transmits it to system monitor 131, for example, via a wireless transceiver within the interrogated device. In this example, system monitor 131 expects to receive a specific value from the interrogated device (this expected value may be stored in system monitor memory, such as in a table). For example, system monitor 131 may store a previously received value of 48 from the device in its memory and, upon requesting an updated value from the interrogated device, expects to receive a value of 49 from the device.

[0404] Also as described above, the system monitor 131 can use a challenge response query. For example, the system monitor 131 can send an encrypted message to the patient care device. The patient care device is then tasked with decrypting the message, for example, using an encryption key, and sending the message back to the system monitor 131. The system monitor 131 can expect that the unencrypted message will be returned within a predetermined amount of time. In this example, if the system monitor 131 does not receive a response message within the predetermined amount of time, the system monitor 131 warns and / or sends an alarm to other devices (e.g., the system monitor 131 can broadcast the warning or alarm messages and / or send them to the monitoring client 1, the monitoring server 3, Figure 8 hub 802 or remote communicator 11, which will then display or audibly give the warning or alarm).

[0405] In one embodiment of the present disclosure, monitoring client 1 has the ability to communicate or interact directly with a healthcare provider using a handheld or portable remote communicator 11 (e.g., a smartphone, tablet, PDA, laptop, or other portable computing device). This can be accomplished wirelessly 12, enabling communication regardless of the patient's location within the facility or the provider's location inside or outside the facility. In one aspect, patient-specific information can be stored locally on monitoring client 1, enabling the patient's healthcare provider to access this information directly without having to access monitoring server 3.

[0406] In some embodiments, optionally, and subject to appropriate security and privacy checks, changes to settings or flow parameters of connected infusion pumps 7 or patient monitoring devices 14-17, 35, 126, 128, 130, 148 can be made directly between the provider's monitoring client 11 and the monitoring client 1 (via wired or wireless communications), with selected changes being transmitted to the monitoring server 3 and, therefrom, optionally to other appropriate locations, such as the nurses' station 5 and / or the pharmacy 6. In addition, any new medical orders associated with the patient 2 can be entered into the order provider's remote communicator 11 (e.g., a smartphone) and sent to the monitoring client 1, which can then notify the caregiver (e.g., a nurse, nurse practitioner, doctor, physician, or other healthcare professional) via the caregiver's own portable communicator 11. Additionally or alternatively, in some embodiments, the new order may also be transmitted to the infusion pump 7 or patient monitoring device 14-17, 35, 126, 128, 130, 148 so that a control system in or coupled to the device may change its operation, e.g., change its set points, in response to the new order. In some embodiments, any information captured and stored in 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 loses service, a new device may be assigned to the patient 2 and quickly repopulated with the patient's current information from the monitoring server 3. Orders, medications, progress notes, monitoring data, treatment data, patient treatment parameters, patient monitoring parameters, and / or operating parameters from the patient's attached device may also be uploaded from the monitoring client 1 to the patient's EHR 19, any applicable remote communicator 11, Figure 8 's hub 802 and / or monitoring server 3 for permanent, temporary or interim storage and / or for analysis to confirm that it meets predetermined criteria, such as ranges and thresholds, etc.

[0407] In some embodiments, monitoring server 3 may comprise a computer that can communicate with multiple monitoring clients 1, 4, 11 within facility 8 and provide some elements of control for these multiple monitoring clients 1, 4, 11. Monitoring server 3 can provide monitoring clients 1, 4, 11 with data extracted from multiple databases within facility 8 and external to facility 9. In one embodiment of the present disclosure, monitoring server 3 can query the facility's EHR system 19 for targeted information related to patient 2 and then populate the patient's monitoring client 1 with a predefined set of information (e.g., the patient's age, height, weight, diagnosis category, current medications and drug classes, drug allergies and sensitivities, etc.). According to one such example, when monitoring client 1 is assigned to patient 2, monitoring server 3 can establish communication links with EHR 19, laboratory 20, radiology department 21, pharmacy 22, and / or other systems (e.g., cardiology department 23 or appointment database 24). Using a unique patient identifier, monitoring server 3 can obtain electronic access rights (permissions) to receive and send patient-specific data to these systems. A predetermined (but optional) subset of data can be downloaded to the memory of the monitoring client 1 ( Figure 1 not explicitly shown).

[0408] The information thus obtained can then serve as a critical database against which new orders can be analyzed. Orders 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, orders entered remotely from the communicator 11 can be intercepted by the monitoring server 3 and similarly checked. The monitoring server 3 can also obtain information from a medication database resident in the facility's pharmacy 22 or from an external medication database 9 to, for example, determine whether a new patient order will create an incompatibility with the patient's existing medications. In one embodiment of the present disclosure, the monitoring server 3 can be programmed to access a publicly available Internet website 25 to determine whether new information related to the patient's prescribed medications should be downloaded and sent 13 to the patient's healthcare provider in the form of an alert or alarm. The monitoring server 3 can also route information between the remote portable communicator 11 and the patient's monitoring client 1.

[0409] In one embodiment of the present disclosure, a patient's physician, nurse, or pharmacist can access the patient's monitoring client 1 to relay or receive new medical orders (such as medication orders) related to patient 2. The monitoring client 1 or server 3 can then record the new order and relay the request to the pharmacist 6 and the patient's nurse via the nurse's portable communicator 11 and / or via a fixed terminal at the nurse's station 5. A "smartphone" with a customized communication application with the monitoring client 1 (such as Google's Nexus One phone, Apple's iPhone, or RIM's Blackberry OS) can serve as a convenient portable communicator 11 for providers who are not in a fixed location (e.g., in an office or at a remote nurse's station). Tablet PCs, netbooks, or laptops can also serve as convenient portable communicators 11 for both portable and fixed locations. A PC can serve as a convenient communication device 11 for fixed or desktop locations. If the provider is in the patient's room, he or she can enter or receive information related to patient 2 using direct input via the keyboard or touchscreen on the monitoring client 1.

[0410] The monitoring client 1 can receive, process, and transmit information related to the specific patient 2 to which it is assigned or designated. The monitoring client 1 can most conveniently be attached or docked to a monitoring client base 102 to communicate with the infusion pump 7 or any other device connectable to or associated with the patient 2. The monitoring client 1 can be, for example, a handheld device comparable in size to a wireless phone or a tablet-type netbook. Conveniently, it can have a touchscreen interface for use by the patient's provider. It can also provide output via a wired or wireless connection to a larger fixed display in the patient's room, at the nurse's station 5, or other convenient location. Each monitoring client 1 can communicate with a central monitoring server 3, through which each monitoring client 1 can access patient data from the facility's EHR database 19, laboratory database 20, radiology database 21, pharmacy database 22, or other databases in various other facility departments. In some cases, the monitoring client 1 can upload information received from the patient monitoring devices 14-17 or from providers entering the patient's EHR 19 via the monitoring server 3. The monitoring clients 1, 4 may also receive information from databases external to the facility via the monitoring server 3 having an Internet connection 25. Thus, various external databases 9 are accessible, including various drug information databases and an alarm network that handles adverse drug related events.

[0411] The monitoring server 3 can, for example, be configured to manage various levels of external database information that helps keep the content of the monitoring client 1 as up-to-date as possible. This can be achieved, for example, by comparing patient-related safety and medication information as it becomes available and prioritizing updates / downloads based on a data transfer schedule. The monitoring clients 1 and 4 can also communicate directly or through the monitoring server 3 with a portable communicator 11 used by a healthcare provider (e.g., a nurse, physician, or pharmacist). In some cases, these devices may have a wired connection to the monitoring server 3 (e.g., if used in a fixed location such as a hospital pharmacy or nurse's station). In other cases, the portable communicator 11 can communicate with the monitoring server 3 using a computer, a secure Internet connection (e.g., one based on a VPN, UPN, HTTPS, a private key mechanism, etc.), and a wired or wireless (e.g., Bluetooth or WiFi 802.11) connection 13 to the device 11. Alternatively, a handheld remote communicator 11 (e.g., a smartphone or tablet netbook) may communicate directly 12 with the facility's monitoring client 1 via a cellular telephone network, and / or the facility may include a dedicated cellular network, which may include a WiFi network (e.g., the open ISM band of 2.4 GHz to 2.4835 GHz).

[0412] In some embodiments, the communication link between the monitoring clients 1, 4 and the monitoring server 3 can exist via Ethernet (if widely available in the facility) or via wireless transmission using one of a number of standards, thereby linking all patient-specific monitoring clients 1, 4 with the central monitoring server 3. The server 3 can then act as a repeater for communicating with other facility servers 8, with web-based servers 25, and with internal and external portable communicators 11 carried by medical healthcare providers. In some embodiments, the wireless network provides the additional functionality of being able to communicate with the monitoring server 3 regardless of where the patient 2 may be located in the facility.

[0413] One approach to blanketing an entire facility with wireless coverage involves licensing a dedicated cellular telephone network. The facility can acquire or lease one or more microcellular frequencies to provide a localized communication network throughout the facility. This arrangement allows patients and their monitoring clients 1 and 4 to maintain communication as they move from one location within the facility to another, maintaining communication with the monitoring server 3, various databases 8 and 25 within and outside the hospital, and users at fixed locations (e.g., nurses' stations 5 and pharmacies 6 in some embodiments) or with monitoring clients 11 (e.g., smartphones, laptops, or tablets) inside or outside the hospital. In some embodiments, this system provides additional security via licensed cellular communication infrastructure. Additionally, in some embodiments, an active wireless system can monitor usage intensity in an area and direct access to additional channel frequencies. However, in some embodiments, the network's bandwidth capacity may not allow for the efficient transmission of large data files (e.g., those containing radiological images). Such bandwidth-intensive data files can be more efficiently transmitted via a wired connection.

[0414] Alternatively or additionally, the hospital may implement an Internet- or intranet-based communication system, using 802.11 WiFi-type protocols for wireless communication between the various monitoring clients 1, 4 and the monitoring server 3. To ensure adequate signal reception throughout the facility, broadband antennas may be installed on the roofs of buildings to collect cellular phone signals from local wireless phone companies. Fiber optic or cable networks can then distribute the signals throughout the facility. Additionally or alternatively, the monitoring server 3 may utilize the aforementioned dedicated cellular network. Such systems typically provide secure communications and are capable of efficiently transferring large files, such as radiological images stored in the radiology department database 21. Home- or office-based users can connect to the hospital server using wired or fiber optic cable or DSL phone lines, for example, via a VPN or other secure access method. Data encryption may be used to provide security for patient data. In some applications, implementing an asymmetric bandwidth communication network may be beneficial to optimize infrastructure capacity. One example is the use of licensed cellular frequencies in the "uplink" direction from the monitoring client 1 to the monitoring server 3 and open 802.11 WiFi frequencies in the "downlink" direction from the monitoring server 3 to the monitoring client 1. In this example, the upstream bandwidth and data rate requirements are smaller than those for downstream. In low priority upstream transmission, the monitoring client 1 can allow data to be sent over a more distributed and cost-effective network, such as a ZigBee network, a Bluetooth network, or a mesh network.

[0415] As described above, ZigBee wireless mesh networks and / or Bluetooth networks can be used, for example, to cost-effectively implement communication between various monitoring devices (such as patient-care devices 14, 15, 16, 17, 35) and the monitoring client 1. Exemplary monitoring devices include, among others, an ECG monitor 14, a blood pressure monitor 15, a pulse oximeter / capnometer 16, a thermometer, and a weight scale. A common characteristic of most of these devices is that they provide periodic readouts of a single or small number of parameters. In-hospital device communication systems, such as wireless mesh networks, provide low-power digital broadcast connections between devices and can utilize widely available, unlicensed frequency bands (e.g., 2.4 GHz in some regions). Advanced communication protocols, such as TCP and UDP, can be employed to ensure data fidelity and security. For example, symmetric encryption keys, such as those generated for encryption algorithms such as Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES, and IDEA, can be used to secure communications between the monitoring client and the patient-care devices. Additionally or alternatively, various data integrity techniques may be used, such as CRC, odd or even parity bit checking, etc.

[0416] Mesh networks are highly scalable, allowing multiple devices to be used on a single, self-forming, self-repairing mesh network. Devices connected to the network can communicate with each other and act as repeaters to transmit data. Mesh networks can be low-cost, scalable, or mobile for monitored patients. In some embodiments, the wireless range of devices linked to the wireless mesh network can be 70 meters from each node of the system within the facility. Similar networks can be used to provide wireless links between portable communicators 11 carried by health care providers and patients to whom these communicators 11 are assigned, within the facility, through the patient's monitoring clients 1, 4.

[0417] In many cases, the information sent to the monitoring client 1 may include a single parameter value (e.g., blood pressure) and a timestamp. The monitoring client 1 can be programmed to determine if the value is outside a predetermined range, record the value in the patient's EHR 19, and notify appropriate providers via the patient's monitoring client 11. Furthermore, the network can enable bidirectional communication and allow the monitoring client 1 to query a patient monitoring device (e.g., BP monitor 15) to instruct it to take an unscheduled reading. This can be beneficial, for example, when an abnormal reading is received and its authenticity needs to be verified. The monitoring client 1 can be programmed to request a repeat reading to verify the abnormal reading. In yet 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 value of the reading 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 infusion, and the monitoring client 1 can send an emergency notification 12 to the healthcare provider's monitoring client 11. In another embodiment, if the infusion pump 7 is able to determine the volume of fluid delivered to the patient 2 (e.g., the flow rate or cumulative amount of fluid pumped over a time interval), the processor in the monitoring client 1 can track the cumulative volume delivered and estimate the amount of fluid remaining in the medication bag 170. (Alternatively, the processor in the monitoring client 1 or infusion pump 7 can calculate the delivered volume based on the infusion rate and the elapsed infusion time).

[0418] Once the estimated remaining volume reaches a predetermined amount, the monitoring client 1 can signal the infusion pump 7 to reduce its flow rate to prevent the patient's IV access 35 from running dry. For example, the monitoring client 1 can determine that a nurse is scheduled to return at a specific time to replace the bag. Instead of warning and / or sending a warning that the IV fluid will run out before the nurse's scheduled return, the monitoring client 1 can signal the infusion pump 7 to reduce the infusion rate so that the IV bag will be empty by the time the nurse arrives or after a predetermined amount of time from the nurse's scheduled return time. It can also send a notification to the nurse's monitoring client 11 to recommend refilling the IV bag 17.

[0419] In some embodiments, the progress of the operation of the patient-care device is indicated by an outer border on the display of the monitoring client 1 to display the status and / or progress of the patient-care device. For example, the outer border may be displayed on the monitoring client 1 such that the percentage of the border that is illuminated (e.g., as the border fills in to form a completely filled perimeter) indicates the progress of the treatment being performed by the patient-care device, such as the infusion pump 7. The border may 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 percentage of completion to the monitoring client 1 (in which case the monitoring client 1 generates the border).

[0420] In some embodiments, GPS and / or distance measurement modules (e.g., ultrasonic distance measurement modules using round-trip time estimation) may be installed on the infusion pump 7, the monitoring client 1, the caregiver, and / or the patient. In this particular embodiment, the predetermined settings may require that a predetermined set of infusion pumps 7, monitoring clients 1, and / or patients be enabled before starting treatment and / or before configuring one of the infusion pumps 7 and / or monitoring clients 1. Figure 8 The hub 802, the caregiver and / or the patient are at a predetermined distance relative to each other.

[0421] In some embodiments, the patient care device 7, 170, 126, 128, 130, 14, 15, 16, 17, 124, or 148, the base 102 or 104, the monitoring client 1, Figure 8 The hub 802 may send a soft alert, a hard alert, and / or a non-critical alert to the remote communicator 11 without issuing an alert on the device that issued the alert and / or on the monitoring client 1 until a predetermined amount of time has passed (e.g., to allow a caregiver to find a solution to eliminate the cause of the alert without disturbing the patient). If the cause of the alert is eliminated before the predetermined amount of time, the device that issued the alert and / or the monitoring client 1 may not issue an alert, thereby avoiding additional disturbance to the patient.

[0422] In some embodiments, Figure 1 The AC cable includes a clamp so that IV tubing can be clamped to the clamp.

[0423] In some embodiments, the infusion pump 7 includes a status LED light to indicate one or more of the following: safety checks have been passed; the pump is flowing; there is a blockage; and / or the pump is disconnecting. The user can use the monitoring client 1 to read the barcode on the IV bag 170 (e.g., using the camera 144 or the camera 136 and / or the scanner 120), at which point the LED on the receptacle can flash to indicate to the user that the tubing connected to the IV bag 170 should be inserted into the receptacle.

[0424] In some embodiments, as Figure 1shown or combined Figure 1 Each item, component, device, patient care device, base, and computing device described, whether numbered or unnumbered, 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, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online medication database 9 is optional, adverse drug event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 is optional. Similarly, in some embodiments of the present disclosure, each of system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply is optional.

[0425] Additionally, in some embodiments, although Figure 1 shown or combined Figure 1 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as single items, components, devices, patient-care devices, bases, or computing devices, although multiple items, components, devices, patient-care devices, bases, and computing devices are contemplated; for example, although Figure 1 A single infusion pump 7 is shown, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, multiple device bases 104 and / or multiple monitoring client bases 102 can be used.

[0426] Additionally or alternatively, while specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples thereof, or combinations thereof of the specific patient care devices may be used. For example, in some embodiments, only the infusion pump 7 is used as a patient care device, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, may not be present or available for use by the system, may be turned off, or may not be Figure 1102. Additionally or alternatively, in some specific embodiments, only the patient-care devices in use are dockable to the device base 104; for example, in this specific embodiment, the infusion pump 7 is the only device docked to the device base 102, and the device base 102 receives only one device, such as the infusion pump 7. Additionally, alternatively, or optionally, in some specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 are dockable, may operate undocked, and / or may be non-dockable and capable of operating as standalone patient-care devices.

[0427] 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 bases 102 and / or 104 may include secure data classes, for example, via an API.

[0428] In some embodiments, the Figure 8 The hub 802 performs the reference Figure 1 Any functionality described.

[0429] Figure 2 A flowchart illustrating a method 150 for maintaining a monitoring client (eg, Figure 1 monitoring client 1) and one or more patient care devices (e.g. Figure 1 The example method 150 includes steps 152-169. The monitoring client 1 can display an icon indicating when communication with the paired and / or designated patient-care device is established. The monitoring client 1 can check to ensure that communication with the paired and / or designated patient-care device is obtained within a predetermined time interval, and the monitoring client 1 can issue a warning or alarm if communication with the paired or designated patient-care device is not available for a predetermined amount of time.

[0430] Step 152 determines whether the monitoring client base can be used as a communication link between the monitoring client and the monitoring client base via the base connector. If the communication link in step 152 is available, then method 150 proceeds to step 154, otherwise, method 150 proceeds to step 156.

[0431] Step 156 determines whether the monitoring client base can be used as the communication link between the monitoring client and the monitoring client base via a wireless link. If the link in step 156 is available, then method 150 proceeds to step 154, otherwise, method 150 proceeds to step 158.

[0432] Step 154 ​​determines whether the monitoring client base can use a cable as a communication link between the monitoring client base and the device base. If the communication link of step 154 ​​is available, the method 150 proceeds to step 160, otherwise, the method 150 proceeds to step 158. Step 160 determines whether the device base can use a communication link between the device base and the patient-care device, such as via a wireless or wired communication link. If the communication link in step 160 is available, the method 150 proceeds to step 166, otherwise, the method 150 proceeds to step 162. Step 162 determines whether the patient-care device can use a direct wireless link as a communication link between the monitoring client and the patient-care device base. If the communication link in step 162 is available, the method proceeds to step 166, otherwise, the method 150 proceeds to step 164.

[0433] Step 158 determines whether the device base can be used as a communication link between the monitoring client and the device base via a wireless link. If the communication link in step 158 is not available, the method 150 proceeds to step 162, otherwise, the method 150 proceeds to step 160.

[0434] Step 166 attempts a handshake between the monitoring client and the patient care device using available communication links. In alternative embodiments, no handshake is used; for example, not all protocols use a handshake between communication endpoints. Decision step 168 determines whether the handshake in step 166 was successful. If decision step 168 determines that the handshake in step 166 was unsuccessful, then step 164 determines that communication with the patient device is unavailable, and / or method 150 attempts to establish communication using other links (not explicitly shown). Otherwise, if decision step 168 determines that the handshake in step 166 was successful, then step 169 transmits the data using a sufficient number of communication links determined to be available by method 150.

[0435] Method 150 is an exemplary embodiment of the present disclosure, describing a method for maintaining communications between a monitoring client and one or more patient-care devices. In some embodiments, while method 150 includes a schedule for communication links, other schedules may be used, broadcast, anycast, multicast, or unicast may be used, a routing algorithm may be used, a distance vector routing protocol may be used, a link state routing protocol may be used, an optimized link state routing protocol may be used, a path vector protocol may be used, static routing with predetermined alternative communication paths may be used, and / or adaptive networking may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, and a Dijkstra algorithm may be used for communications between a monitoring client 1 and one or more patient-care devices; the weights may be determined in any known manner, including based on bandwidth, signal quality, bit error rate, may be linear with respect to available data throughput or latency, and the like.

[0436] See attached figure, Figure 3 A block diagram of an electronic patient care system 300 is shown according to another embodiment of the present disclosure having two bases 102, 104 for wireless communication therebetween. The system 300 is similar to Figure 1 However, the communication between the monitoring client base 102 and the device base 104 is via a wireless link. For example, in some embodiments, Figure 3 The system 300 may be Figure 1 The cable 110 is not present or inoperable when Figure 1 system 100; additionally or alternatively, Figure 3 The system 300 may have bases 102 and 104 that are not connected together using a cable.

[0437] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be configured to send commands or requests to the infusion pump 7, syringe pump 126, and / or micropump 130 for the patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, such as a bolus dose, an infusion flow rate, a total fluid to be delivered, a start time for drug delivery, a stop time for drug delivery, or a delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be configured to send commands or requests to the bolus dispenser 128, such as a bolus dispense command for dispensing a bolus, a bolus type, a bolus dispense schedule, and / or a maximum bolus dispense standard. The maximum bolus dispense standard can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications are available on demand (i.e., when necessary), whereas excessive amounts of medication can be unsafe, and the maximum bolus dispense standard can prevent a patient from receiving medication at unsafe levels, such as by receiving a predetermined amount within a predetermined time interval.

[0438] 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 monitoring client remote communicator 11.

[0439] Optionally, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also transmit data back to the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 to: determine whether a warning or alarm should be issued or sent; determine whether the treatment or condition is safe for the patient; determine whether the system 300 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11. For example, the infusion pump 7, syringe pump 126, and / or micropump 130 may optionally transmit to one or more of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 (as appropriate): upstream pressure; change in upstream pressure; pressure downstream of the patient 2; change in pressure downstream of the patient 2; presence of air in the infusion line; actual bolus delivered; actual infusion flow rate; actual total fluid delivered; actual start time of medication delivery; actual stop time of medication delivery; or actual delivery flow rate profile. In another embodiment, the pill dispenser 128 can optionally transmit data back to the monitoring client 1, other monitoring clients 4, and / or remote communicator 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule dispensed, or whether a maximum pill dispensing criteria was exceeded.

[0440] Data received from patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined conditions that trigger alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micropump 130 as an indication of one of the following: excessive coagulation, infiltration, occlusion, or kinking of the tubing leading to the patient; or an occlusion caused by other materials within the IV bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. Additionally or alternatively, a sudden decrease in pressure downstream of the patient 2 can indicate that the tubing has become detached from the needle and / or that the needle is now removed from the patient; and in response, one or more of the monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. One or more of the monitoring clients 1, 4, 11 can optionally send commands to one or more of the infusion pump 7, syringe pump 126 and / or micropump 130 to stop fluid delivery in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2.

[0441] In some embodiments, as Figure 3 shown or combined Figure 3 Each item, component, device, patient care device, base, and computing device described, whether numbered or unnumbered, 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, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online medication database 9 is optional, adverse drug event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 is optional. Similarly, in some embodiments of the present disclosure, each of system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply is optional.

[0442] Additionally, in some embodiments, although Figure 3 shown or combined Figure 3 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as single items, components, devices, patient-care devices, bases, or computing devices, although multiple items, components, devices, patient-care devices, bases, and computing devices are contemplated; for example, although Figure 3 A single infusion pump 7 is shown, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, multiple device bases 104 and / or multiple monitoring client bases 102 can be used.

[0443] Additionally or alternatively, while specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples thereof, or combinations thereof of the specific patient care devices may be used. For example, in some embodiments, only the infusion pump 7 is used as a patient care device, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, may not be present or available for use by the system, may be turned off, or may not be Figure 3 102. Additionally or alternatively, in some specific embodiments, only the patient-care devices in use are dockable to the device base 104; for example, in one specific embodiment, the infusion pump 7 is the only device docked to the device base 102, and the device base 102 receives only one device, such as the infusion pump 7. Additionally, alternatively, or optionally, in some specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be dockable, may operate undocked, and / or may be non-dockable and capable of operating as standalone patient-care devices.

[0444] exist Figure 3 In the embodiment, although the device base 104 is shown as being capable of receiving several patient care devices, in other embodiments, the device base 104 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Moreover, the bays of the base can be unused, for example, Figure 3 As shown, an empty recess 170 in the device base 104 is shown. In addition, although the monitoring client base 102 is shown as being able to receive one monitoring client 1, in other embodiments, the monitoring client base 102 can receive two monitoring clients 1, more than two monitoring clients 1, or any number of monitoring clients 1.

[0445] Figure 4 A flowchart for illustrating a method 202 according to an embodiment of the present disclosure is shown. The method 202 is used to maintain a monitoring client (eg, monitoring client 1) and one or more devices (eg, Figure 3 Communication between patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148).

[0446] Step 204 determines whether the monitoring client base can function as a communication link between the monitoring client and the monitoring client base via the base connector. If the communication link is available in step 204, method 202 proceeds to step 206; otherwise, method 202 proceeds to step 208. Step 208 determines whether the monitoring client base can function as a communication link between the monitoring client and the monitoring client base via a wireless link. If the communication link is available in step 208, method 202 proceeds to step 206; otherwise, method 202 proceeds to step 210.

[0447] Step 206 determines whether the monitoring client base can be used as a communication link between the monitoring client base and the device base via a wireless link. If the communication link in step 206 is available, the method 202 proceeds to step 212, otherwise, the method 202 proceeds to step 210.

[0448] Step 210 determines whether the device base can be used as a communication link between the monitoring client and the device base via a wireless link. If the communication link in step 210 is available, the method 202 proceeds to step 212, otherwise, the method 202 proceeds to step 214.

[0449] Step 212 determines whether the device base can be used as a communication link between the device base and the patient-care device. If the communication link in step 212 is available, the method 202 proceeds to step 216, otherwise, the method 202 proceeds to step 214.

[0450] Step 214 determines whether the patient care device can be used as a communication link between the monitoring client and the patient care device via a direct wireless link. If the communication link in step 214 is available, the method 202 proceeds to step 216, otherwise, step 218 determines that communication with the patient care device is not available.

[0451] Step 216 attempts a handshake between the monitoring client and the patient-care device using an available communication link. In alternative embodiments, a handshake is not attempted; for example, some communication protocols do not use a handshake. Decision step 220 determines whether the handshake was successful and whether communication between the monitoring client and the device has been established. If step 220 determines that a communication link has been established, method 202 uses the available communication link to transmit data between the monitoring client and the device during step 222. If decision step 220 determines that the handshake was unsuccessful, method 202 determines in step 218 that communication with the device is not available, or method 202 attempts to communicate between the monitoring clients via a communication link that was not attempted (not explicitly shown).

[0452] Method 202 is an exemplary embodiment of the present disclosure, which is used to describe a method for maintaining communication between a monitoring client and one or more patient-care devices. In some embodiments, although method 202 includes a schedule for communication links, other schedules may be used, broadcast, anycast, multicast, or unicast may be used, a routing algorithm may be used, a distance vector routing protocol may be used, a link state routing protocol may be used, an optimized link state routing protocol may be used, a path vector protocol may be used, static routing with predetermined alternative communication paths may be used, and / or adaptive networking may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, and a Dijkstra algorithm may be used to communicate between a monitoring client 1 and one or more patient-care devices; the weights may be determined in any known manner, including based on bandwidth, signal quality, bit error rate, may be linear with respect to available data throughput or latency, and the like.

[0453] Now see Figure 5 , an electronic patient-care system 500 according to another embodiment of the present disclosure is shown in block diagram form, which has a base 502 for docking the monitoring client 1 and various patient-care devices (e.g., patient-care device 7, 126, 128 or 130), the communication module 124D and the software dog 133 together. Figure 5 The electronic patient care system 500 is similar to Figure 1 However, each of the monitoring client 1, patient-care devices 7, 126, 128, 130, communication module 124D, and dongle 133 can be docked to a base 502. As will be understood in light of this disclosure, the base 502 can include one or more buses, backplanes, communication pathways, electronic circuits, and the like to facilitate communication.

[0454] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be configured to send commands or requests to the infusion pump 7, syringe pump 126, and / or micropump 130 for the patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, such as a bolus dose, an infusion flow rate, a total fluid to be delivered, a start time for drug delivery, a stop time for drug delivery, or a delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be configured to send commands or requests to the bolus dispenser 128, such as a bolus dispense command for dispensing a bolus, a bolus type, a bolus dispense schedule, and / or a maximum bolus dispense standard. The maximum bolus dispense standard can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications are available on demand (i.e., when necessary), however, excessive amounts of medication may be unsafe, and the maximum bolus dispense standard can prevent a patient from receiving medication at unsafe levels, such as by receiving a predetermined amount within a predetermined time interval.

[0455] Optionally, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also transmit data back to the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 to: determine whether an alarm or warning should be issued or sent; determine whether a treatment or condition is safe for the patient; determine whether the system 500 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11. For example, the infusion pump 7, syringe pump 126, and / or micropump 130 may optionally transmit to one or more of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 (as appropriate): upstream pressure; change in upstream pressure; pressure downstream of the patient 2; change in pressure downstream of the patient 2; presence of air in the infusion line; actual bolus delivered; actual infusion flow rate; actual total fluid delivered; actual start time of medication delivery; actual stop time of medication delivery; or actual delivery flow rate profile. In another embodiment, the pill dispenser 128 can optionally transmit data back to the monitoring client 1, other monitoring clients 4, and / or remote communicator 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule dispensed, or whether a maximum pill dispensing criteria was exceeded.

[0456] Data received from patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined conditions that trigger alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micropump 130 as an indication of one of the following: excessive coagulation, infiltration, occlusion, or kinking of the tubing leading to the patient; or an occlusion caused by other materials within the IV bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. Additionally or alternatively, a sudden decrease in pressure downstream of the patient 2 can indicate that the tubing has become detached from the needle and / or that the needle is now removed from the patient; and in response, one or more of the monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. One or more of the monitoring clients 1, 4, 11 can optionally send commands to one or more of the infusion pump 7, syringe pump 126 and / or micropump 130 to stop fluid delivery in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2.

[0457] In some embodiments, as Figure 5 shown or combined Figure 5 Each item, component, device, patient care device, base, and computing device described, whether numbered or unnumbered, 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, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online medication database 9 is optional, adverse drug event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 is optional. Similarly, in some embodiments of the present disclosure, each of system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply is optional.

[0458] Additionally, in some embodiments, although Figure 5 shown or combined Figure 5 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as single items, components, devices, patient-care devices, bases, or computing devices, although multiple items, components, devices, patient-care devices, bases, and computing devices are contemplated; for example, although Figure 5 A single infusion pump 7 is shown in FIG, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, multiple bases 502 can be used.

[0459] Additionally or alternatively, while specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples thereof, or combinations thereof of the specific patient care devices may be used. For example, in some embodiments, only the infusion pump 7 is used as a patient care device, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, may not be present or available for use by the system, may be turned off, or may not be Figure 5 502. Additionally or alternatively, in some specific embodiments, only the patient-care device in use can be docked to the base 502; for example, in one specific embodiment, the infusion pump 7 is the only device docked to the device base 502, and the device base 102 only receives one device, such as the infusion pump 7. Additionally, alternatively, or optionally, in some specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be dockable, can operate undocked, and / or can be non-dockable and capable of operating as standalone patient-care devices.

[0460] exist Figure 5 In the embodiment, although the base 502 is shown as being capable of receiving several patient care devices, in other embodiments, the base 502 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Moreover, the recess of the base can be unused, for example, Figure 5 As shown, an empty recess 170 in the base 502 is shown. In addition, although the base 502 is shown as being able to receive one monitoring client 1, in other embodiments, the base 502 can receive two monitoring clients 1, more than two monitoring clients 1, or any number of monitoring clients 1.

[0461] Figure 6 is a flowchart illustrating a method 304 for maintaining a monitoring client (eg, Figure 5 monitoring client 1) and one or more patient care devices (e.g. Figure 5 Communication between patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148).

[0462] The method determines in step 306 whether the base can be used as a communication link between the monitoring client and the base via the base connector. If the communication link is not available in step 306, the method 304 proceeds to step 308; otherwise, the method 304 proceeds to step 310. Step 310 determines whether the base can be used as a communication link between the base and the patient-care device. If the communication link is not available in step 310, the method 304 proceeds to step 312; otherwise, the method 304 proceeds to step 314.

[0463] Step 308 determines whether the base can be used as a communication link between the monitoring client and the base via a wireless link. If the communication link in step 308 is available, the method 304 proceeds to step 310, otherwise, the method 304 proceeds to step 312.

[0464] Step 312 determines whether a patient-care device can be used as a communication link between the monitoring client and the patient-care device via a direct wireless link. If the communication link in step 312 is not available, step 316 determines that communication between the monitoring client and the patient-care device is not available.

[0465] Step 314 attempts a handshake between the monitoring client and the device using an available communication link. In alternative embodiments, a handshake is not used; for example, some protocols do not use a handshake. Decision step 318 determines whether the handshake was successful, and if so, method 304 proceeds to step 320 to transmit data using an available communication link. If decision step 318 determines that the handshake in step 314 was unsuccessful, step 316 determines that communication with the device is unavailable. In other embodiments, if decision step 318 determines that the handshake in step 314 was unsuccessful, method 304 attempts to communicate with the patient care device via an untried communication link (not explicitly shown).

[0466] Method 304 is an exemplary embodiment of the present disclosure, describing a method for maintaining communications between a monitoring client and one or more patient-care devices. In some embodiments, while method 304 includes a schedule for a communication link, other schedules may be used, broadcast, anycast, multicast, or unicast may be used, a routing algorithm may be used, a distance vector routing protocol may be used, a link state routing protocol may be used, an optimized link state routing protocol may be used, a path vector protocol may be used, static routing with predetermined alternative communication paths may be used, and / or adaptive networking may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, and a Dijkstra algorithm may be used for communications between a monitoring client 1 and one or more patient-care devices; the weights may be determined in any known manner, including based on bandwidth, signal quality, bit error rate, may be linear with respect to available data throughput or latency, and the like.

[0467] Now turn Figure 7 , shows a block diagram of an electronic patient-care system 700 according to yet another embodiment of the present disclosure, the electronic patient-care system 700 having a monitoring client 1 with an integrated base 702 for docking the patient-care device 7, 126, 128, 130 with the monitoring client 1. Additionally, in some embodiments, both the communication module 124D and the dongle 133 can be docked to the base 702. Figure 7 The patient care system 700 is similar to Figure 1 14, 15, 16, 17, 35, 126, 128, 130, 148), the monitoring client 1 can communicate with the patient-care device wirelessly, for example, using the antenna 112 of the monitoring client 1.

[0468] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be configured to send commands or requests to the infusion pump 7, syringe pump 126, and / or micropump 130 for the patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, such as a bolus dose, an infusion flow rate, a total fluid to be delivered, a start time for drug delivery, a stop time for drug delivery, or a delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be configured to send commands or requests to the bolus dispenser 128, such as a bolus dispense command for dispensing a bolus, a bolus type, a bolus dispense schedule, and / or a maximum bolus dispense standard. The maximum bolus dispense standard can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications are available on demand (i.e., when necessary), however, excessive amounts of medication may be unsafe, and the maximum bolus dispense standard can prevent a patient from receiving medication at unsafe levels, such as by receiving a predetermined amount within a predetermined time interval.

[0469] Optionally, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may also transmit data back to the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 to: determine whether an alarm or warning should be issued or sent; determine whether a treatment or condition is safe for the patient; determine whether the system 700 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11. For example, the infusion pump 7, syringe pump 126, and / or micropump 130 may optionally transmit to one or more of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 (as appropriate): upstream pressure; change in upstream pressure; pressure downstream of the patient 2; change in pressure downstream of the patient 2; presence of air in the infusion line; actual bolus delivered; actual infusion flow rate; actual total fluid delivered; actual start time of medication delivery; actual stop time of medication delivery; or actual delivery flow rate profile. In another embodiment, the pill dispenser 128 can optionally transmit data back to the monitoring client 1, other monitoring clients 4, and / or remote communicator 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule dispensed, or whether a maximum pill dispensing criteria was exceeded.

[0470] Data received from patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined conditions that trigger alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micropump 130 as an indication of one of the following: excessive coagulation, infiltration, occlusion, or kinking of the tubing leading to the patient; or an occlusion caused by other materials within the IV bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. Additionally or alternatively, a sudden decrease in pressure downstream of the patient 2 can indicate that the tubing has become detached from the needle and / or that the needle is now removed from the patient; and in response, one or more of the monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. One or more of the monitoring clients 1, 4, 11 can optionally send commands to one or more of the infusion pump 7, syringe pump 126 and / or micropump 130 to stop fluid delivery in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2.

[0471] In some embodiments, as Figure 7 shown or combined Figure 7 Each item, component, device, patient care device, base, and computing device described, whether numbered or unnumbered, 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, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online medication database 9 is optional, adverse drug event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 is optional. Similarly, in some embodiments of the present disclosure, each of system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply is optional.

[0472] Additionally, in some embodiments, although Figure 7 shown or combined Figure 7 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as single items, components, devices, patient-care devices, bases, or computing devices, although multiple items, components, devices, patient-care devices, bases, and computing devices are contemplated; for example, although Figure 7 A single infusion pump 7 is shown in FIG, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or any number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, an integrated base 702 can be used.

[0473] Additionally or alternatively, while specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples thereof, or combinations thereof of the specific patient care devices may be used. For example, in some embodiments, only the infusion pump 7 is used as a patient care device, and in this particular example, the other patient care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, may not be present or available for use by the system, may be turned off, or may not be Figure 7 702. Additionally or alternatively, in some specific embodiments, only the used patient-care devices are dockable to the integrated base 702; for example, in one specific embodiment, the infusion pump 7 is the only device docked to the integrated base 702, and the integrated base 702 receives only one device, such as the infusion pump 7. Additionally, alternatively, or optionally, in some specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 are dockable, can be operated undocked, and / or can be non-dockable and capable of operating as standalone patient-care devices.

[0474] exist Figure 7 In the embodiment, although the integrated base 702 is shown as being capable of receiving several patient care devices, in other embodiments, the integrated base 702 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Moreover, the recess of the base can be unused, for example, Figure 7 As shown, an empty recess 170 is shown in the integrated base 702. In addition, although the integrated base 702 is shown as having one integrated monitoring client 1, in other embodiments, the integrated base 702 has two integrated monitoring clients 1, more than two integrated monitoring clients 1, or any number of integrated monitoring clients 1.

[0475] Figure 8FIG2 is a block diagram of an electronic patient-care system 800 with 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 base 102 and device bases 804 and 806. In other embodiments, the hub 802 controls patient-care devices without the monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, the hub 802 can communicate with the monitoring server 3, facility services 8, nurse station 5, pharmacy 6, cloud server 25, online medication database or adverse drug event network 9, a patient's personal EHR 19', and / or treatment outcome database 10. The hub 802 can provide a clock so that all devices connected to the hub 802 (e.g., patient care devices, monitoring clients, remote communicators, etc.) use the hub 802 clock, with real-time devices using the hub 802 clock, or time-critical devices using the hub 802 clock.

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

[0477] In some embodiments, the hub 802 includes an application programming interface (API) for displaying a GUI, window, data, etc. on the monitoring client 1 and / or the remote communicator 11. The API may include a secure data class. In other embodiments, the base 102, 804, and / or 806 includes an API for displaying a GUI, window, data, etc. on the monitoring client 1 or the portable communicator 11. In yet another embodiment, the base 102, 804, or 806, or the hub 802 includes an API for displaying a GUI, window, data, etc. on the patient-care device 830, 810, and / or 814.

[0478] In some embodiments, the hub 802 and / or bases 102, 804 and / or 806 can identify the type of patient-care device associated with it and load configuration data based on the type of the associated patient-care device (the device paired with it, inserted into, or docked into the hub 802 and / or bases 102, 804 and / or 806).

[0479] In some embodiments, the hub 802 and / or bases 102 , 804 , and / or 806 can identify the type of patient-care device associated therewith and configure the UI using HTML, CSS, JavaScript, etc. In some embodiments, the hub 802 and / or bases 102 , 804 , and / or 806 can have a distributed UI system.

[0480] The user interface described here can use the request-action framework.

[0481] Optionally, in some specific embodiments, hub 802 includes all safety-critical circuitry and software for communicating with monitoring client 1; for example, in this specific embodiment, hub 802 receives treatment parameters from monitoring client 1, and hub 802 ensures that the treatment parameters are safe for patient 2, regardless of where any safety checks are performed (e.g., on monitoring client 1). In another specific embodiment, system 800 is optionally fully fault-tolerant with respect to monitoring client 1 and can ignore commands, requests, or parameters from monitoring client 1 if, for example, independent safety checks performed therein do not meet predetermined criteria, such as a predetermined safety range for drug delivery by infusion pump 7.

[0482] Alternatively, in another specific embodiment, the scanner 120 can scan a barcode attached to the IV bag 170, the scanner 120 downloads a predetermined prescription (e.g., from the patient's personal EHR 19'), and / or the infusion pump 830 includes a predetermined prescription that is uploaded to the hub 802 when it is docked to the base 804; thereafter, in this specific embodiment and optionally, the hub 802 initiates the infusion of the IV bag 170 into the patient 2 and monitors the progress of the treatment to ensure the safety of the patient 2. Additionally, alternatively, or optionally, in this specific embodiment, the caregiver can communicate solely with the patient via the hub 802. Figure 8 The system 800 shown interacts with each other. Optionally, in some embodiments, the hub 802 uploads treatment, status, or patient information to the monitoring client 1; for example, the hub 802 can upload treatment information it receives from the infusion pump 830 or treatment information it receives from the patient's personal EHR 19' corresponding to a scanned barcode on the IV bag 170 to the monitoring client 1 for display to the user so that the user can confirm the information and store it in the monitoring client 1, etc.

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

[0484] Optionally, the monitoring client 1, other monitoring clients 4, and / or remote communicator 11 can be configured to send commands or requests to one or more of the infusion pumps 830, 810, 812 for patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148, such as a bolus dose, an infusion flow rate, a total fluid to be delivered, a start time for drug delivery, a stop time for drug delivery, or a delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be configured to send commands or requests to the bolus dispenser 814, such as a bolus dispense command for dispensing a bolus, a bolus type, a bolus dispense schedule, and / or a maximum bolus dispense standard. The maximum bolus dispense standard can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications can be obtained on demand (i.e., when necessary); however, excessive medications can be unsafe, and the maximum bolus dispense standard can prevent a patient from obtaining medication at unsafe levels, such as obtaining a predetermined amount within a predetermined time interval.

[0485] Optionally, the patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148 may also transmit data back to the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 to: determine whether an alarm or warning should be issued or sent; determine whether the treatment or condition is safe for the patient; determine whether the system 800 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11. For example, one or more of the infusion pumps 830, 810, 812 may optionally transmit to one or more of the monitoring client 1, the other monitoring clients 4, and / or the remote communicator 11 (as appropriate): upstream pressure; change in upstream pressure; pressure downstream of the patient 2; change in pressure downstream of the patient 2; presence of air in the infusion line; actual bolus delivered; actual infusion flow rate; actual total fluid delivered; actual start time of medication delivery; actual stop time of medication delivery; or actual delivery flow rate profile. In another embodiment, the pill dispenser 814 can optionally transmit data back to the monitoring client 1, other monitoring clients 4, and / or remote communicator 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule dispensed, or whether a maximum pill dispensing criteria was exceeded.

[0486] Data received from patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148 can be analyzed for any predetermined conditions that could trigger alarms and / or warnings. For example, one or more of monitoring clients 1, 4, 11 can use an increase in pressure downstream of one or more of infusion pumps 830, 810, 812 as an indication of one of the following: excessive coagulation, infiltration, occlusion, or kinking of the tubing leading to the patient; or an occlusion caused by other material within IV bag 170. In response to a sudden increase in downstream pressure, one or more of monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. Additionally or alternatively, a sudden decrease in pressure downstream of patient 2 can indicate that the tubing has become detached from the needle and / or that the needle is now removed from the patient; and in response, one or more of monitoring clients 1, 4, 11 can visually or audibly provide a warning or alarm to the user. One or more of the monitoring clients 1 , 4 , 11 can optionally send commands to one or more of the infusion pumps 830 , 810 , 812 to stop delivery of fluid in response to a sudden increase and / or a sudden decrease in pressure downstream of the patient 2 .

[0487] In some embodiments, as Figure 8 shown or combined Figure 8Each item, component, device, patient care device, base, and computing device described, whether numbered or unnumbered, 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 medication database 9 is optional, adverse drug event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of patient care devices 830, 810, 812 is optional. Similarly, in some embodiments of the present disclosure, each of system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power supply is optional.

[0488] Additionally, in some embodiments, although Figure 8 shown or combined Figure 8 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as single items, components, devices, patient-care devices, bases, or computing devices, although multiple items, components, devices, patient-care devices, bases, and computing devices are contemplated; for example, although Figure 8 8. A single pill dispenser 814 is shown in FIG, but in some embodiments, two pill dispensers 814 may be used, multiple pill dispensers 814 may be used, or any number of pill dispensers 814 may be used. Additionally or alternatively, in some embodiments, multiple bases 804 or 806 and / or multiple monitoring client bases 102 may be used.

[0489] Additionally or alternatively, while specific patient-care devices 830, 810, 812 are shown, other combinations, subsets, multiples thereof, or combinations thereof may be used. For example, in some embodiments, only the infusion pump 830 is used as a patient-care device, and in this particular example, the other patient-care devices 810, 812, 814 may be disabled, may not be present or available for use by the system, may be turned off, or may not be Figure 8 Additionally or alternatively, in some specific embodiments, only the patient-care device in use can be docked to base 804 or 806; for example, in one specific embodiment, infusion pump 830 is the only device docked to base 804, and base 804 only receives one device, e.g., infusion pump 830.

[0490] exist Figure 8In the embodiment, although the base 804 is shown as being capable of receiving several patient care devices, in other embodiments, the device base 804 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Furthermore, the recesses of the base can be unused ( Figure 8 ). Additionally, while the monitoring client base 102 is shown as being capable of receiving one monitoring client 1, in other embodiments, the monitoring client base 102 can receive two monitoring clients 1, more than two monitoring clients 1, or any number of monitoring clients 1. Additionally, alternatively, or optionally, in certain specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 830, 810, 812, 814 can be dockable, can operate undocking, and / or can be non-dockable and capable of operating as standalone patient-care devices.

[0491] Figure 8 The system 800 can use any known communication method to maintain communication within the system. For example, in some embodiments, any schedule for communication can be used, broadcast, anycast, 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 with predetermined alternative communication paths can be used, and / or adaptive networking can be used. For example, in some embodiments of the present disclosure, a weight can be assigned to each communication path, and a Dijkstra algorithm can be used to communicate between the monitoring client 1 or hub 802 and one or more patient-care devices (e.g., patient-care devices 830, 810, 812, and 814); the weights can be determined in any known manner, including based on bandwidth, signal quality, bit error rate, can be linear with respect to available data throughput or latency, and the like.

[0492] In one embodiment of the present disclosure, the facility services 8 and / or the adverse drug event network 9 may also include a medication error reduction system ("DERS"). The DERS system may 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. A soft alarm can be stopped (e.g., turned off) by a caregiver using the user interface of the infusion pump 830, the user interface 808 of the hub 802, and / or the user interface of the monitoring client 1 (and may only be an audible and / or vibrating alarm), while a hard alarm causes treatment to be stopped until the cause of the hard alarm is eliminated.

[0493] In another embodiment of the present disclosure, the DERS system may include a first set of predetermined criteria for defining soft limits and / or a second set of predetermined criteria for defining hard limits. The hard and soft limits define treatment limits, such as drug dosage limits based on size, weight, age, other patient parameters, or other criteria. A caregiver can use the user interface of the infusion pump 830, the user interface of the monitoring client 1, and / or the user interface 808 of the hub 802 to override these soft limits to start treatment even if the treatment is outside the first set of predetermined criteria, while hard limits prevent treatment from starting until the settings are changed to meet the second set of predetermined criteria for defining the hard limits.

[0494] 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 base 102 and / or 804, and / or hub 802 may include secure data classes, for example, via an API.

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

[0496] Optionally, the monitoring client 902, other monitoring clients 4, and / or the remote communicator 11 can be configured to send commands or requests, such as a bolus dose, an infusion flow rate, a total fluid for delivery, a start time for drug delivery, a stop time for drug delivery, or a delivery flow rate profile, to the stackable infusion pump 904, the stackable syringe pump 906, and / or another stackable patient-care device 908 for the patient-care device 14, 15, 16, 17, 35, 128, 904, 906, 908, 148. In some embodiments, one or more of the monitoring clients 902, 4, 11 can be configured to send commands or requests, such as a bolus dose, a bolus type, a bolus dispensing schedule, and / or a maximum bolus dispensing standard, to the bolus dispenser 128. The maximum bolus dispensing criteria may be a maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications may be obtained on demand (i.e., as needed), however, it may be unsafe to obtain medication at excessive levels, and the maximum bolus dispensing criteria may prevent a patient from obtaining medication at unsafe levels, e.g., obtaining a predetermined amount within a predetermined time interval.

[0497] Optionally, the patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 may also transmit data back to the monitoring client 902, other monitoring clients 4 and / or remote communicator 11 to: determine whether an alarm or warning should be issued or sent; determine whether the treatment or condition is safe for the patient; determine whether the system 900 is operating properly or within predetermined boundaries; and / or display the data on a display of the monitoring client 902, other monitoring clients 4 and / or remote communicator 11. For example, the stackable infusion pump 904, the stackable syringe pump 906, and / or the other stackable patient-care device 908 can optionally transmit (as appropriate) to one or more of the stackable monitoring client 902, the other monitoring client 4, and / or the remote communicator 11: upstream pressure; change in upstream pressure; pressure downstream of the patient 2; change in pressure downstream of the patient 2; presence of air in the infusion line; actual bolus delivered; actual infusion flow rate; actual total fluid delivered; actual start time of medication delivery; actual stop time of medication delivery; or actual delivery flow rate profile. In another embodiment, the bolus dispenser 128 can optionally transmit data back to the stackable monitoring client 902, the other monitoring client 4, and / or the remote communicator 11, such as the actual bolus dispensed, the actual type of bolus dispensed, the actual bolus dispensing schedule dispensed, or whether a maximum bolus dispensing threshold has been exceeded.

[0498] Data received from patient-care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 can be analyzed for any predetermined conditions that trigger alarms and / or warnings. For example, one or more of monitoring clients 902, 4, 11 can use an increase in pressure downstream of stackable infusion pump 904 and / or stackable syringe pump 906 as an indication of one of the following: excessive coagulation, infiltration, occlusion, or kinking of the tubing leading to the patient; or an occlusion caused by other material within IV bag 170. In response to a sudden increase in downstream pressure, one or more of monitoring clients 902, 4, 11 can visually or audibly provide a warning or alarm to the user. Additionally or alternatively, a sudden decrease in pressure downstream of patient 2 can indicate that the tubing has become detached from the needle and / or that the needle is now removed from the patient; and, in response, one or more of monitoring clients 902, 4, 11 can visually or audibly provide a warning or alarm to the user. One or more of the monitoring clients 902 , 4 , 11 can optionally send commands to one or more of the stackable infusion pumps 902 and / or stackable syringe pumps 906 to stop delivery of fluid in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2 .

[0499] The stackable monitoring client 902, the stackable device 908, the stackable infusion pump 904, and the stackable syringe pump 906 can be connected together in a daisy-chain fashion via connectors coupled to the top and bottom of each device. For example, the stackable syringe pump 906 can be stacked on top of the monitoring client 902 so that the bottom connector of the stackable syringe pump 906 is electrically coupled to the connector on the top of the monitoring client 902.

[0500] For example, the daisy chain may be established by electrical conductors within each of the stackable monitoring client 902, the stackable patient-care device 908, the stackable infusion pump 904, and the stackable syringe pump 906 so as to maintain continuous electrical contact between each of these devices.

[0501] Additionally or alternatively, the stackable devices 902, 908, 904, 906 may optionally maintain wireless communication with one another. For example, the stackable monitoring client 902 may detect that the daisy-chain conductor is not electrically responsive due to an internal short circuit within one of the stackable devices 902, 908, 904, 906, and the stackable monitoring client 902 may interrogate each stackable device 908, 904, 906 to determine which device is faulty; upon making this determination, the stackable monitoring client 902 may wirelessly communicate with an isolated disconnect circuit within the faulty device among the stackable devices 902, 908, 904, 906 to electrically disconnect the faulty device from the daisy-chain conductor. Additionally or alternatively, one or more of the stackable devices 902, 908, 904, 906 may be capable of warning, sending an alarm, and / or displaying a message 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 a daisy-chained wired communication link.

[0502] Additionally or alternatively, each of the stackable monitoring client 902, the stackable device 908, the stackable infusion pump 904, and the stackable syringe pump 906 can relay or retransmit information to the corresponding device above or below it in the daisy chain. For example, the stackable infusion pump 904 can transmit all data received from the stackable syringe pump 906 by buffering the data in internal memory and transmitting the information when a signal is received from the stackable patient-care device 908 indicating that the stackable patient-care device 908 is ready to receive additional data. In some embodiments, as Figure 8 shown or combined Figure 8Each item, component, device, patient care device, base, and computing device described, whether numbered or unnumbered, 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 medication database 9 is optional, adverse drug event network is optional, patient's personal EHR 19' is optional, and / or treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of patient care devices 830, 810, 812 is optional. Similarly, in some embodiments of the present disclosure, each of system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power supply is optional.

[0503] Additionally, in some embodiments, although Figure 9 shown or combined Figure 9 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as single items, components, devices, patient-care devices, bases, or computing devices, although multiple items, components, devices, patient-care devices, bases, and computing devices are contemplated; for example, although Figure 9 A single pill dispenser 128 is shown in FIG, but in some embodiments, two pill dispensers 128 may be used, multiple pill dispensers 128 may be used, or any number of pill dispensers 128 may be used.

[0504] Additionally or alternatively, while specific patient-care devices 904, 906, 908 are shown, other combinations, subsets, multiples thereof, or combinations thereof may be used. For example, in some embodiments, only the stackable infusion pump 904 is used as a patient-care device, and in this particular example, the other patient-care devices 906, 908 may be disabled, may not be present or available for use by the system, may be powered off, or may not be Figure 9908, 128, 148 may be dockable, may be operated undocked, and / or may be non-dockable and capable of operating as a standalone patient-care device.

[0505] exist Figure 9 In the embodiment of the present invention, although the stack is shown as being capable of stacking several patient-care devices, in other embodiments, the stack can receive one patient-care device, multiple patient-care devices, or any number of patient-care devices. In addition, although the stack is shown as being capable of receiving one monitoring client 902, in other embodiments, two stackable monitoring clients 902, more than two stackable monitoring clients 902, or any number of stackable monitoring clients 902 are stacked together in the system 900.

[0506] Figure 9 The system 900 can use any known communication method to maintain communications within the system. For example, in some embodiments, any schedule for communications can be used, broadcast, anycast, 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 with predetermined alternative communication paths can be used, and / or adaptive networking can be used. For example, in some embodiments of the present disclosure, a weight can be assigned to each communication path, and a Dijkstra 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); the weights can be determined in any known manner, including based on bandwidth, signal quality, bit error rate, can be linear with respect to available data throughput or latency, and the like.

[0507] See also Figure 1 、 3, 5, 7, 8, and 9, various update techniques and / or methods can be used to update the hub, base, device, infusion pump, and / or patient care device. For example, the patient care device can be connected to a computing device (in some embodiments, this can be 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) via a bus converter. In some embodiments, the bus converter converts RS232 format data to, for example, I2C format data. In some embodiments, a processor within the hub, base, device, insulin pump, infusion pump, and / or patient care device can execute an update program to control and coordinate the download of software to flash memory, such as through a mainframe processor and / or command processor. In some embodiments, the computing device can coordinate the download of software to the flash memory of the hub, base, device, insulin pump, infusion pump, and / or patient care device. Software updates obtained by the computing device can be stored in flash memory (not shown) accessible to the mainframe processor and / or command processor. In some embodiments, the software update can be a command line program that can be automatically invoked by a script process.

[0508] In some embodiments, the hub, base, device, insulin pump, infusion pump, and / or patient-care device may be a network-connected remote interface or have network-connected remote interface capabilities. This network-connected remote interface may have the ability to (but not limited to) download applications, download software updates, upload information to the respective devices, and / or send information, including (but not limited to) via a secure web-based portal and / or via email and / or via wireless communication protocols. Thus, in various embodiments, the remote interface application may run on any capable device and is not limited to so-called dedicated devices. Furthermore, in some embodiments, the remote interface may be Bluetooth-enabled or otherwise enabled to communicate, for example, using radio frequency ("RF") communication, with one or more devices, including but not limited to one or more of the following: the hub, base, device, insulin pump, infusion pump, patient-care device, Bluetooth or other communication device, patient-care device, and / or any other device.

[0509] In some embodiments, the charging station may include a charging area for a hub, base, device, insulin pump, infusion pump, and / or patient care device for a remote interface that may have a USB socket. In some embodiments, the charging station may include a USB port, and in some embodiments, a mini-USB port, to allow the charging station to receive power, which in some embodiments is used to charge the hub, base, device, insulin pump, infusion pump, patient care device, and / or remote interface via USB. Additionally and / or alternatively, the USB port may be configured to transfer data to / from the remote interface and / or hub, base, device, insulin pump, infusion pump, and / or patient care device by connecting to a computer or other device and / or other computer-type equipment. In embodiments that include a USB port, while the remote interface is being charged, the system can call a personal computer and / or web portal to check for updated software, and, if updateable software exists, can download software updates, for example, via a USB connection. These updates can then be transferred to the hub, base, device, insulin pump, infusion pump, and / or patient care device after pairing.

[0510] Thus, the user can connect the remote interface of the hub, base, 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 a web portal or otherwise. In some embodiments, this can be done during the "recharging" period of the remote interface, which in some embodiments can be done using a USB connection to a personal computer, which, in addition to charging / recharging the remote interface, can also synchronize and / or upload / download data from the personal computer, 1908, and / or web portal. At this point, the system can determine that software updates for one or more of the devices and / or for the remote interface are available. The user can select "Download Updates," and these updates can be re-downloaded to the remote interface of the hub, base, device, insulin pump, infusion pump, and / or patient care device while charging and / or when the remote interface is directly or indirectly connected to a personal computer and / or to a web portal specifically designed for the system. As described above, the remote interface is capable of communicating with a variety of devices. Thus, software updates can be transmitted to any one or more devices via the remote interface. This has many advantages including, but not limited to, only requiring a remote interface connection to a personal computer / web portal to upload data / information from all devices and / or download updates and / or applications to any one device 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 data from all devices in one location and / or the ability to download information and / or settings to any one device from a personal computer / web portal via the remote interface.

[0511] Thus, in some embodiments, because the personal computer / web portal contains all information from all devices, including but not limited to remote interfaces, a new "remote interface" can be introduced to the system at any time. This can be accomplished by connecting the new remote interface to the personal computer / web portal and downloading all information related to the system to the remote interface. In some embodiments, this may first require removing the old remote interface from the "approved devices," while in other embodiments, the system can "allow" additional remote interfaces with permission from the user. Thus, the system includes the ability to download all information and applications to any Internet-connected interface and / or remote interface capable of communicating with a device and / or capable of connecting to a personal computer and / or web portal.

[0512] This also allows the remote interface to download any application from the internet to any device in the system. Thus, in various embodiments of the system, a user can convert any device (including certain parameters, such as the ability to wirelessly communicate and connect to a personal computer and / or web portal) into a device that can control various devices (e.g., an infusion pump) and / or receive data from and / or control a CGM sensor / transmitter and / or other analytical sensors and / or other devices, such as a hub, a base, a device, an insulin pump, an infusion pump, and / or a patient care device. In some embodiments, the remote interface and / or one or more applications on the remote interface can be password protected or otherwise secured and paired with one or more devices, such as an infusion pump and / or a CGM sensor and / or one or more other devices.

[0513] In some embodiments, information about the remote interface can be uploaded and / or synchronized with another device and / or computer and / or machine, including but not limited to uploading data to an internet site (web portal) that can be password protected. Thus, the user can access the information from any device and / or download the information to any device including any device-specific applications. Thus, user information can be downloaded to any device, including but not limited to history, preferences, and the like.

[0514] Figure 10 6 is a flow chart of a method 600 for transmitting patient care parameters of a patient care device to a monitoring server according to one embodiment of the present disclosure. The method 600 includes steps 602-608. Optionally, the patient care device of the method 600 can be any patient care device disclosed herein, for example, Figure 1 、 3 , 5 or 7 patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, Figure 8 Patient care devices 14, 15, 16, 17, 830, 810, 812, 814, Figure 9 's patient care devices 14, 15, 16, 17, 904, 906, 908 or other patient care devices disclosed herein.

[0515] Step 602 establishes a communication link between the patient care device and the monitoring server. Step 604 transmits the patient care parameters to the monitoring server, for example, via a local area network and / or the Internet, via WiFi, via a monitoring client, one or more hubs or base stations, etc. Step 606 de-identifies the patient care parameters. Step 606 may be performed, for example, at Figure 1 、 3, 5, 7, 8, and / or 9 are automatically and electronically performed within the monitoring server 3. For example, the patient's name may be removed and replaced with a random serial number or other identifier that cannot be used to determine the patient's identity in the monitoring server. Step 608 stores the reverse-identified patient care parameters in the monitoring server, for example, in a database such as an SQL database, a relational database, a linked database, a cloud server, or the like.

[0516] Figure 11 is a flow chart of a method 701 for aggregating patient care parameters from a plurality of patients determined from patient care devices in a monitoring server according to one embodiment of the present disclosure. The method 701 includes steps 703-713. In some embodiments, all steps 703-713 are optional. The patient care device can be any patient care device disclosed herein, for example, Figure 1 、 3 , 5 or 7 patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, Figure 8 Patient care devices 14, 15, 16, 17, 830, 810, 812, 814, Figure 9 's patient care devices 14, 15, 16, 17, 904, 906, 908 or other patient care devices disclosed herein.

[0517] Step 703 is performed on the monitoring server (eg Figure 1 、 3 A communication link is established between the monitoring server 3) of , 5, 7, 8 or 9 and the multiple patient-care devices associated with the multiple patients. Optionally, the multiple patient-care devices can be associated with a single patient, and / or the multiple patient-care devices can be associated with different respective patients.

[0518] Step 705 transmits a plurality of patient care parameters from a plurality of patient care devices to a monitoring server. Step 707 reverse-identifies the patient care parameters, and step 709 stores the patient care parameters in the monitoring server, for example, in a database such as an SQL database, a relational database, an associative database, or the like. Step 707 can be performed automatically and / or electronically. Step 711 treats a subset of the plurality of patients using a treatment regimen. For example, a patient with hypertension can be treated with a medication designed to lower blood pressure. Step 713 analyzes a subset of the plurality of patient care parameters associated with the plurality of patients to determine the efficacy of the treatment. For example, all patients who received a blood pressure medication in step 711 can have their blood pressure compared to a blood pressure reading taken a predetermined amount of time later (e.g., 6 months) to determine whether the treatment was effective for one or more patients.

[0519] Figure 12 FIG8 is a flow chart of a method 801 for recovering a patient-care device when operation of the patient-care device is interrupted, according to one embodiment of the present disclosure. For example, the patient-care device may be unplugged from a dock, power may be interrupted, a hardware or software failure may temporarily render one or more processors or other circuits within the patient-care device unavailable, etc. Additionally or alternatively, one or more processors on the patient-care device may execute the method 801, making the patient-care device hot-swappable.

[0520] Method 801 includes steps 803-823. In some embodiments, each of steps 803-823 is optional. Step 803 receives one or more patient care parameters associated with a patient care device. The patient care device of method 801 can be any patient care device disclosed herein, for example, it can be Figure 1 、 3 , 5 or 7 patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, Figure 8 Patient care device 14, 15, 16, 17, 830, 810, 812, 814 or Figure 9 One or more of patient care devices 14, 15, 16, 17, 904, 906, 908.

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

[0522] Step 807 receives one or more operating parameters for the patient-care device. An operating parameter can be anything related to the operation of the device. For example, an operating parameter can be a speed limit for an infusion pump motor, a limit on the infusion pump speed, a wattage limit for wireless communication, a battery discharge rate or rate limit, an update frequency, etc. Step 809 stores the one or more operating parameters in a non-volatile memory of the patient-care device.

[0523] Step 811 calculates one or more additional operating parameters for the patient-care device. A calculated operating parameter is any parameter calculated to operate the patient-care device, such as a gain coefficient of a proportional-integral-derivative ("PID") control loop with an adaptive gain coefficient used in automatic gain control. Step 813 stores the one or more additional operating parameters in a non-volatile memory of the patient-care device.

[0524] Step 815 determines that operation of the patient care device has been interrupted, eg, power to the patient care device has been lost, a fault has occurred in the patient care device, a CPU brownout reset has occurred, etc. Step 817 determines that operation of the patient care device can be resumed.

[0525] Step 819 loads one or more received or calculated operating parameters into the working memory of the patient care device; and, step 821 loads the one or more patient care parameters into the working memory of the patient care device. Step 823 resumes operation of the patient care device.

[0526] Now turn Figure 13 , shows a flow chart of a method 900 for pairing a monitoring client having a user interface with a patient care device according to an embodiment of the present disclosure. The method 900 includes steps 902-912. The monitoring client of the method 900 may be Figure 1 、 3 , 5, 7 or 8 monitoring client 1 or remote communicator 11, Figure 9 Monitoring client 902, Figure 1 、 3 , 5, 7, 8 or 9 remote communicator 11, cellular phone, handheld computer, tablet computer, laptop computer, personal computer and personal digital assistant, etc. Although method 900 describes pairing between monitoring client and patient care device, in some embodiments, method 900 can be used to pair a hub (e.g., Figure 8 802 ) with patient-care devices (eg, patient-care devices 830 , 810 , 812 , and 814 ), a first patient-care device (eg, Figure 8 of the patient care device 830) and a second patient care device (e.g., Figure 8 814 ) such that a user interface of a first patient-care device can be used to control a second patient-care device and / or to monitor a system (e.g., Figure 1 、 3 , 5, 7, 8 or 9 system monitor 131) and patient care devices (e.g., Figure 1 、 3 , 5 and 7 shown in the patient care device 7, 170, 126, 128, 148, 14, 15, 16, 17 or 170 or Figure 8 Patient care device 830, 810, 812, 814, 14, 15, 16, 17 or 148 and / or Figure 9 paired with a patient-care device 904, 906, 908, 14, 15, 16, 17, or 148).

[0527] Step 902 places a monitoring client having a user interface (e.g., a display, touchscreen, display, buttons, and an accelerometer for user input) within operating range of a patient-care device. Step 904 displays the identity of the patient-care device on the user interface. The patient-care device may 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. Step 906 uses the user interface to select a patient-care device for pairing. For example, a user may touch the touchscreen of the monitoring client in step 906 to indicate selection of a patient-care device.

[0528] Step 908 pairs the patient-care device with the monitoring client. For example, pairing the patient-care device with the monitoring client can be performed using Bluetooth, Bluetooth Low Energy (IEEE 802.15.1), WiFi, infrared communication, near-field communication (NFC ISO 13157), IR communication, or optically. As will be appreciated based on this disclosure, a customized pairing protocol may also be used, which may or may not utilize a handshake sequence. Step 910 transmits patient-care parameters between the patient-care device and the monitoring client, for example, so that the patient-care device can be controlled or monitored by the monitoring client.

[0529] Step 912 optionally transmits additional patient-care parameters in an operative manner with another patient-care device through the patient-care device. In step 912, if the patient-care device is operatively connected to or in operative communication with another patient-care device, the patient-care device can act as a repeater or router so that the monitoring client can communicate with the other patient-care device. Additionally or alternatively, the patient-care device can use information from another patient-care device for its own operation, for example, an infusion pump can use a flow rate determined by a flow meter or a temperature from a temperature probe, and / or the infusion pump can relay information from the flow meter to the monitoring client. Additionally or alternatively, the monitoring client can communicate in parallel or serially with multiple patient-care devices connected to a paired patient-care device. Additionally or alternatively, in some embodiments of the present disclosure, in method 900, the monitoring client uses an intravenous line to communicate with the patient-care device. This communication can occur optically via electrical conductors embedded in or attached to the IV tubing, via using the fluid within the IV tubing as an electrical communication medium to the conductive medium, using sound waves propagating through the IV tubing, or by using the fluid within the tubing as an optical waveguide. Communication via the IV tubing can be used to establish pairing (e.g., between a monitoring client, hub, pedestal, patient-care device, and / or system monitor and one or more of the monitoring client, hub, pedestal, patient-care device, and / or system monitor) using another communication link such as Bluetooth, Bluetooth Low Energy, WiFi, etc.

[0530] In another embodiment of the present disclosure, a first communication link can be used to configure and / or initialize pairing from 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) so that the devices can be configured using a second communication link; for example, near-field communication or IR communication can be used, for example, to establish pairing between the devices using Bluetooth, Bluetooth Low Energy, or WiFi. Establishing the pairing (e.g., via near-field communication or IR communication) can request the monitoring client, the hub, the patient-care device, and / or the system monitor to request user confirmation of the device pairing (e.g., via Bluetooth pairing). In some embodiments, when a patient-care device is paired with a hub, monitoring client, and / or base, its ID and software version number are sent to the hub, monitoring client, and / or base. The hub, monitoring client, and / or base then negotiates with a server (e.g., monitoring server 3), middleware, cloud server, or other server to determine whether the software on the patient-care device is up to date. If the software is not up to date, the hub, monitoring client, base, or the patient-care device itself (e.g., directly) downloads updated software for programming the patient-care device. The patient-care device can inform the user whether the software is up to date and / or provide the user with an option on a touchscreen to optionally update the patient-care device if the software is not up to date. Establishing the paired communication link (e.g., NFC) and / or using the paired communication link (e.g., Bluetooth or Bluetooth Low Energy) can transmit updated software, ID, software version number, provide notifications, and the like. A pairing, for example, that may be used in a pump patient care device or insulin pump may be found in: (1) patent application entitled “INFUSION PUMP METHODS AND SYSTEMS” to Mandro et al., filed March 25, 2010, attorney docket I06, and having serial number 12 / 731,843, (2) patent application entitled “METHODS AND SYSTEMSFOR CONTROLLING AN INFUSION PUMP” to Bryant et al., filed April 4, 2009, attorney docket G98, and having serial number 12 / 416,662, and / or (3) patent application entitled “INFUSION PUMP ASSEMBLY” to Kamen et al., filed December 31, 2009, attorney docket G75, and having serial number 12 / 347,985, the entire contents of which are hereby incorporated by reference in their entirety.

[0531] Figure 14FIG1 is a flow chart of a method 10000 for monitoring the operation of a patient-care device using a wearable system monitor paired with the patient-care device, according to one embodiment of the present disclosure. The method 1000 includes steps 1014-1040, and various devices 1002, 1004, 1006, 1008, 1100, and 1112 can be utilized to facilitate pairing the wearable system monitor with the patient-care device in the method 1000. In some embodiments, each of steps 1014-1040 is optional.

[0532] The wearable system monitor of method 1000 may be Figure 1 、 3 , 5, 7, 8, and 9. 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 sufficient device disclosed herein. For example, a user interface of monitoring device 1002, a user interface of remote communicator 1004, a user interface of communication device 1006, a user interface of patient-care device 1008, a user interface of another patient-care device 1010, or a user interface of wearable system monitor 1012 can be used to pair the wearable system monitor of method 1000 with a patient-care device.

[0533] The patient care device of method 1000 can be any patient care device disclosed herein, such as Figure 1 、 3 , 5 or 7 patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, Figure 8 Patient care devices 14, 15, 16, 17, 830, 810, 812, 814, Figure 9 's patient care devices 14, 15, 16, 17, 904, 906, 908 or other patient care devices disclosed herein.

[0534] The system monitor of method 1000 may be used with Figure 1 System 100, Figure 3 System 300, Figure 5 System 500, Figure 7 System 700, Figure 8 System 800, Figure 9 The system 900 may be used with a single system and / or with any other sufficient system or device group disclosed herein.

[0535] Step 1014 identifies the caregiver (i.e., provider) using one or more of the following: a voice recognition algorithm, a facial recognition algorithm, a barcode, an RFID tag, near-field communication, a simple login, a secure signature, etc. For example, the identification of the caregiver in step 1040 can be performed using an onboard camera and / or microphone via a monitoring client, a monitoring client docking station, a device docking station, via a communication module, other base, or hub. Furthermore, as a safety check, the monitoring client, hub, base, or patient care device can request that the user enter in the displayed font to prevent font corruption errors. Additionally or alternatively, in some embodiments, if the device can capture and store a video after one or more failed logins or authentication attempts, the video can be sent to a middleware server for storage. Step 1016 records the caregiver's presence in one or more of the devices 1002-1012. The log entry can be stored on any of the devices 1002-1012, a patient care device as described herein, a monitoring client as described herein, a wearable system monitor as described herein, a remote communicator as described herein, and / or a hub as described herein. The logging of step 1016 can be used for caregiver compliance and diagnostic purposes, etc. For example, if a caregiver was scheduled to appear but did not show up, step 1016 can record that the caregiver did not show up at the scheduled time.

[0536] The facial recognition algorithm of step 1014 can rely on any facial features of the caregiver, such as analyzing the relative size, shape, position of the eyes, nose, chin, cheekbones, or other facial features. The facial recognition algorithm of step 1014 can use three-dimensional facial recognition, skin texture analysis, or other facial recognition algorithms. Additionally or alternatively, in some embodiments, the speech recognition algorithm of step 1014 can use a hidden Markov model, dynamic time normalization-based speech recognition, or other speech recognition algorithm.

[0537] Step 1018 detaches the wearable system monitor from the wearable base. For example, Figure 1 The system monitor 131 can be worn on the patient's wrist such that it is attached to the patient using a wristband similar to a wristwatch wristband; a portion of the wearable system monitor can be detached from a base that includes a wristband and a snap-fit ​​base member (also referred to herein as a "wearable base") into which the wearable system monitor snaps. When the wearable system monitor is detached from its base, step 1020 starts a timer. Figure 14 In the method 1000, the timer and related steps are optional.

[0538] The timer of step 1020 tracks the amount of time the wearable system monitor has been detached from its base. If a predetermined amount of time has elapsed since the wearable system monitor was detached from the wearable base, step 1022 stops the treatment. For example, the wearable system monitor of method 1000 can signal the infusion pump to stop pumping. If the treatment was interrupted, for example, after a predetermined amount of time has elapsed since the wearable system monitor was detached from its wearable base, step 1024 resumes the treatment when the wearable system monitor is re-docked.

[0539] As described above, step 1018 detaches the wearable system monitor from the wearable base. Step 1026 identifies the patient using, for example, one or more of the following: a voice recognition algorithm, a facial recognition algorithm, a barcode, an RFID tag, near-field communication, a simple login, and a caregiver entry. Step 1026 can be similar to step 1014, can utilize the same software as used in step 1014, and / or can utilize one of devices 1002-1020. However, in some embodiments, it should be noted that the patient identification process can include more than just the identification of the caregiver by using, for example, biometrics or other identifying patient characteristics. Such patient identification criteria can be used to ensure that a specific treatment is given to the correct patient and / or that a given prescription is met. Steps 1014 and / or 1026 can be performed using a key device on the patient and / or caregiver.

[0540] Step 1028 determines whether the caregiver is authorized to pair the wearable system monitor, e.g., to pair the wearable system monitor with a patient-care device. If the caregiver is not authorized, method 1000 prevents further pairing of the wearable system monitor (or edits its pairing settings). If the caregiver is authorized to pair the wearable system monitor, step 1030 allows the caregiver to select one or more patient-care devices to pair with the wearable system monitor. For example, caregiver authorization can be used to ensure that a specific treatment is given to the correct patient and / or that a given prescription is met.

[0541] A caregiver can be provided with a list of patient-care devices available for pairing on one or more user interfaces of devices 1002-1012. During step 1030, the caregiver selects a wearable system monitor (e.g., the patient's wearable system monitor of step 1018) and a patient-care device to pair together. Step 1032 pairs the wearable system monitor with the patient-care device, and step 1034 records the pairing in step 1032 in the wearable system monitor, including the caregiver and patient identities. In another specific embodiment, pairing the wearable system monitor with the patient-care device can be used for 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 light of this disclosure, any suitable pairing protocol (e.g., Bluetooth or IEEE 802.11) can be used. Additionally or alternatively, step 1034 can record the pairing in one or more of devices 1002-1012.

[0542] Step 1036 reattaches the wearable system monitor to the wearable base. Step 1038 uses the wearable system monitor to identify and authenticate the wearable base, e.g., to determine whether the wearable system monitor and the pairable base are authorized to be docked together. For example, step 1038 can ensure that the wearable system monitor is docked to the wearable base of the correct patient. For example, if the wearable system monitor is docked to the wearable base of the wrong patient, the wearable system monitor can identify the error, prevent the associated treatment from proceeding (in some embodiments) by signaling the patient-care device associated with the patient-care device to stop functioning, and provide a notification to the monitoring client (e.g., Figure 1 、 3 , 5, 7, 8 monitoring clients 1, 4 or 11, Figure 9 If treatment was interrupted, step 1024 can resume treatment, or step 1040 can treat the patient according to any updated settings 1040.

[0543] In some specific embodiments, when the caregiver is identified in step 1016 and / or the patient is identified in step 1026, the caregiver may update therapy settings, for example, on a monitoring client, a hub, a remote communicator, or on a patient-care device.

[0544] Figure 15 11 is a flow chart of a method 1100 for displaying a user interface using a user interface template according to one embodiment of the present disclosure. The method 1100 includes steps 1102 to 1132. In some embodiments, each of steps 1102 to 1132 is optional.

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

[0546] While method 1100 describes the use of a user interface template with a monitoring client, the monitoring client can be replaced with a hub, a communication module, another patient care device, or other sufficient device with a user interface. The user interface template of the user interface of method 110 provides a predefined display having specific fields for displaying patient care parameters. For example, a user interface template for an infusion pump can define specific fields for displaying on the 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 received from the infusion pump. The user interface template can include layout information, such as: instructions for how to display information; descriptions of various widgets; various widgets; graphics; labels for graphic axes; labels for displays; buttons; and / or labels for providing controls or visual information to the user about one or more patient care devices. The user interface template can be a template that describes a QT-based template and / or can use HTML or CSS.

[0547] Step 1102 identifies or selects a patient-care device for communication with a monitoring client having a user interface. For example, in step 1102, the monitoring client may automatically identify a predetermined infusion pump that has been pre-designated by the provider for treating the patient. Additionally or alternatively, in step 1102, the provider may be presented with a list of patient-care devices to select from, with information regarding the operation of the selected patient-care device displayed on the user interface of the monitoring client.

[0548] Step 1104 determines whether the patient care device has a stored user interface template. For example, an infusion pump may include a flash memory having a user interface template stored therein. If the patient care device has a stored user interface template, step 1106 transfers the stored user interface template from the patient care device to a monitoring client having a user interface. Step 1108 displays the user interface template on the user interface of the monitoring client. Step 1110 transfers patient care parameters between the patient care device and the monitoring client. Step 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 may include a space for a current infusion rate; in this example, step 1112 displays the current infusion rate (a patient care parameter) on the display using the user interface template.

[0549] If step 1104 determines that no patient care device has a stored user interface template, method 1100 determines whether the monitoring client has a user interface template for displaying patient care parameters of the patient care device; additionally or alternatively, step 11004 may issue an alert via the monitoring client and / or the patient care device. Step 1114 determines the type of patient care device. If the type is determined, step 1116 determines whether the user interface template is stored in the monitoring client based on the type of patient care device. If the user interface template exists, step 1118 displays the user interface template on the user interface of the monitoring client. Step 1120 transmits the patient care parameters between the patient care device and the monitoring client. Step 1122 displays the patient care parameters on the displayed user interface template based on the user interface template. For example, the patient care parameters, such as the infusion rate, can be displayed in a predefined area of ​​the user interface specified by the user interface template.

[0550] If the type is not determined in step 1114, or the user interface template is not present in the monitoring client based on the determined type, step 1124 displays a selectable list of a plurality of user interface templates on the user interface of the monitoring client; additionally or alternatively, step 1114 may issue a warning or alert via the monitoring client and / or the patient care device. Step 1126 allows the user to select a user interface template from the plurality of user interface templates using the user interface of the monitoring client. Step 1128 displays the user interface template on the user interface of the monitoring client. Step 1130 transmits patient care parameters between the patient care device and the monitoring client. Step 1132 displays the patient care parameters on the displayed user interface template according to the user interface template.

[0551] In some embodiments of the present disclosure, the patient care device of method 1100 may also store one or more fonts for display on a monitoring client, for example, using the user interface template described above. The fonts can be stored in any format, such as JPEG, BMP, image formats, and pre-stored fonts, and can be sent for use in a field that provides an indication of an operating parameter (e.g., instead of sending a value, an image can be sent that shows a number or value that is then displayed on the monitoring client). In some embodiments, fonts stored within the monitoring client can be used so that the value of the operating parameter is sent to the monitoring client for display within the template using the fonts stored in the monitoring client.

[0552] Figure 16 is a flow chart of a method 1134 for downloading an application for controlling a patient care device according to one embodiment of the present disclosure. Figure 16 In method 1134, although the monitoring device is described herein as an exemplary device for controlling the patient-care device, the monitoring device may be replaced and / or supplemented by a base, a hub, a communication module, a remote communicator, a communication device, and the like.

[0553] Method 1134 includes steps 1136-1146. In some embodiments, each of steps 1136-1146 is optional. Optionally, the monitoring client of method 1134 can be one of the following: Figure 1 、 3 , 5, 7, 8 monitoring clients 1, 4 or 11, Figure 9 Alternatively, the patient care device of method 1134 may be one of: Figure 1 、 3 , 5 or 7 patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, Figure 8 Patient care devices 14, 15, 16, 17, 830, 810, 812, 814, Figure 9 14, 15, 16, 17, 904, 906, 908, or other patient care devices disclosed herein. Optionally, the server of method 1134 may be Figure 1 、 3 , 5, 7, 8 or 9 monitoring server 3 one.

[0554] Step 1136 docks the patient care device into the base. For example, Figure 1 、 3 , 5 or 7 of the infusion device 7, Figure 8 Infusion device 830, 810 or 812, or Figure 9The infusion device 904 can be docked into the corresponding dock. In step 1138, the monitoring client identifies the patient care device. For example, the patient care device can transmit information such as an ID number, serial number, instructions, prescription, treatment plan, patient treatment parameters, etc. to the monitoring client, such as through a discovery protocol. The docked patient care device can store treatment information (e.g., medication dosage, infusion rate, total fluid volume, or other patient treatment parameters), each of which can be associated with or corresponding to the patient.

[0555] In step 1140, the monitoring client queries the server for an application for controlling the patient care device (e.g., for setting an infusion rate). The monitoring client downloads the application in step 1142. Communications between the monitoring client and the server can be encrypted. For example, the server can encrypt the application before sending it to the monitoring client, and the monitoring client can decrypt the application using a sufficient encryption key. Additionally or alternatively, all communications can be encrypted. The monitoring client executes the application during step 1144. In step 1146, the monitoring client communicatively and operably connects to the patient care device through the application by executing the application on one or more processors. The monitoring client can place the application in a sandbox (as described below). In one such embodiment, the application includes a set of operable processor-executable instructions configured to be executed by one or more processors on the monitoring client. The application can include instructions for, for example, utilizing Figure 15 The user interface template of method 1100 displays user interface instructions on a display of a monitoring client. Additionally or alternatively, in some embodiments, the application can be used to control a patient-care device by optionally sending parameters or values ​​to the patient-care device, such as a bolus dose, an infusion flow rate, a total fluid for delivery, a start time for drug delivery, a stop time for drug delivery, a delivery flow rate profile, a bolus dispensing command for dispensing a bolus, a bolus type, a bolus dispensing schedule, and / or a maximum bolus dispensing standard.

[0556] Figure 17 is a flow chart of a method 1200 for ensuring data integrity when transmitting data (e.g., a request) for a patient care device according to one embodiment of the present disclosure. The method 1200 includes steps 1202-1222. In some embodiments, each of steps 1202-1222 is optional. The patient care device of the method 1200 can be any patient care device disclosed herein, for example, Figure 1 、 3 , 5 or 7 patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, Figure 8Patient care devices 14, 15, 16, 17, 830, 810, 812, 814, Figure 9 's patient care devices 14, 15, 16, 17, 904, 906, 908, or other patient care devices disclosed herein.

[0557] Alternatively, the request may originate from any authorized, authenticated and / or identified monitoring client, e.g. Figure 1 、 3 , 5, 7 or 8 monitoring clients 1 or 4, Figure 1 、 3 , 5, 7, 8 or 9 of the remote communicator 11, a cellular phone, a handheld computer, a tablet computer, a laptop computer, a personal computer and a personal digital assistant, etc.

[0558] Step 1202 uses the user interface of the monitoring client to submit a request for a patient care device. For example, using Figure 1 The user submits an infusion rate request to the infusion pump 7 via the touch screen of the monitoring client 1. In some embodiments, the request may optionally be parameters related to the patient care device, such as a bolus dose, an infusion flow rate, a total fluid for delivery, a start time for drug delivery, a stop time for drug delivery, a delivery flow rate profile, a bolus dispensing command for dispensing a bolus, a bolus type, a bolus dispensing schedule, and / or a maximum bolus dispensing standard.

[0559] Step 1204 is optional and displays a "pending request" on the user interface of the monitoring client. Step 1206 formats the request to the patient-care device. For example, step 1206 may prepare the request so that it meets the communication requirements of the patient-care device.

[0560] Step 1208 determines a check value for the request. For example, a cyclic redundancy check (CRC) algorithm is used to determine the check value corresponding to the request. The check value calculated by the CRC depends on the request. Changing one bit of the request will also change the check value calculated by the CRC algorithm. Similarly, changing several bits will also change the check value. Additionally or alternatively, in other embodiments, a parity bit (even or odd) or other data integrity check may be used.

[0561] Step 1210 appends a checksum value to the request. Step 1212 is optional, and step 1212 requests confirmation from the user to transmit the request using the user interface. The request for confirmation can be a pop-up dialog box on the touch screen that displays "Confirm 90 ml / hr infusion rate?" with a box for selecting "Confirm." The text and format shown in step 1212...

Claims

1. A system for electronic patient care, the system comprising: a gateway configured to provide at least one of: routing functions, medical device software updates, and network services; as well as A medical device is configured to communicate in an operable manner with the gateway using the network service.

2. The system according to claim 1, wherein: The gateway is a web server of the web service, and the medical device is a client of the web service.

3. The system according to claim 1, wherein: The web service is a transaction-based web service.

4. The system according to claim 1, wherein: The medical device is an infusion pump.

5. A medical device comprising: Transceiver; as well as At least one processor is configured to be coupled with the transceiver to communicate via the transceiver, wherein the at least one processor is configured to communicate with a network service that is in operable communication with the transceiver.

6. The device according to claim 5, wherein: The medical device is configured as a network client of the network service.

7. The device according to claim 5, wherein: The web service is a transaction-based web service.

8. The medical device according to claim 5, wherein: The medical device is an infusion pump.

9. A method for communicating between a medical device and a gateway, the method comprising: establishing communication between the medical device and the gateway; establishing a network service between the medical device and the gateway; as well as The network service is used to communicate between the medical device and the gateway.

10. The method according to claim 9, wherein: The gateway is a network server for the network service.

11. The method according to claim 9, wherein: The medical device is a network client and the network service is a network client.

12. The method according to claim 9, wherein: The gateway routes data for the medical device, wherein the data is transmitted between the medical device and the gateway using the network service.

13. A system for electronic patient care, the system comprising: a first medical sensor configured to be coupled to a patient and to measure a first physiological parameter of the patient; a second medical sensor configured to couple to the patient and measure a second physiological parameter of the patient; as well as A medical device configured to operatively receive the measured first and second physiological parameters from the first and second medical sensors, wherein the medical device is configured to: detecting a first pattern using the measured first physiological parameter; detecting a second pattern using the measured second physiological parameter; and When the first and second patterns are detected within a predetermined amount of time relative to each other, it is determined that a medical condition exists.

14. The system according to claim 13, wherein: The medical device is configured to detect the first and second patterns regardless of the magnitude of the measured first and second physiological parameters.

15. The system of claim 13, wherein: The medical device is configured to detect the first pattern and the second pattern regardless of measured starting values ​​of the first and second physiological parameters.

16. The system of claim 13, wherein: The first pattern is a trend.

17. The system of claim 16, wherein: The medical device is configured to detect the first pattern regardless of a starting value of the measured first physiological parameter.

18. The system of claim 16, wherein: The second mode is a second trend.

19. A system for electronic patient care, the system comprising: a first medical sensor configured to be coupled to a patient and to measure a first physiological parameter of the patient; a second medical sensor configured to couple to the patient and measure a second physiological parameter of the patient; a medical device configured to operatively receive the measured first and second physiological parameters from the first and second medical sensors and to transmit the measured first and second physiological parameters; as well as A server in operable communication with the medical device, wherein the server is configured to: detecting a first pattern using the measured first physiological parameter; detecting a second pattern using the measured second physiological parameter; and When the first and second patterns are detected within a predetermined amount of time relative to each other, it is determined that a medical condition exists.

20. The system of claim 19, wherein: The server is configured to detect the first pattern and the second pattern regardless of the measured magnitudes of the first and second physiological parameters.

21. The system of claim 19, wherein: The server is configured to detect the first pattern and the second pattern regardless of measured starting values ​​of the first and second physiological parameters.

22. The system of claim 19, wherein: The first pattern is a trend.

23. The system of claim 22, wherein: The server is configured to detect the first pattern regardless of a starting value of the measured first physiological parameter.

24. The system of claim 22, wherein: The second mode is a second trend.

25. An RFID tag, comprising: an antenna configured to receive an interrogation signal; a rectifier circuit configured to condition the interrogation signal to power the RFID tag; a modulation circuit configured to modulate the antenna using the interrogation signal for communication; Read memory location and corresponding read bit; Write memory location and corresponding write bit; a processor configured to receive power from the rectifier circuit, the processor configured to perform processing associated with the read memory location when the corresponding read bit is set to true, and further configured to perform processing associated with the write memory location when the corresponding write bit is set to true; as well as A measurement component is in operable communication with the processor to measure at least one physiological parameter.

26. A system, comprising: interfaces into medication error reduction systems; as well as A field editor configured to edit a field of a medication entry of the medication error reduction system, wherein the field editor is configured to prompt a user to enter a new value in a new field if a predetermined value is entered into the field.

27. A medication error reduction editing system, the system comprising: interfaces into medication error reduction systems; as well as A field editor is configured to edit a field of a medication entry of the medication error reduction system, wherein if a predetermined value is entered into the field, the field editor prompts a user to enter in a new field.

28. The system of claim 27, wherein: The predetermined value of the field is a predetermined care area.

29. A system, comprising: interfaces into medication error reduction systems; Interfaces into continuous quality improvement systems; as well as A field editor is configured to edit a field of a medication entry of the medication error reduction system, wherein the field editor is configured to use data within the continuous quality improvement system to inform a user about information corresponding to the field.

30. The system of claim 29, wherein: The notification is the percentage of values ​​entered into the field that were overturned by the caregiver.

31. The system of claim 29, wherein: The notification is a suggestion for a value to be entered into the field, the value being the value most frequently entered into the field as determined using the continuous quality improvement system.

32. A system comprising: interfaces into medication error reduction systems; as well as A field editor is configured to edit a field of a medication entry of the medication error reduction system, wherein the field editor is configured to suggest a standard value to be entered when a user attempts to enter a predetermined value into the field.

33. A system comprising: a first interface configured to connect into a medication error reduction system; a second interface configured to connect to a continuous quality improvement system; as well as A field editor configured to edit a field of a medication entry of the medication error reduction system using the first interface, wherein the field editor is configured to provide data from the continuous quality improvement system corresponding to the field to a user using the second interface.

34. A system comprising: interfaces into medication error reduction systems; as well as A field editor is configured to edit a field of a medication entry of the medication error reduction system using the interface, wherein the field is an end point of an infusion action process.

35. A system comprising: interfaces into medication error reduction systems; as well as A field editor is configured to edit a field of a medication entry of the medication error reduction system using the interface, wherein the field is an indication that the medication should still be delivered despite an error in a medical device delivering the medication.

36. A system comprising: interfaces into medication error reduction systems; as well as a field editor configured to edit fields of a medication entry of the medication error reduction system using the interface; as well as A medical device simulator is configured to simulate a medical device using the edited fields of the medication entry of the medication error reduction system.

Images