Systems, methods and devices for electronic patient care

Abstract

Disclosed are systems, methods and devices for electronic patient care, in particular an electronic patient monitoring system, which includes: a first module monitoring client, which receives and stores patient-related information; a second module, which receives treatment orders and sends them to the first module; and a communication device, which receives the treatment orders and sends them to the monitoring client, the monitoring client being used to: obtain drug information related to the treatment order from a second database; determine whether a first parameter of the patient is outside a predetermined range; when it is outside the predetermined range, request the device to perform an unscheduled reading to determine a third parameter of the patient, and verify the authenticity of the second parameter by using the third parameter; determine whether the treatment order must be confirmed by the second module communication device based on the drug information, the values ​​of the first and second parameters; and send a pre-established message confirming the acceptability of the drug order from the first module monitoring client to the second module communication device for display on a user interface.

Description

[0001] Divisional application

[0002] This application is a divisional application of the Chinese patent application with application number 201380072039.8. The application date of the above application 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 non-provisional application, which claims the benefit of U.S. Provisional Patent Application No. 61 / 740,474 (Agent 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, which is 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. I97), published on July 19, 2012, and

[0012] PCT Application No. PCT / US11 / 66588, filed on 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 entirety.

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

[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 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. I97), published on July 19, 2012, is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, filed on January 21, 2011, and entitled Electronic Patient Monitoring System, now U.S. Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), published on December 22, 2011, which claims a prior art patent application entitled Electronic Order Intermediation System for a Medical Device Facility U.S. Provisional Patent Application No. 61 / 297,544 (Attorney Docket No. H53); and

[0022] PCT Application PCT / US11 / 66588, filed on December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now International Publication 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, which is 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 No. 13 / 900,655, filed on May 23, 2013, and entitled System, Method, and Apparatus for Electronic Patient Care, which is now U.S. Publication No. US-2013-0317837-A1 (Agent Docket No. K66) published on November 28, 2013, which claims priority to and the benefit of U.S. Provisional Patent Application No. 61 / 651,322 (Agent Docket No. J46), filed on May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, both of which are hereby incorporated by reference in their entirety.

[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 (attorney docket number K66WO), filed on May 23, 2013, and entitled System, Method, and Apparatus for Electronic Patient Care, which claims priority to and the benefit of U.S. Provisional Patent Application No. 61 / 651,322 (attorney docket number J46), filed on May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, both of which are hereby incorporated by reference in their entirety.

[0030] PCT Application No. PCT / US13 / 42350 is also a continuation-in-part application, which claims priority 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 and entitled Apparatus for Infusing Fluid (attorney docket number 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 on 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 Titled 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 number K50WO); and

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

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

[0065] Providing patient care in a hospital generally 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 the treatment of a given patient. While there are systems designed to facilitate the care process, such as systems including 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 a number of 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 input module (e.g., a fixed or portable monitoring client), the second order input 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 oxygen, respiratory rate, or ventilation. The first module may also be configured to receive information about pre-stored parameters related to the patient from a first database (e.g., an EHR database containing patient-related information), the parameters including patient condition parameters, such as drug allergy or sensitivity history, other currently taken medications currently in the patient's tissue, age, weight, height, renal or liver function. The first module may also be configured to obtain drug information about the prescribed medication and / or pre-stored medication from a second database (e.g., a drug information database), such as known drug interactions, 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 the received pre-stored patient condition parameters with known normal ranges, and to establish a table of patient condition parameters that are found to be outside the normal range. The first module can then compare the table of patient condition parameters with a table of corresponding parameters obtained from a drug 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 sending to the second (order input) module. These messages can include, for example, warnings to the user of the second module that are appropriate for the specific medication prescribed, the patient's pre-stored medications, and the patient's current and pre-stored medical conditions. Optionally, once the second module has received the warning and the user of the second module has confirmed the warning through an input signal from the user interface, further repetition of the warning can be avoided.

[0067] In other embodiments, the electronic patient care system may provide the user with editable default values ​​derived from standard medications and dosing instructions obtained from a drug information database, and may 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 by the user.

[0068] In other embodiments, the first module or other modules of the electronic patient care system can also be used to identify the ordered medication to be delivered to the patient's bedside (by 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 treatment, such as an infusion pump or a pill dispenser, through a wired or wireless communication link. In the case of an infusion pump, the first module or another connected module can provide patient treatment parameters (for example, infusion settings including infusion rate or infusion pressure) to the infusion pump, and receive various operating parameters from the infusion pump, such as whether there is air in the infusion line, the amount of solution remaining in the 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, responding by signaling the mechanical occlusion device to occlude the IV line, and / or directly alerting a health care provider or other person to the abnormality through an alarm contained in the first module or by sending an alarm to the second module. In yet another embodiment, the first module may also be configured to communicate with various patient care devices for monitoring patient conditions and determining patient condition parameters, such as blood pressure monitors, ECG monitors, pulse oximetry monitors, and temperature monitors, etc. The monitored parameters are monitored and / or recorded by the mobile device and / or recorded in the EMR. In some cases, the first module may be programmed to issue a warning to the patient or other person when the monitored patient condition parameter falls outside a predetermined range. In some embodiments, the first module may send a signal to the monitoring client to perform an unplanned measurement through the patient care device in order to obtain another patient condition parameter. The first module may communicate with various health care providers at various locations, and in one embodiment, the first module is able to notify the patient to whom it is assigned of an abnormality and recommend corrective actions, such as by an audible warning 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 download device. 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 at least one liquid corresponding to the prescription order. The data download device 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 may be in operable communication with a data download device, and the compounding robot may instruct the data download device to download the prescription order to a memory of the micropump. The data download device may 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 a patient care device. The hub includes an operating system (which can be implemented as a processor that executes software) and a sandbox component (which can be implemented as a processor that executes software). The operating system component is configured to access at least one of a hardware resource of the hub and a software resource 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. The patient care device may be one or more of: an infusion pump, a pill dispenser, a micro pump, 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 identification 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 a hardware resource and a software resource. The hub is further configured to identify the patient care device and execute an application for monitoring the patient care device. The hub executes an application within a sandbox component so that the application accesses at least one of the hardware resource and the software resource 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 an application from a 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 a hardware resource of the monitoring client and a software resource of the monitoring client. A sandbox component is configured to control access to at least one of the hardware resource and the software resource. 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 an application within the sandbox component such that the application accesses at least one of the hardware resource and the software resource 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 a patient-care device and download an application from a server associated with the identifier. The monitoring client may be further configured to receive an identifier from a patient-care device and update an application from a 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 a hardware resource and a software resource. 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 an application within the sandbox component such that the application accesses at least one of the hardware resource and the software resource 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 micro pump, 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 a patient-care device and download an application from a server associated with the identifier. The monitoring client may be further configured to receive an identifier from a patient-care device and update an application from a 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 a patient and a patient care device (e.g., an infusion pump). The hub is also configured to download at least one treatment parameter (e.g., an infusion medication and / or an infusion rate or rate curve, 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 a voice using voice recognition software coupled with a microphone, reading a face using facial recognition software coupled to a camera, reading a biometric parameter of a biometric reading, reading an identifier, and reading a barcode read by a barcode reader. In a specific embodiment, the hub may download 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 a patient and a patient care device (e.g., an infusion pump). The monitoring client is also configured to download at least one treatment parameter (e.g., an infusion medication and / or an infusion rate or rate curve, etc.) from the electronic medical record and program the patient care device with 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 a voice using voice recognition software coupled to a microphone, reading a face using facial recognition software coupled to a camera, reading a biometric parameter of a biometric reading, reading an identifier, and reading a barcode read by a barcode reader. In a specific embodiment, the monitoring client may download 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 operably 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 a monitoring client, and wherein the monitoring client communicates operably with the patient-care device via a cable to the base and the docked patient-care device by wirelessly transmitting at least one patient-care parameter with the monitoring client base.

[0092] In another embodiment, the monitoring client operatively transmits 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 utilizes wireless communication with the device base to operably transmit at least one patient care parameter when the monitoring client determines at least one of the following situations: 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 communicates at least one patient-care parameter with the patient-care device.

[0096] In another embodiment, the monitoring client wirelessly transmits at least one patient-care parameter to the patient-care device in an operable manner when the monitoring client determines at least one of the following situations: 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 also include a cable operably 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 micro pump, an ECG monitor, a blood pressure monitor, a pulse oximeter and a carbon dioxide monitor, 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 to dock the patient-care device to the device base, and to receive the monitoring client to dock 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 at least one patient-care parameter; and a device base configured to receive the patient-care device to dock 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 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 at least one patient care parameter; and a device base configured to receive the patient care device to dock the patient care device to the device base. The hub can be inserted into the device base to establish a communication link between the two. The system can also include a monitoring client that is in operable communication with the hub to receive at least one patient care parameter. The patient treatment parameter can be operably transmitted to the hub, and the hub transmits the patient treatment 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 therapy 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 prior to 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, which is suitable for monitoring at least one patient parameter; a monitoring client, which communicates 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, which is 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 monitor, a blood pressure monitor, a pulse oximeter monitor, and a carbon dioxide 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 bar code disposed on a wristband. The unique patient identifier may be encoded on an RFID tag (e.g., an RFID reader) coupled to the wristband. The patient information includes a patient condition or a patient care parameter. The unique patient identifier may be operable to be sent to a 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 a predetermined criterion 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 order may be a medication order, and the monitoring server may be adapted to determine whether the new 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 order meets the another predetermined criterion. The monitoring server may be configured to send a warning to the monitoring client when the new 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 a monitoring client and a 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 detached from the monitoring client.

[0120] In another embodiment, the system further includes 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 the data from the plurality of databases for downloading the data to the monitoring client. Optionally, in a particular embodiment, the monitoring client may transmit at least one patient parameter to the monitoring server. In a particular embodiment, the patient parameter may be one or more of the following and / or may include at least one of the following: a treatment progress of an infusion pump, an electrocardiogram signal, a blood pressure signal, a pulse oximeter signal, a capnometer 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 also include 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 therapy data from an attached device.

[0131] The monitoring server may be configured to query the electronic health record database to receive patient information therefrom. 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 medications, medication classes, medication allergy history, and sensitivities.

[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 multiple patients on a display; displaying at least one patient parameter associated with a patient among the multiple patients on the display; displaying at least one warning associated with the patient on the display; and, selecting the patient from the multiple patients.

[0135] In some specific embodiments, the method may also 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 also includes one or more databases accessible to the monitoring client, the one or more databases allowing at least one of the following: i.e., centralized storage of patient information, and / or downloading of information that can be used in the treatment of patients associated with the monitoring client.

[0139] In yet another specific embodiment, the communication interface is further configured to perform fault checks to perform at least one of: evaluating data integrity of communications with a patient-care device, evaluating whether the monitoring client is functioning properly, evaluating whether the patient-care device is functioning properly, and / or evaluating whether the communication interface is functioning 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 to 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 convert communication signals from the 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 by the hub, the one or more databases allowing at least one of the following: i.e., centralized storage of patient information, and / or downloading of information that can be used in the treatment of patients associated with the hub.

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

[0144] In yet 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 the following: i.e., 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 yet another specific embodiment, the communication interface is further configured to perform fault checks to perform at least one of: evaluating data integrity of communications with a patient-care device, evaluating whether the monitoring client is functioning properly, evaluating whether the patient-care device is functioning properly, and / or evaluating whether the communication interface is functioning properly.

[0148] In one embodiment, a patient-care device includes a body, a recess in 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 in the recess.

[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; a transceiver coupled to the patient-care device interface, the transceiver configured to provide communication between the processor and the patient-care device. In some specific 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; a transceiver coupled to the patient care device interface, the transceiver configured to provide communication between the processor and the patient care device. In some specific 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; a transceiver coupled to the patient-care device interface, the transceiver configured to provide communication between the patient-care device and another device. In some specific 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 a connector.

[0153] In yet another embodiment, an electronic patient care system comprises: a first module configured to receive and store information related to a patient, the information comprising data related to a first parameter of the patient measured by a device connected to the patient and data related to a second parameter of the patient received from a first database containing information about the patient; and a second module configured to receive a medication 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 about 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 about 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 impact 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, the patient care device includes a first communication link and a second communication link; and the base includes the first communication link and the second communication link. When the patient care device is within a predetermined range of the base, the patient care device and the base are paired using the first communication link, and after pairing, the second communication link is used to maintain communication. Pairing using the first communication link can be pairing the patient care device and the base for the second communication link. The first communication link can be near field communication, and the second communication link can be Bluetooth, low-power Bluetooth, WiFi, or other communication links.

[0158] In another embodiment, the patient-care device includes a first communication link and a second communication link; and the 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 after pairing, the second communication link is used to maintain communication. Pairing using the first communication link can be pairing the patient-care device and the monitoring client for the second communication link. The first communication link can be near field communication, and the second communication link can 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. The attachable electronic components include 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 on 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 a 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 operating distance of a patient-care device (e.g., an infusion pump); displaying an identity of the patient-care device on the user interface; using the user interface to select a patient-care device to be paired; 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 additional patient-care parameters, such as to the monitoring client and / or hub, via the patient-care device in an operative manner with another patient-care device.

[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 to 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 patient-care devices.

[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 be coupled to a pole. An adapter can be coupled to the base. The adapter can include at least one electronic coupler for enabling a patient-care device to be in operable communication with 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 the monitoring client.

[0184] In another embodiment, the method implemented by 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 includes 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 includes: initiating treatment of the patient using the monitoring client.

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

[0190] In another embodiment, the method implemented by a set of operable processor-executable instructions, which also includes using a monitoring client to initialize treatment of a patient, also includes: using a hemodialysis system as a basic device to treat the patient.

[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 includes 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 also 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 the 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 higher than the first predetermined threshold.

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

[0201] In another embodiment, the method implemented by a set of operable processor-executable instructions includes causing the monitoring client to enter a headless state when the link quality value drops below a first predetermined threshold, and also includes leaving the headless state when the link quality value is higher than 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 a monitoring client and a base device using a 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 when necessary; using the base device to generate a configuration file; using the first communication link to transmit the configuration file from the base device to the monitoring client; 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 a second communication link between the monitoring client and the base device according to the configuration file.

[0204] In another embodiment, the method implemented by a set of operable processor-executable instructions includes: when the 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, the message requesting the user to move the monitoring client closer to the above-mentioned base device.

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

[0206] In another embodiment, the method implemented by a set of operable processor-executable instructions configured to be executed by a processor includes: transmitting data between the monitoring client and the base device as long as the 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 to above the predetermined threshold; and exiting the headless state if the link quality value has returned to above the predetermined threshold.

[0207] In another embodiment, the method implemented by a set of operable processor-executable instructions configured to be executed 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 to above a 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 to above a 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 the interface program 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 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, 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 a hub, a base, and a 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 perform at least one of the following: establishing a first communication link between the monitoring client and the base device via the physical connection; updating interface programs on the monitoring client and the base device via the first communication link; and establishing 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 basic device. In one embodiment of the present disclosure, the second communication link transmits data from the basic device to the monitoring client. In one embodiment of the present disclosure, the monitoring client uses the second communication link to receive data. In one embodiment of the present disclosure, the monitoring client is configured to display data transmitted from the basic device. In one embodiment of the present disclosure, the monitoring client is configured to initialize treatment for a patient. In one embodiment of the present disclosure, the basic device is configured to treat a patient. In one embodiment of the present disclosure, the basic 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 device. In one embodiment of the present disclosure, the communication link between the monitoring client and the base device is wireless. In one embodiment of the present disclosure, the base device 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 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 the link quality value drops 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 the 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 basic 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 basic device is configured to leave the headless state when the link quality value is higher than a second predetermined threshold 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 via 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 via 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 a 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. The memory has a set of processor-executable instructions operable therein, the set of processor-executable instructions operable therein configured 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 a base device for storage in the base device; (8) store errors or operating parameters for transmission to a 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 flow chart of a method for maintaining communications 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 flow chart of a method for maintaining communications 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 flow chart of a method for maintaining communications 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 dock 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] Fig. 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] Fig.10 is a flow chart 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] Fig.11 is a flow chart 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] Fig.12 is a flow chart 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] Fig.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] Fig.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] Fig.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] Fig.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] Fig.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] Fig.18 is a block diagram of an electronic patient care system according to yet another embodiment of the present disclosure;

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

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

[0244] Fig.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] Fig. 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] Fig.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] Fig.24 An embodiment according to the present disclosure is shown Fig.23 A side view of an electronic patient care system;

[0248] Fig.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] Fig.26 An electronic patient-care system according to yet another embodiment of the present disclosure is shown, the electronic patient-care system having a modular infusion pump docked into a base along a common horizontal plane, and the base including a monitoring client having a retractable user interface;

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

[0251] Fig.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] Fig.29 Another embodiment according to the present disclosure is shown Fig.28 A side view of an 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] Fig.33 shows an infusion pump and a base coupled to a pole according to one embodiment of the present disclosure;

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

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

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

[0258] Fig.37 A square hub with several connectors is shown according to one embodiment of the present disclosure;

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

[0260] Fig.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] Fig.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] Fig.41 An electronic patient-care system having a hub coupled to a pole is shown according to another embodiment of the present disclosure;

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

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

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

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

[0267] Fig.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] Fig.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] Fig.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] Fig.49 According to another embodiment of the present disclosure Fig.48 A close-up view of the handle of an electronic patient care device;

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

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

[0273] Fig.52 An electronic patient-care system prepared for transport is shown according to another embodiment of the present disclosure;

[0274] Fig.53An electronic patient care system having a stackable patient care device according to another embodiment of the present disclosure is shown;

[0275] Fig.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] Fig.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] Fig.56 showing a perspective view of a clutch system according to another embodiment of the present disclosure, the clutch system having a release handle for frictionally gripping to a lever;

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

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

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

[0281] Fig.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] Fig.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] Fig.62 is a process diagram illustrating several stages of electronic patient care according to one embodiment of the present disclosure;

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

[0285] Fig.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 Fig.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] Fig.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 Fig.71 Timing diagram of

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

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

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

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

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

[0295] Fig.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 Fig.79 Timing diagram in ;

[0297] Fig.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 Fig.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] Fig.90 A block diagram showing the circuitry of an embodiment of a hub according to one embodiment of the present disclosure;

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

[0302] Fig.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] Fig.93 A block diagram showing the circuitry of an embodiment of a hub according to one embodiment of the present disclosure;

[0304] Fig.94 A block diagram showing a circuit of a communication module according to an 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 according to several embodiments of the present disclosure are shown;

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

[0307] Fig.102 A block diagram showing a battery pack according to one embodiment of the present disclosure;

[0308] Figure 103-104 shows another embodiment of the circuit of the base according to another embodiment of the present disclosure;

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

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

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

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

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

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

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

[0316] Fig.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] Fig.128 A patient wristband according to one embodiment of the present disclosure is shown, with an RFID tag attached;

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

[0320] Fig.130 A near field antenna according to one embodiment of the present disclosure is shown;

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

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

[0323] Fig.133 A list of occlusion situations that can be displayed on a monitoring client according to an embodiment of the present disclosure is shown;

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

[0325] Fig.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] Fig.136is an illustration of a display screen on a portable monitoring client of a health care provider 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] Fig.137 is an illustration of a display screen on a portable monitoring client of a health care provider showing data entry fields for a medication prescription for use with an IV infusion pump according to one embodiment of the present disclosure;

[0328] Fig.138 is an illustration of a display screen on a portable monitoring client of a health care provider showing a risk prediction and a suggested course of action associated with a prescribed medication generated by the monitoring client according to one embodiment of the present disclosure;

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

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

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

[0332] Fig.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] Fig.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 in accordance with one embodiment of the present disclosure;

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

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

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

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

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

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

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

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

[0342] Fig.152 is a block diagram illustrating a sensor 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] Fig.154 is a flowchart illustrating a method for updating an interface program according to one embodiment of the present disclosure;

[0345] Fig.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] Fig.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] Fig.157 is a flow chart 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, the following system, which has one or more patient care devices, which are communicatively connected to a monitoring client. The patient care device may include any number of different functions, and / or may be produced by different manufacturers. In a type of such case, the communication interface between a client monitoring station and various different patient care devices allows discovery and protocol conversion and various other functions, such as power supply, compliance, and user interface, just to name a few examples. 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, a sonogram, an electrocardiogram monitor, a blood pressure monitor, a pulse oximeter, a carbon dioxide monitor, a drip counter, a flow meter, 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 on February 9, 2007 and entitled Fluid Delivery Systems and Methods, now U.S. Publication No. US-2007-0228071-A1, published on October 4, 2007 (Attorney Docket No. E70); U.S. Patent Application No. 11 / 704,896, filed on February 9, 2007 and entitled Pumping Fluid Delivery Systems and Methods Using Force Application Assembly, now U.S. Publication No. US-2007-0219496, published on September 20, 2007 (Attorney Docket E71); U.S. Patent Application No. 11 / 704,886, filed on February 9, 2007 and entitled Patch-Sized Fluid Delivery Systems and Methods, now U.S. Publication No. US-2007-0219481, published on September 20, 2007 (Attorney Docket No. E72); U.S. Patent Application No. 11 / 704,897, filed on February 9, 2007 and entitled Adhesive and Peripheral Systems and Methods for Medical Devices, now U.S. Publication No. US-2007-0219597, published on September 20, 2007 (Attorney Docket No. E73); 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 Assembly, now U.S. Publication No. US-2009-0275896, published on November 5, 2009 (Attorney Docket No. G77); U.S. Patent Application No. 12 / 347,984, filed on December 31, 2008 and entitled Pump Assembly With Switch, now U.S. Publication No. US-2009-0299289, published on December 3, 2009 (Attorney Docket No. G79); U.S. Patent Application No. 12 / 249,882, filed on October 10, 2008 and entitled Infusion Pump Assembly, now U.S. Publication No. US-2010-0094222, published on April 15, 2010 (Attorney Docket No. F51); U.S. Patent Application No. 12 / 249,636, filed on October 10, 2008 and entitled System and Method for Administering an Infusible Pump Assembly Fluid, now U.S. Publication No. US-2010-0094261, published on April 15, 2010 (Attorney Docket No. F52); U.S. Patent Application No. 12 / 249,621, filed on October 10, 2008 and entitled Occlusion Detection System and Method, now U.S. Publication No. US-2010-0090843, published on April 15, 2010 (Attorney Docket No. F53); U.S. Patent Application No. 12 / 249,600, filed on October 10, 2008 and entitled Multi-Language / Multi-Processor Infusion Pump Assembly, now U.S. Publication No. US-2010-0094221, published on April 15, 2010 (Attorney Docket No. F54); U.S. Patent No.8,066,672, issued on November 29, 2011 and entitled An Infusion Pump Assembly with a Backup Power Supply (Agent File No. F55); U.S. Patent No. 8,016,789, issued on December 13, 2011 and entitled Pump Assembly with a Removable Cover Assembly (Agent File No. F56); U.S. Patent No. 7,306,578, issued on December 11, 2007 and entitled Loading Mechanism for Infusion Pump (Agent File No. C54). The technology can be used to allow seamless communication and fail-safe operation. Based on this disclosure, many other features, functions, and applications will become apparent. .

[0349] General Overview

[0350] As described above, the process of providing comprehensive care to patients (e.g., prescribing and delivering medications) is associated with a number of significant problems. For example, there is a high probability that critical information will not be properly communicated, treatment decisions will be made without ready access to complete information, and / or delays in the implementation of prescriptions will occur due to unnecessary duplication and inefficient processes.

[0351] In more detail, medical errors may cause hundreds of deaths, and may only injure tens of thousands or even millions of people every year in the United States. Hospitals under financial pressure may encounter an increased incidence of medication errors. The drugs associated with the most dangerous errors include insulin, anesthetics, heparin and chemotherapy drugs. The sources of medication errors include taking the wrong medication, taking the wrong concentration of medication, delivering medication at the wrong ratio, or delivering medication by the wrong path (medication can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, in the eye or ear, intrathecally, intraperitoneally or even intravesically). Even with the correct prescription and correct label, medication may still be taken incorrectly due to illegible handwriting, miscommunication of prescription medications, and mispronunciation of medications with similar names. The trend of using electronic medical records ("EMR") and barcode systems for medications has shown that the incidence of medication errors can be reduced. For example, an EMR system can facilitate computerized physician order entry ("CPOE") and mark prescriptions that do not match the patient's diagnosis, allergies, weight and / or age. However, these systems have not been widely adopted, and their implementation can result in significant delays and inefficiencies in the process of prescribing, preparing, and taking medications.

[0352] Additionally, a significant portion (e.g., up to 1 / 3) of all medication errors that result in significant harm involve medication infusion devices such as infusion pumps. The wrong medication may be administered, the wrong parameters (e.g., drug concentration or injection rate) may be entered, or existing infusion parameters may be incorrectly changed. Almost half of all deaths associated with infusion pumps are due to user error, and the majority of these errors may be due to errors in programming the infusion pump.

[0353] Effective monitoring systems can monitor and regulate at any stage of the medication prescribing and taking process to help minimize any of the multiple 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 taking 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 at least one patient care device by discovering the presence of at least one patient care device and converting communication signals from that device into a communication protocol associated with the monitoring client. In some embodiments, the monitoring client passively monitors the operation of the patient care device. The communication interface can be implemented by the communication module described below. The communication interface can be further configured to discover the presence of additional other patient care devices that are different from each other (e.g., different manufacturers, functions and / or communication protocols, etc.), and convert communication signals from those devices into a communication protocol associated with the monitoring client or hub. Therefore, the communication interface allows a monitoring client such as a tablet computer to effectively serve as a common universal user interface that a health care provider can use when providing treatment to a patient associated with the monitoring client. One or more databases accessible to the monitoring client allow centralized storage of patient information (in any format and database structure desired by the health care facility or database maintainer), and allow downloading of information that can be used by a health care provider in the treatment of a patient 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 portable, for example, by the following means: that is, the communication module includes a battery and sufficient circuitry for mobile operation of a patient care device such as an infusion pump. In addition 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 directly inserted into the patient care device). The communication module can be charged 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 a plurality of 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 LAN 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 in a prescription that is sent to update the patient's personal EHR 19 or sent to the pharmacy 6 for filling. The prescription can be a prescription for a pill, for injection of fluids or other treatment. The prescription can be a prescription for injecting fluids using an infusion pump 7, a syringe pump 126 or a micro pump 130 or for dispensing pills using a 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 coupled to the one or more computers that can mix fluids or produce pills; or manually by a pharmacist observing a queue in 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 micro pump 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 regimens, prescriptions, and / or patient information.

[0360] The automated mixing device may: (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 may 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 identification 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 bar code 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 pills; (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 pills 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 bar code, RFID, or other patient identification information). That is, in some specific embodiments, the infusion pump 7, syringe pump 126, micro pump 130 and / or pill dispenser 128 can read one or more serial numbers from an RFID tag or bar code and ensure that the value matches the value found in internal memory (e.g., a value downloaded via an automated mixing device) or that the value matches the value found in the patient's electronic medical record (e.g., via a patient serial number determined by scanning the patient's RFID tag or scanning a patient bar code 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, micropump 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, and 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 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 mixing 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 pills; (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 pills 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 may be used to send commands or requests to the infusion pump 7, syringe pump 126, and / or micro pump 130 for the patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, such as a bolus, 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. In some embodiments, one or more of the monitoring clients 1, 4, 11 may be used to send commands or requests to the pill dispenser 7, such as a pill dispensing command for dispensing pills, pill types, pill dispensing schedules, and / or a maximum pill dispensing standard. The maximum pill dispensing standard may be the maximum amount of medication that can be delivered within a predetermined time interval; for example, to obtain certain medications on demand (i.e., when necessary); however, it may be unsafe to obtain medications in excess, and the maximum pill dispensing standard may prevent a patient from obtaining medications at unsafe levels, such as 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, 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 100 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, other monitoring client 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or micro pump 130 may transmit to one or more of the monitoring client 1, other monitoring client 4, and / or remote communicator 11 (as appropriate): upstream pressure; changes in upstream pressure; pressure downstream of the patient 2; changes 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 drug delivery; actual stop time of drug 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 pills 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 the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be analyzed for any predetermined conditions for which alarms and / or warnings may be issued. For example, one or more of the monitoring clients 1, 4, 11 may use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micro pump 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 downstream by materials such as contaminants found in the IV bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 may provide a warning or alarm to the user, either visually or audibly. These warnings and / or alarms may also notify the nurse to take other appropriate actions, such as a suggestion to change the needle when the pressure downstream of the patient rises above a predetermined threshold, or a suggestion 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 tube 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 visually or audibly provide a warning or alarm to the user to reattach the tube to the needle or insert a new needle to continue the infusion. The warning may also indicate that prompt action is required, for example, because the patient may be bleeding, such as when the tube becomes detached from the needle and when the patient is bleeding through an unattached needle coupler.

[0368] In some embodiments, additionally or alternatively, the pressure upstream of one or more infusion pumps 7 may be monitored for any upstream occlusions. For example, contaminants on the IV bag 170 may 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 may drop below the pressure that would occur if there were no upstream occlusions. Thus, one or more of the monitoring clients 1, 4, 11 may 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, the syringe pump 126 and / or the 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, the cable 110 is coupled to both bases 102, 104 to provide a communication link therebetween. The cable 110 may be permanently attached 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, the bases 102, 104 can communicate with each other using one or more wires and / or waveguides in the cable 110. For example, in one embodiment of the present disclosure, the cable 110 includes a fiber optic waveguide for providing an optical communication link between the bases 102, 104. In other embodiments, as will be understood based on the present disclosure, if desired, the cable 110 can be replaced with one or more wireless communication links (e.g., Bluetooth, etc.). Still other embodiments can use a combination of wired and wireless communication channels between the bases 102, 104. Any number of suitable wired connection types can 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. In addition 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, Fiber 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 is able to access communications between the bases 102, 104. For example, in some embodiments of the present disclosure, the monitoring client 1 is able to communicate with circuitry, such as memory, within the device base 104 via a communication link provided by the cable 110. Additionally or alternatively, the monitoring client 1 is able to communicate with any device docked to the device base 104 via a communication link provided by the cable 110 and / or one or more wireless communication links (described in more detail below).

[0375] Further references Figure 1In the illustrated example embodiment, the 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, the monitoring client base 102 may include various accessories, each of which is optional, such as a camera 140 and a microphone 142. The monitoring client 1 may include various accessories, each of which is optional, such as a camera 144 and a microphone 146. The cameras 136, 140, 144 may be used, for example, by facial recognition software to identify or recognize the presence of a provider (e.g., a nurse, a nurse practitioner, a doctor, etc.) and / or a patient. Additionally or alternatively, the 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 identity of a patient prior to beginning treatment (e.g., using voice and / or facial recognition technology, retinal scanning, etc.) to ensure that the correct patient receives the correct treatment.

[0376] like Figure 1 As shown, in some embodiments, the monitoring client 1, the monitoring client base 102, and the device base 104 have respective antennas 112, 106, and 108 for wireless communication (each antenna 112, 106, and / or 108 is optional). If the cable 110 is unplugged or the communication between the bases 102, 104 via the cable 110 is interrupted or damaged, the monitoring client base 102 and the device base 104 can continue to communicate with each other using the wireless communication link established through the antennas 106, 108. In addition, when the monitoring client 1 is removed from the monitoring client base 102, the monitoring client 1 can, for example, communicate directly with the device base 104, and / or the monitoring client 1 can communicate with the device base 104 by wirelessly communicating with the monitoring client base 102, and the monitoring client base 102 relays the communication via the cable 110 or via the wireless communication link between the 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, the monitoring client 1 may electronically determine whether one or more electrical contacts of one or more connectors are electrically engaged with the monitoring client base 102 to determine whether the cable 110 is available as a communication link, for example by measuring a voltage or impedance between two electrical contacts of a connector of the monitoring client 1 for docking to the monitoring client base 102 and for providing electrical communication between the monitoring client base 102 and the monitoring client 1. Furthermore, if the monitoring client 1 determines that the cable 110 is not electrically coupled to the cable 110, the monitoring client 1 may determine that the cable 110 is unavailable. Additionally or alternatively, in some embodiments, a magnet in the base 102 engages a Hall effect sensor in the monitoring client 1, which the monitoring client 1 uses to determine whether it is docked, such that the monitoring client 1 assumes that the cable 110 is unavailable as a communication link when the monitoring client 1 is not docked. Additionally or alternatively, circuitry within the monitoring client base 102 may send a signal to the monitoring client 1 when the cable is unavailable 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 not available as a communication link.

[0378] In the event that 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 a speaker and / or a 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 from the monitoring client 1 to the cable 110 with minimal or no circuitry. 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 with 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 may be a cradle.

[0380] In one embodiment of the present disclosure, each monitoring client 1 is assigned to a specific patient 2 and may be desktop-based, portable or handheld and may have a display and user input capabilities. The monitoring client 1 may be portable and may facilitate efficient data viewing and data input; the monitoring client 1 may be a notebook PC, a netbook PC, a tablet PC, a "smartphone" with or without a touch screen. Additionally or alternatively, in some embodiments, the monitoring client 1 and / or the remote communicator 11 may be docked or connected to a cable that is connected to a larger display, thereby adjusting the larger display (e.g., a 24-inch display) to the display of the monitoring client 1 and / or the remote communicator 11; the larger display may have input capabilities, such as touch screen capabilities, stylus input capabilities, keyboard input capabilities, and remote control input capabilities, etc., which are transmitted to the monitoring client 1 and / or the remote communicator 11. For example, the viewing of X-ray files or patient imaging files may be facilitated by docking the monitoring client 1 and / or the remote communicator 11 to a viewing base coupled to a larger display, so that a caregiver can use the larger display to view the patient imaging files. 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, and iPhone OS, etc. A specific monitoring client 1 can be assigned to a specific patient 2 using any of a variety of methods, such as, but not limited to, a unique patient identifier encoded on an RFID tag 116 or a barcode 114 embedded in a wristband 118. The device base 104 includes a scanner 120 for determining a unique patient identifier of 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, and an RFID reader, etc. In other embodiments, please note that the unique patient identifier can be based on the patient's biometric data. In one such example case, biometric capabilities (e.g., facial and / or voice recognition, retinal scanning, blood type monitor, fingerprint scanning, etc.) can be built into the monitoring client 1 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, a logic device, a digital circuit, an analog circuit, etc. to transceive (e.g., send or receive) information related to the patient's 9 care, condition, disease, 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 are measurements of blood pressure, body 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 taken, flow rates of medications or fluids, 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 attachable and detachable from the infusion pump 7. This can be accomplished by a docking interface between two devices (e.g., a monitoring client base 102 and a 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 communicating via electrical contacts in the bases 102, 104, via electrical connectors, or via transceivers on each device using corresponding antennas 112, 122A. Additionally or alternatively, the infusion pump may include pre-programmed treatment data that is uploaded to the monitoring client 1 when the infusion pump 7 becomes operatively communicative with the monitoring client 1, representing a specific treatment for a specific patient.

[0384] The monitoring client 1 may also communicate with one or more databases in the facility 8, with databases external to the facility 9, 10, and / or with health care providers (including, for example, physicians, nurses, and pharmacists) using a portable communicator 11. This may be accomplished by a wired connection to the facility server 8 via a connector in the patient's room (e.g., a Category 5 LAN connector, USB, wired Ethernet, etc.) 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 the monitoring server 3 (e.g., using middleware), which may then centralize software and application programming interfaces to communicate with databases having separate organization, formatting, and communication protocols. Thus, in one embodiment of the present disclosure, any software updates may be largely limited to the monitoring server 3, thereby reducing maintenance requirements for the individual monitoring clients 1, 4, 11. Optionally, the monitoring client 1 may communicate with a patient treatment device such as an infusion pump 7 to receive information about the progress of treatment (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 the provider or algorithm desires.

[0385] In one embodiment of the present disclosure, the facility service 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 stopped (e.g., turned off) by a caregiver using the infusion pump 7 and / or the user interface of the monitoring client 1 (and may only be an audible and / or vibrating alarm), while hard alarms cause treatment to be stopped until the cause of the hard alarm is eliminated.

[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 infusion pump 7 and / or the user interface of the monitoring client 1 to stop these soft limits to start treatment even if the treatment is outside the first set of predetermined criteria, while the 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 of the system 100, the system 100 also includes communication modules 124A-124K, each of which has a corresponding antenna in the antennas 122A-122K. In some embodiments, each communication module 124A-124K is optional, and / or each device can have integrated communication capabilities. Each communication module 124A-124K 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, through 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, for example, as a wireless mesh network using IEEE 802.14.4, Zigbee, XBee, Wibree, and IEEE 802.11, etc. In a more general sense, any wireless communication protocol may be used to implement 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.), which wireless communication protocol, for example, allows 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 a module or 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 having a specific function and the user may connect them together. The group of modules can then be applied to a patient care device, such as an infusion pump. Consider another example: each module may have a main processor, a backup processor, and a functional circuit that is operable to communicate with each other. The functional circuit can be a wireless transceiver, a battery, an interface with a touch screen or a display (e.g., a display can be attached to the housing), a wired connection, Bluetooth, low-power Bluetooth, WiFi, 3G, 4G, a co-processor, a control system (e.g., for controlling an infusion pump), a drug with a fluid measurement circuit, etc. The selected modules can be connected together in a daisy chain, for example, and then connected to the infusion pump. In this example, for example, the selected modules can be operable to communicate with each other via a CAN bus, a wired connection, and / or a wireless method, etc., to coordinate their behavior and / or function.

[0390] Each module may include a speaker and a microphone. When several modules are connected to each other, the modules may coordinate their operation so that one module can send an audible signal to a speaker, while another module uses a microphone to determine whether the speaker is functioning correctly. Each of the several modules may use its speaker at a different frequency, so that any one of the modules may sense sound via its microphone and demodulate different frequencies to test several of the speakers simultaneously. A first module may request the test from a second module, and the second module may send the result 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 provide power to the device connected thereto. 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 associated therewith, the communication modules 124A-124K may include other structures and functions. For example, in some embodiments, the control of the infusion occurs at the infusion pump, and the input associated with the desired delivery occurs on the infusion pump; therefore, in some embodiments of the present disclosure, the communication module 124A executes 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), and the communication module 124A then applies a signal corresponding to the fluid flow rate signal through an electrical contact connected to the motor (not explicitly shown) of the infusion pump 7 to obtain the desired flow rate. In some embodiments, the infusion pump 7 provides one or more feedback signals from a flow meter provided in the infusion pump 7 to the communication module 124A, so that the communication module 124A can control the operation of the infusion pump 7 (for example, some aspects of the operation, such as a PID control system, etc.). The result can be transmitted to the monitoring client 1 to be displayed 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 the 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 / capnometry 16, communication module 124H is operably coupled to other monitors 17, communication module 124I is operably coupled to patient's 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 respective patient care device 7, 14, 15, 16, 17, 35, 126, 128, or 148 coupled thereto.

[0393] Additionally or alternatively, in some embodiments, the communication module 124D is docked in the device base 104 and operably 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 circuits within the device base 104, electronic circuits 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, such as the infusion pump 7, the syringe pump 126, the pill dispenser 128, or the micro pump 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 their respective devices 7, 14, 15, 16, 17, 35, 126, 128, 148, which power may be supplemented by one or more wired power sources, such as power sources 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 a power supply circuit (e.g., a voltage converter, a voltage regulator circuit, a rectifier and filter circuit, a buck circuit, a boost 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 circuit can be configurable to allow for providing various power supply characteristics (e.g., voltage levels, maximum load / current requirements, and A / C frequencies) associated with 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 1In such cases, when available, the outlet power can be used to power devices in the base 104 and charge the battery included in the power module 132 (which can be done simultaneously); when the outlet power is lost or unavailable, the battery within the power module 132 and / or the communication modules 124A, 124B, 124C can provide power to the docked device.

[0397] Optionally, the example system 100 may include a dongle 133. The dongle 133 may be 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 the 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 new communication protocols and convert information sent under one protocol to another 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., monitoring server 3 or monitoring client 1). The dongle 133 may also provide a communication bridge to a cellular communication link (e.g., a cellular system based on EVDO or CDMA).

[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 communication to one or more other patient care devices, monitoring client 1, 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 devices using traditional wired communication protocols.

[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 a 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 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 properly, 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 a monitoring server 3, a monitoring client 1, or a monitoring device. Figure 8 The hub 802 transmits the detected condition or error to warn the provider, initiate a shutdown process and / or initiate other appropriate remedial actions related to the failed device. For example, the system monitor 131 can use the transceiver of the communication module 124J to communicate with the monitoring client 1, the monitoring server 3 via a WiFi router connected to the network and / or the Internet, other monitoring clients 4, other devices configured with the communication module 124 or the remote communicator 11, so as to signal a warning and / or alarm caused by an abnormality or the absence of an inquiry response. The warning and / or alarm can cause the device to audibly emit a sound or visually give a warning and / or alarm. In some embodiments of the present disclosure, the system monitor 131 indicates a call button (not explicitly shown) to allow the patient 2 to make 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 who owns the device.

[0401] The system monitor 131 can implement its functions in a variety of ways, including, for example: (1) expecting to receive 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 inquiry within a predetermined amount of time after inquiring a patient-care device paired with the system monitor 131. For example, the system monitor 131 can send a text string message "System Monitor Inquiry" to the infusion pump 7. In this example, the infusion pump 7 receives a message labeled "System Monitor Inquiry" 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 can 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, the system monitor 131 increments a counter within the device being queried and requests the value of the counter after the increment from the device. For example, the 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 processor of the device receives the "increment counter" message and reads a value from a memory location of the device, increments the value found at the memory location, and stores the new value in the same memory location by overwriting the previous value. Thereafter, in this example, the processor reads the new value from the memory location and sends the new value to the system monitor 131, for example, via a wireless transceiver on the device being queried. In this example, the system monitor 131 expects to receive a specific value from the device being queried (this expected value may be stored in the system monitor's memory, such as in a table). For example, the system monitor 131 may store in its memory a value 48 previously received from the device, and after requesting an updated value within the device being queried, expects to receive a value 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 a patient care device. The patient care device is then tasked to decrypt the message, for example, using an encryption key, and send 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 a 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, the monitoring client 1 has the ability to communicate or directly interact with a health care provider using a handheld or portable remote communicator 11 (which may be, for example, a smart phone, tablet computer, PDA, laptop computer, or other portable computing device). This may be accomplished wirelessly 12, enabling communication to be maintained regardless of the patient's location in the facility or the provider's location inside or outside the facility. In one aspect, specific information about the patient 2 may be stored locally in the monitoring client 1, enabling the patient's health care provider to directly access the information without having to access the monitoring server 3.

[0406] In some embodiments, optionally, and with the inclusion of appropriate security and privacy checks, changes to settings or flow parameters of a connected infusion pump 7 or patient monitoring device 14-17, 35, 126, 128, 130, 148 may 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 thereby optionally to other appropriate locations, such as the nurses' station 5 and / or pharmacy 6. In addition, any new orders associated with the patient 2 may be entered into the order provider's remote communicator 11 (e.g., a smartphone) and sent to the monitoring client 1, which may then notify the caregiver (e.g., a nurse, nurse practitioner, doctor, physician, or other health care 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 connected to the device can change its operation in response to the new order, for example, change its set points. 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 can be assigned to the patient 2 and quickly repopulated with the patient's current information from the monitoring server 3. Orders, medications, medical records, 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 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, the monitoring server 3 may include a computer that can communicate with multiple monitoring clients 1, 4, 11 in the facility 8 and provide some elements for the control of the multiple monitoring clients 1, 4, 11. The monitoring server 3 can provide the monitoring clients 1, 4, 11 with data extracted from multiple databases within the facility 8 and outside the facility 9. In one embodiment of the present disclosure, the monitoring server 3 can query the EHR system 19 of the facility for target information related to the patient 2, and then fill the monitoring client 1 of the patient with a predefined set of information (such as the patient's age, height, weight, diagnosis category, current medication and medication category, medication allergy history and sensitivity, etc.). According to one such example, for example, when the monitoring client 1 has been assigned to the patient 2, the monitoring server 3 can establish a communication link to the EHR 19, the laboratory 20, the radiology department 21, the pharmacy 22 and / or other systems (e.g., the cardiology department 23 or the appointment database 24). Through the unique patient identifier, the monitoring server 3 can obtain electronic access rights (permissions) for receiving and sending patient-specific data from and 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 so obtained can then serve as a critical database against which new orders can be analyzed. For orders entered into the monitoring client 1, compatibility with patient characteristic information obtained by the monitoring server 3 can be checked. Optionally, for safety redundancy, orders entered remotely from the communicator 11 can be intercepted by the monitoring server 3 and can be similarly checked. The monitoring server 3 can also obtain information from a drug database resident in the pharmacy 22 of the facility or an external drug database 9 to, for example, determine whether a new patient order will be incompatible 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 health care 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, the 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 the patient 2. The monitoring client 1 or server 3 can then record the new medical 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, etc.) can be used as a convenient portable communicator 11 for providers who are not in a fixed place (for example, in an office or remote nurse's station). Tablet PCs, netbooks or laptops can also serve as convenient portable communicators 11 for portable and fixed locations. PCs can serve as convenient communication devices 11 for fixed or desktop locations. If the provider is located in the patient's room, he or she can enter or receive information related to the patient 2 using direct input through a keyboard or touch screen on the monitoring client 1.

[0410] The monitoring client 1 can receive, process and send information related to the specific patient 2 to which it is assigned or designated. The monitoring client 1 can be most conveniently attached or docked to the monitoring client base 102 to communicate with the infusion pump 7 or any other device that can be connected or associated with the patient 2. The monitoring client 1 can be, for example, a handheld device of comparable size to a wireless phone or a tablet-type netbook. Conveniently, it can have a touch screen interface to be used by the patient's provider. It can also provide output to a larger fixed display in the patient's room or at the nurse's station 5 or other convenient location via a wired or wireless connection. Each monitoring client 1 can communicate with a central monitoring server 3, through which each monitoring client 1 can access patient data from the EHR database 19 of the facility, the laboratory database 20, the radiology database 21, the pharmacy database 22 or other databases in various other facilities departments. In some cases, the monitoring client 1 can upload information received from the patient monitoring device 14-17 or from the provider input to 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 alarm networks that handle adverse drug related events.

[0411] The monitoring server 3 can be arranged to manage various levels of external database information, which helps to keep the content of the monitoring client 1 as up to date as possible. This can be achieved, for example, by comparing the safety and drug information associated with the patient as it becomes available and giving priority to updating / downloading on a data transfer schedule. The monitoring clients 1, 4 can also communicate directly or through the monitoring server 3 with a portable communicator 11 used by a health care provider (e.g., a nurse, a physician, or a pharmacist). In some cases, these devices can have a wired connection to the monitoring server 3 (e.g., if used in a fixed location such as a hospital pharmacy or a nurse's station). In other cases, the portable communicator 11 can communicate with the monitoring server 3 using a computer, through a secure Internet connection (e.g., an Internet connection 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 with the device 11. Alternatively, a handheld remote communicator 11 (e.g., a smart phone or tablet netbook) can communicate directly 12 with the facility's monitoring client 1 via a cellular telephone network, and / or the facility can include a dedicated cellular network, which may include a WiFi network (e.g., an 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 may 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 health care 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 method of blanketing the entire facility with wireless coverage includes enabling the facility to obtain a license for a dedicated cellular telephone network. It can obtain or lease one or more microcellular frequencies to provide a local communication network throughout the facility. This arrangement can maintain communication when patients and their monitoring clients 1, 4 move from one location within the facility to another, to maintain communication with the monitoring server 3, various databases 8, 25 within and outside the hospital, and users at fixed locations (e.g., in some embodiments, nurse stations 5 and pharmacies 6) or with monitoring clients 11 (e.g., smartphones, laptops or tablet devices) inside or outside the hospital. In some embodiments, such a system provides additional security via a licensed cellular communications infrastructure. In addition, in some embodiments, an active wireless system can monitor the intensity of use in an area and direct additional channel frequencies to that area. However, in some embodiments, the bandwidth capacity of the network may not allow the efficient transmission of large data files (e.g., large data files containing radiological images). Such data files that occupy huge bandwidths can be transmitted more efficiently via wired connections.

[0414] Alternatively or in addition, the hospital can implement an Internet or intranet-based communication system, wherein an 802.11 WiFi type protocol is used for wireless communication between each monitoring client 1, 4 and the monitoring server 3. In order to ensure adequate signal reception throughout the facility, a broadband antenna can be installed on the roof of the building to collect cellular phone signals from a local wireless phone company. The optical fiber or cable network can then distribute the signal throughout the facility. Additionally or alternatively, the monitoring server 3 can use the above-mentioned dedicated cellular phone network. Such a system generally allows secure communication to be provided and can effectively transmit large files, such as radiological images stored in the radiology database 21. Users based on home or office can use wired cables or optical cables or DSL phone lines to connect to the hospital server through, for example, VPN or other secure access. Data encryption can be used to provide the security of patient data. In some applications, it can be beneficial to implement an asymmetric bandwidth communication network to optimize infrastructure capabilities. An example thereof is to use a licensed cellular frequency in the "up" direction from the monitoring client 1 to the monitoring server 3 and an open 802.11 WiFi frequency in the "down" 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 in the 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, for example, can be used to implement communication between various monitoring devices (such as patient care devices 14, 15, 16, 17, 35) and monitoring clients 1 in a cost-effective manner. Exemplary monitoring devices include, among others, ECG monitors 14, blood pressure monitors 15, pulse oximeters / capnometry monitors 16, thermometers, weight scales, and the like. The common feature 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 use widely available, unlicensed frequency bands (e.g., 2.4 GHz in some regions). Advanced communication protocols can be used to ensure data fidelity and security, such as TCP and UDP, and the like. For example, symmetric encryption keys can be used to ensure communication between monitoring clients and patient care devices, such as keys generated by encryption algorithms such as Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES, and IDEA, and the like. Additionally or alternatively, various data integrity techniques may be used, such as CRC, odd or even parity check, etc.

[0416] Mesh networks are highly scalable, allowing multiple devices to be used on a single self-forming, self-healing mesh network. Devices connected to the network can communicate with each other and act as repeaters to transmit data. Mesh networks can be low-cost, scalable or mobile for monitored patients. In some embodiments, the wireless range of devices for linking to a wireless mesh network can be 70 meters from each node of the system in a 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 client 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 may be programmed to determine if the value is outside a predetermined range, record the value in the patient's EHR 19, and notify the appropriate provider via the patient's monitoring client 11. In addition, the network may enable two-way communication and may allow the monitoring client 1 to query a patient monitoring device (e.g., a BP monitor 15) to instruct the patient monitoring device to take an unscheduled reading. This may be helpful, for example, when an abnormal reading is received and its authenticity needs to be verified. The monitoring client 1 may be programmed to request a repeated number of times in order to verify the abnormal reading. In yet another embodiment, the monitoring client 1 may 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 device 14-17. For example, if the BP monitor 15 indicates a blood pressure below a predetermined acceptable range, the monitoring client 1 may be programmed to command the infusion pump 7 to stop infusion, and the monitoring client 1 may send an emergency notification 12 to the monitoring client 11 of the health care provider. 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 volume delivered 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 the nurse is scheduled to return at a specific time to replace the bag, and 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 run out when 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 will be displayed on the monitoring client 1 so that the percentage of the border that is lit (e.g., begins to form a fully filled perimeter as the border fills in) indicates the progress of the treatment performed by the patient-care device, such as the infusion pump 7. The border can be transmitted from the infusion pump 7 to the monitoring client 1 in the format of an image (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 ranging modules (e.g., ultrasonic ranging modules using round-trip time estimation) may be installed on the infusion pump 7, monitoring client 1, caregiver, and / or patient. In this particular embodiment, the predetermined settings may require that a predetermined set of infusion pumps 7, monitoring client 1, and / or patient devices must be used before starting treatment and / or before configuring one of the infusion pumps 7 and / or monitoring client 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 warning, a hard warning, and / or a non-critical warning to the remote communicator 11 without warning on the device that issued the warning 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 warning without disturbing the patient). If the cause of the warning is eliminated before the predetermined amount of time, the device that issued the warning and / or the monitoring client 1 may not warn, thereby avoiding additional disturbance to the patient.

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

[0423] In some embodiments, the infusion pump 7 includes a status LED light to indicate one or more of the following situations: the safety check has 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 time the LED on the socket can flash to indicate to the user that the tube connected to the IV bag 170 should be inserted into the socket.

[0424] In some embodiments, Figure 1As shown or combined Figure 1 Each item, component, device, patient care device, base, and computing device described, whether numbered or not, 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 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Likewise, 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] In addition, in some embodiments, although Figure 1 As 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 a single item, component, device, patient-care device, base, or computing device, although multiple items, components, devices, patient-care devices, bases, and computing devices are also contemplated; for example, although Figure 1 A single infusion pump 7 is shown, but in some embodiments, two infusion pumps 7 may be used, multiple infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. Additionally or alternatively, in some embodiments, multiple device bases 104 and / or multiple monitoring client bases 102 may 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 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 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 are dockable, can be operated undocked, and / or can 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, Figure 8 The hub 802 performs the reference Figure 1 Any functionality described.

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

[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 through 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 a communication link between the monitoring client and the monitoring client base via a wireless link. If the link in step 156 is available, the method 150 proceeds to step 154, otherwise, the 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 be used as 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 be used as a communication link between the monitoring client and the patient care device base via a direct wireless link. 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 an available communication link. In an alternative embodiment, 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, step 164 determines that communication with the patient device is not available, 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, step 169 uses a sufficient number of communication links determined to be available by method 150 to transmit data.

[0435] Method 150 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 150 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 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.

[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, the electronic patient-care system 300 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 performed 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 cannot be connected together using a cable.

[0437] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send commands or requests for the patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 to the infusion pump 7, syringe pump 126, and / or micro pump 130, such as a bolus, infusion flow rate, total fluid for delivery, start time of drug delivery, stop time of drug delivery, or delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send commands or requests to the pill dispenser 128, such as a pill dispensing command for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria. The maximum pill dispensing criteria can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, some medications are obtained on demand (i.e., when necessary), however, if an excessive amount of medication is obtained, it may be unsafe, and the maximum pill dispensing criteria can prevent a patient from obtaining medication at an unsafe level, for example, obtaining 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, other monitoring clients 4, and / or 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, other monitoring client 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or micro pump 130 may transmit to one or more of the monitoring client 1, other monitoring client 4, and / or remote communicator 11 (as appropriate): upstream pressure; changes in upstream pressure; pressure downstream of the patient 2; changes 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 drug delivery; actual stop time of drug 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 pills 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 the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be analyzed for any predetermined conditions for issuing alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 may use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micro pump 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 provide a warning or alarm to the user, either visually or audibly. 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 away from the patient; and, in response, one or more of the monitoring clients 1, 4, 11 can provide a warning or alarm to the user, either visually or audibly. One or more of the monitoring clients 1 , 4 , 11 can optionally send commands to one or more of the infusion pump 7 , the syringe pump 126 and / or the micropump 130 to stop the delivery of fluid in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2 .

[0441] In some embodiments, Figure 3 As shown or combined Figure 3 Each item, component, device, patient care device, base, and computing device described, whether numbered or not, 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 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Likewise, 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] In addition, in some embodiments, although Figure 3 As 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 a single item, component, device, patient-care device, base, or computing device, although multiple items, components, devices, patient-care devices, bases, and computing devices are also contemplated; for example, although Figure 3 A single infusion pump 7 is shown, but in some embodiments, two infusion pumps 7 may be used, multiple infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. Additionally or alternatively, in some embodiments, multiple device bases 104 and / or multiple monitoring client bases 102 may 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 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 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 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 are dockable, may be operated 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 be used as a communication link between the monitoring client and the monitoring client base via a base connector. If the communication link in step 204 is available, the method 202 proceeds to step 206, otherwise, the method 202 proceeds to step 208. Step 208 determines whether the monitoring client base can be used as a communication link between the monitoring client and the monitoring client base via a wireless link. If the communication link in step 208 is available, the method 202 proceeds to step 206, otherwise, the 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 is available 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 is 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 is 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 over a communication link that has not been 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 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 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] See now 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 a monitoring client 1 and various patient-care devices (e.g., patient-care devices 7, 126, 128 or 130), a communication module 124D and a 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 the present disclosure, the base 502 can include one or more buses, backplanes, communication paths, electronic circuits, etc., to facilitate communication.

[0454] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send commands or requests for the patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 to the infusion pump 7, syringe pump 126, and / or micro pump 130, such as a bolus, infusion flow rate, total fluid for delivery, start time of drug delivery, stop time of drug delivery, or delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send commands or requests to the pill dispenser 128, such as a pill dispensing command for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria. The maximum pill dispensing criteria can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, some medications are obtained on demand (i.e., when necessary), however, if an excessive amount of medication is obtained, it may be unsafe, and the maximum pill dispensing criteria can prevent a patient from obtaining medication at an unsafe level, for example, obtaining 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, 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 500 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, other monitoring client 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or micro pump 130 may transmit to one or more of the monitoring client 1, other monitoring client 4, and / or remote communicator 11 (as appropriate): upstream pressure; changes in upstream pressure; pressure downstream of the patient 2; changes 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 drug delivery; actual stop time of drug 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 pills 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 the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be analyzed for any predetermined conditions for issuing alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 may use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micro pump 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 provide a warning or alarm to the user, either visually or audibly. 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 away from the patient; and, in response, one or more of the monitoring clients 1, 4, 11 can provide a warning or alarm to the user, either visually or audibly. One or more of the monitoring clients 1 , 4 , 11 can optionally send commands to one or more of the infusion pump 7 , the syringe pump 126 and / or the micropump 130 to stop the delivery of fluid in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2 .

[0457] In some embodiments, Figure 5 As shown or combined Figure 5 Each item, component, device, patient care device, base, and computing device described, whether numbered or not, 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 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Likewise, 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] In addition, in some embodiments, although Figure 5 As 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 a single item, component, device, patient-care device, base, or computing device, although multiple items, components, devices, patient-care devices, bases, and computing devices are also contemplated; for example, although Figure 5 A single infusion pump 7 is shown in FIG, but in some embodiments, two infusion pumps 7 may be used, multiple infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. Additionally or alternatively, in some embodiments, multiple bases 502 may 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 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 Additionally or alternatively, in some specific embodiments, only the patient-care devices in use are dockable 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 are dockable, can be operated 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 in step 306 is not available, 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 in step 310 is not available, 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 uses an available communication link to attempt a handshake between the monitoring client and the device. In alternative embodiments, a handshake is not used; for example, some protocols do not use a handshake. Decision step 318 determines whether the handshake is 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 not available. 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, 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 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 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.

[0467] Now turn to Figure 7 , a block diagram of an electronic patient-care system 700 according to yet another embodiment of the present disclosure is shown, the electronic patient-care system 700 having a monitoring client 1 having an integrated base 702 for docking a 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 may be docked to the base 702. Figure 7 The patient care system 700 is similar to Figure 1 100; however, the patient care system 700 includes an integrated base 702. In some embodiments, the monitoring client 1 communicates with the patient care device when it is docked via the base; however, if the monitoring client 1 is unable to communicate with the patient care device (e.g., patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148), the monitoring client 1 can, for example, use the antenna 112 of the monitoring client 1 to communicate with the patient care device wirelessly.

[0468] Optionally, the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to send commands or requests for the patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 to the infusion pump 7, syringe pump 126, and / or micro pump 130, such as a bolus, infusion flow rate, total fluid for delivery, start time of drug delivery, stop time of drug delivery, or delivery flow rate profile. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send commands or requests to the pill dispenser 128, such as a pill dispensing command for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria. The maximum pill dispensing criteria can be the maximum amount of medication that can be delivered within a predetermined time interval; for example, some medications are obtained on demand (i.e., when necessary), however, if an excessive amount of medication is obtained, it may be unsafe, and the maximum pill dispensing criteria can prevent a patient from obtaining medication at an unsafe level, for example, obtaining 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, 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 700 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, other monitoring client 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or micro pump 130 may transmit to one or more of the monitoring client 1, other monitoring client 4, and / or remote communicator 11 (as appropriate): upstream pressure; changes in upstream pressure; pressure downstream of the patient 2; changes 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 drug delivery; actual stop time of drug 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 pills 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 the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be analyzed for any predetermined conditions for issuing alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 may use an increase in pressure downstream of the infusion pump 7, syringe pump 126, and / or micro pump 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 provide a warning or alarm to the user, either visually or audibly. 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 away from the patient; and, in response, one or more of the monitoring clients 1, 4, 11 can provide a warning or alarm to the user, either visually or audibly. One or more of the monitoring clients 1 , 4 , 11 can optionally send commands to one or more of the infusion pump 7 , the syringe pump 126 and / or the micropump 130 to stop the delivery of fluid in response to a sudden increase and / or sudden decrease in pressure downstream of the patient 2 .

[0471] In some embodiments, Figure 7 As shown or combined Figure 7 Each item, component, device, patient care device, base, and computing device described, whether numbered or not, 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 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Likewise, 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] In addition, in some embodiments, although Figure 7 As 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 a single item, component, device, patient-care device, base, or computing device, although multiple items, components, devices, patient-care devices, bases, and computing devices are also contemplated; for example, although Figure 7 A single infusion pump 7 is shown in FIG, but in some embodiments, two infusion pumps 7 may be used, multiple infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. Additionally or alternatively, in some embodiments, an integrated base 702 may 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 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 Additionally or alternatively, in some specific embodiments, only the patient-care devices in use 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 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 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 in the integrated base 702 is shown. 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 8802 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 the device bases 804, 806. In other embodiments, the hub 802 controls the patient care devices without the monitoring client 1, other monitoring clients 4, and / or remote communicators 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, 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 use the clock of the hub 802 (e.g., patient care devices, monitoring clients, remote communicators, etc.), real-time devices use the clock of the hub 802, or time-critical devices use the clock of the hub 802.

[0476] In some embodiments, GPS and / or distance measurement modules (e.g., ultrasonic distance measurement modules) 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, the predetermined settings may require that a predetermined group of infusion pumps 830, the monitoring client 1, the hub 802, the caregiver, and / or the patient must be at a predetermined distance relative to each other before starting treatment and / or before configuring one of the infusion pumps 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 (a device paired with it, a device 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 may 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 may have a distributed UI system.

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

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

[0482] Optionally, 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 exclusively with the patient via the hub 802, such as Figure 8 The system 800 shown interacts. 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, 806 can communicate with each other using, for example, a USB cable, an Ethernet cable, and / or via 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 can provide all patient safety critical functions and can 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 may be used to send commands or requests to one or more of the infusion pumps 830, 810, 812 for the patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148, such as a bolus, 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. In some embodiments, one or more of the monitoring clients 1, 4, 11 may be used to send commands or requests to the pill dispenser 814, such as a pill dispensing command for dispensing pills, pill types, pill dispensing schedules, and / or a maximum pill dispensing standard. The maximum pill dispensing standard may be the maximum amount of medication that can be delivered within a predetermined time interval; for example, to obtain certain medications on demand (i.e., when necessary); however, it may be unsafe to obtain medications in excess, and the maximum pill dispensing standard may prevent a patient from obtaining medications 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, 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 800 is operating correctly or within predetermined boundaries; and / or display data on a display of the monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, optionally, one or more of the infusion pumps 830, 810, 812 may transmit (as appropriate) to one or more of the monitoring client 1, other monitoring clients 4, and / or remote communicator 11: upstream pressure; changes in upstream pressure; pressure downstream of the patient 2; changes 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 drug delivery; actual stop time of drug 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 pills 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 the patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148 may be analyzed for any predetermined conditions for issuing alarms and / or warnings. For example, one or more of the monitoring clients 1, 4, 11 may use an increase in pressure downstream of one or more of the 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 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 provide a warning or alarm to the user, either visually or audibly. 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 away from the patient; and, in response, one or more of the monitoring clients 1, 4, 11 can provide a warning or alarm to the user, either visually or audibly. 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 sudden decrease in pressure downstream of the patient 2 .

[0487] In some embodiments, Figure 8 As 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. Likewise, 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] In addition, in some embodiments, although Figure 8 As 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 a single item, component, device, patient-care device, base, or computing device, although multiple items, components, devices, patient-care devices, bases, and computing devices are also contemplated; for example, although Figure 8 8, 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 of specific patient-care devices 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 may 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. Moreover, the recess of the base can be unused ( Figure 8 ). In addition, 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 some specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 830, 810, 812, 814 are dockable, can be operated un-docking, and / or can be non-dockable and can be operated as separate patient-care devices.

[0491] Figure 8 The system 800 may use any known communication method to maintain communications within the system. For example, in some embodiments, any schedule for communications 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 or hub 802 and one or more patient care devices (e.g., patient care devices 830, 810, 812, and 814); 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.

[0492] In one embodiment of the present disclosure, the facility service 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 may 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 it may be only 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 the 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, Fig. 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 a 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 may be used to send commands or requests for the patient-care device 14, 15, 16, 17, 35, 128, 904, 906, 908, 148, such as a bolus, 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. In some embodiments, one or more of the monitoring clients 902, 4, 11 may be used to send commands or requests to the pill dispenser 128, such as a pill dispensing command for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria. The maximum bolus dispensing criteria may be the maximum amount of medication that can be delivered within a predetermined time interval; for example, certain medications are obtained on demand (i.e., when necessary), however, it may be unsafe if the medication is obtained in excess, 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 in order 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 data on a display of the monitoring client 902, other monitoring clients 4 and / or remote communicator 11. For example, optionally, the stackable infusion pump 904, the stackable syringe pump 906, and / or another stackable patient-care device 908 can 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; changes in upstream pressure; pressure downstream of the patient 2; changes 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 drug delivery; actual stop time of drug delivery; or actual delivery flow rate profile. In another embodiment, the pill 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 pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule dispensed, or whether a maximum pill dispensing criteria has been exceeded.

[0498] Data received from the patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 may be analyzed for any predetermined conditions for issuing alarms and / or warnings. For example, one or more of the monitoring clients 902, 4, 11 may use an increase in pressure downstream of the stackable infusion pump 904 and / or the 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 materials within the IV bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 902, 4, 11 can provide a warning or alarm to the user, either visually or audibly. 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 away from the patient; and, in response, one or more of the monitoring clients 902, 4, 11 can provide a warning or alarm to the user, either visually or audibly. 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 manner via connectors connected 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 connected 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 each other. 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 of the stackable devices 908, 904, 906 to determine which device is faulty; upon making the determination, the stackable monitoring client 902 may wirelessly communicate with an isolated disconnect circuit within the faulty device of 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 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 a corresponding device located 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 As 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. Likewise, 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] In addition, in some embodiments, although Fig. 9 As shown or combined Fig. 9 Some of the items, components, devices, patient-care devices, bases, and computing devices described, whether numbered or unnumbered, are shown as a single item, component, device, patient-care device, base, or computing device, although multiple items, components, devices, patient-care devices, bases, and computing devices are also contemplated; for example, although Fig. 9 A single pill dispenser 128 is shown in FIG. 1 , 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 of specific patient-care devices 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 turned off, or may not be Fig. 9Additionally or alternatively, in some specific embodiments, only the patient-care devices in use are stacked; for example, in one specific embodiment, the infusion pump 904 is the only device that is stacked. Additionally or alternatively, an unstacked patient-care device (e.g., patient-care devices 904, 906, and / or 908) can continue to operate while it operates as a separate device. Additionally, alternatively, or optionally, in some specific embodiments, the patient-care devices 14, 15, 16, 17, 35, 904, 906, 908, 128, 148 are dockable, can operate undocked, and / or can be non-dockable and capable of operating as separate patient-care devices.

[0505] exist Fig. 9 In the embodiment, although the stack is shown as being able to stack 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 able to receive 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] Fig. 9 The system 900 may use any known communication method to maintain communications within the system. For example, in some embodiments, any schedule for communications 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 902 and one or more patient care devices (e.g., patient care devices 904, 906, 908); 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.

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

[0508] In some embodiments, the hub, base, device, insulin pump, infusion pump and / or patient care device can be a network-connected remote interface or have network-connected remote interface capabilities, which network-connected remote interface can have (but not limited to) the ability to download applications, download software updates, upload information to various machines, and / or send information, including (but not limited to) through a web-based secure portal and / or via email and / or through wireless communication protocols. Therefore, in various embodiments, the remote interface application can be run on any capable device and is not limited to so-called dedicated devices. Moreover, in some embodiments, the remote interface can be Bluetooth-enabled or otherwise enabled to communicate with one or more devices, such as using radio frequency ("RF") communications, which can include, but are not limited to, one or more of the following: a 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, a base, a device, an insulin pump, an infusion pump, and / or a 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 may be included 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. In addition and / or alternatively, the USB port may be configured to transfer data to / from the following components by connecting to a computer or other device and / or other computer-type equipment: a remote interface and / or a hub, a base, a device, an insulin pump, an infusion pump, and / or a patient care device. In an embodiment including a USB port, while the remote interface is being charged, the system may call a personal computer and / or a web portal to check for updated software, and, if there is updateable software, software updates may be downloaded, for example, via a USB connection. These updates may then be transmitted to the hub, base, device, insulin pump, infusion pump, and / or patient care device after pairing.

[0510] Therefore, 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 the data from the remote interface to a web portal or other. In some embodiments, this can be done during the "recharging" of the remote interface, which can be done using a USB connection to a personal computer in some embodiments, which can be synchronized and / or uploaded / downloaded from a personal computer, 1908 and / or web portal in addition to charging / recharging the remote interface. At this point, the system can determine that software updates for one or more of the device 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 when charging and / or when the remote interface is directly or indirectly connected to a personal computer and / or connected to a web portal specifically designed for the system. As described above, the remote interface is capable of communicating with various devices. Therefore, 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 needing to connect the remote interface 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, at any time, a new "remote interface" can be introduced to the system. This can be done 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", however, in other embodiments, the system can "allow" additional remote interfaces through 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 that can communicate with the device and / or can connect to the 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 some parameters, such as the ability to communicate and connect wirelessly to a personal computer and / or a web portal) into a device that can control various devices (such as an infusion pump) and / or receive data from and / or control CGM sensors / transmitters and / or other analytical sensors and / or other devices, such as hubs, bases, devices, insulin pumps, infusion pumps and / or patient care devices. In some embodiments, the remote interface and / or one or more applications on the remote interface can be password protected or otherwise protected 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 can 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, preference settings, etc.

[0514] Fig.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 an 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, Fig. 9 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 bases, 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 in the monitoring server 3. For example, the patient's name can be removed and replaced with a random serial number or other indicator 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, and a cloud server.

[0516] Fig.11 701 is a flow chart of a method 701 for aggregating patient care parameters from multiple 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, Fig. 9 Patient care devices 14, 15, 16, 17, 904, 906, 908 or other patient care devices disclosed herein.

[0517] Step 703 is to monitor the server (eg Figure 1 , 3 , 5, 7, 8 or 9) and a plurality of patient care devices associated with a plurality of patients. Optionally, a plurality of patient care devices may be associated with a single patient, and / or a plurality of patient care devices may 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 a monitoring server, for example, in a database such as an SQL database, a relational database, and an associative database. Step 707 may be performed automatically and / or electronically. Step 711 treats a subset of patients from a plurality of patients using a treatment regimen. For example, a patient with hypertension may be treated with a drug designed to lower blood pressure. Step 713 analyzes a subset of a plurality of patient care parameters associated with a plurality of patients to determine the efficacy of the treatment. For example, all patients who received a blood pressure medication in step 711 may compare their blood pressure to a blood pressure reading after a predetermined amount of time (e.g., 6 months) to determine whether the treatment is effective for one or more patients.

[0519] Fig.12 is a flow chart of a recovery method 801 for 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 perform method 801 such that the patient-care device is 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 Fig. 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 may be anything related to the operation of the device. For example, an operating parameter may be a speed of an infusion pump motor, a limit on the infusion pump speed, a watt limit on 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 for operating 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 a working memory of the patient-care device; and, step 821 loads the one or more patient-care parameters into a working memory of the patient-care device. Step 823 resumes operation of the patient-care device.

[0526] Now turn to Fig.13 , a flowchart 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 is shown. 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, Fig. 9 Monitoring client 902, Figure 1 , 3 , 5, 7, 8 or 9 of the remote communicator 11, cellular phone, handheld computer, tablet computer, laptop computer, personal computer and personal digital assistant, etc. Although method 900 describes pairing between a monitoring client and a patient care device, in some embodiments, method 900 can be used to pair a hub (e.g., Figure 8 The hub 802 of FIG. 804 is paired with a patient-care device (eg, patient-care devices 830 , 810 , 812 , and 814 ) to pair a first patient-care device (eg, Figure 8 of 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 Fig. 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, a touch screen, a display, buttons, an accelerometer for user input, etc.) within an operating distance 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 a 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, the user may touch the touch screen 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, the pairing of the patient care device with the monitoring client can be performed using Bluetooth, low-power Bluetooth (IEEE 802.15.1), WiFi, infrared communication, near field communication (NFC ISO13157), IR communication, or optically. As can be understood based on the present disclosure, a customized pairing protocol can also be used, which may or may not use 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 another patient care device or operatively communicates 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 tube to communicate with the patient care device. The 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 to a 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, a hub, a pedestal, a patient-care device, and / or a system monitor and one or more of the monitoring client, a hub, a pedestal, a patient-care device, and / or a 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 are configured using a second communication link; for example, near field communication or IR communication can establish pairing between the devices using, for example, Bluetooth, Bluetooth low energy, or WiFi. Establishment of 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, which 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 give the user an option on the touch screen 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, etc. A pairing, for example, that can be used for a pump patient care device or an insulin pump can be found in the following applications: (1) patent application entitled “INFUSION PUMP METHODS AND SYSTEMS” to Mandro et al., filed on 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 on 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 on 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] Fig.141 is a flow chart of a method 10000 for monitoring the operation of a patient-care device using a wearable system monitor paired with a patient-care device according to an embodiment of the present disclosure. The method 1000 includes steps 1014-1040, and various devices 1002, 1004, 1006, 1008, 1100, 1112 may be utilized to facilitate the pairing of 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 may 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 may 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, Fig. 9 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, Fig. 9 The system 900 may be used with a standalone 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: voice recognition algorithms, facial recognition algorithms, barcodes, RFID tags, near field communications, simple logins, secure signatures, etc. For example, the identification of the caregiver in step 1040 can be performed using an onboard camera and / or microphone through a monitoring client, a monitoring client docking station, a device docking station, through a communication module, other bases, or hubs. Moreover, as a safety check, the monitoring client, hub, base, or patient care device can request the user to enter in the displayed font to prevent font corruption errors. Additionally or alternatively, in some embodiments, if the device can capture a picture and store the picture after one or more failed logins or authentications, the picture can be sent to be stored in a middleware server. Step 1016 records the presence of the caregiver in one or more of the devices 1002-1012. The log entry may 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 log of step 1016 may be used for caregiver compliance and diagnostic purposes, etc. For example, if a caregiver was scheduled to appear but did not appear, step 1016 may record that the caregiver did not appear at the scheduled time.

[0536] The facial recognition algorithm of step 1014 may 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 may 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 may use hidden Markov models, speech recognition based on dynamic time normalization, or other speech recognition algorithms.

[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 so that it is attached to the patient using a wristband similar to a watch wristband; a portion of the wearable system monitor can be detached from a base, which 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. Fig.14 In method 1000, the timer and related steps are optional.

[0538] The timer of step 1020 tracks the amount of time that the wearable system monitor is detached from its base. If a predetermined amount of time has passed since the wearable system monitor was detached from the wearable base, then step 1022 stops the therapy. For example, the wearable system monitor of method 1000 can signal an infusion pump to stop pumping. When the wearable system monitor is re-docked, if the therapy was interrupted, e.g., after a predetermined amount of time has passed since the wearable system monitor was detached from its wearable base, then step 1024 resumes the therapy.

[0539] As described above, step 1018 separates the wearable system monitor from the wearable base. Step 1026 uses one or more of the following items, such as voice recognition algorithms, facial recognition algorithms, bar codes, RFID tags, near field communications, simple logins, and caregiver entries, etc. to identify the patient. Step 1026 can be similar to step 1014, can utilize the same software used in step 1014, and / or can utilize one of devices 1002-1020. However, in some embodiments, please note that the patient identification process can include more than just the identification of the caregiver by using, for example, biometrics or other identification patient characteristic information. Such patient identification criteria can be used to ensure that specific treatment is given to the correct patient and / or meets a given regulation. 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, the method 1000 blocks additional 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 particular treatment is given to the correct patient and / or that a given regulation is met.

[0541] A list of patient-care devices available for pairing on one or more user interfaces of devices 1002-1012 may be provided to the caregiver. During step 1030, the caregiver selects a wearable system monitor (e.g., the patient wearable system monitor of step 1018) and a patient-care device for pairing 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 identity of the caregiver and the patient. In another specific embodiment, the pairing of the wearable system monitor with the patient-care device may 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.). It will be appreciated from the present disclosure that any suitable pairing protocol (e.g., Bluetooth or IEEE 802.11) may be used. Additionally or alternatively, step 1034 may record the pairing into 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 by signaling the patient-care device associated with the patient-care device to cease operation (in some embodiments), and send a notification to the monitoring client (e.g., Figure 1 , 3 , 5, 7, 8 monitoring clients 1, 4 or 11, Fig. 9 The monitoring client 9, 4 or 11 or other monitoring client disclosed herein) sends a warning. If the treatment is interrupted, step 1024 can resume the 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 the therapy settings, for example, on a monitoring client, a hub, a remote communicator, or on a patient-care device.

[0544] Fig.15 1 is a flow chart of a method 1100 for displaying a user interface using a user interface template according to an embodiment of the present disclosure. The method 1100 includes steps 1102-1132. In some embodiments, each of steps 1102-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, Fig. 9 The monitoring client 9, 4 or 11 of method 1100, or other monitoring clients disclosed herein. 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, Fig. 9 Patient care devices 14, 15, 16, 17, 904, 906, 908, or other patient care devices disclosed herein.

[0546] Although 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 with specific fields for displaying patient care parameters. For example, a user interface template for an infusion pump can define specific fields for display 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 on 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 of one or more patient care devices to the user. 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 a provider for treating a patient. Additionally or alternatively, in step 1102, a list of patient-care devices to select from may be presented to the provider to display information about the operation of the selected patient-care device 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 transmits 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 transmits 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 (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 alarm 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 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, patient care parameters, such as 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 in the monitoring client based on the determined type, step 1124 displays a selectable list of multiple user interface templates on the user interface of the monitoring client; additionally or alternatively, step 1114 may issue a warning or alarm via the monitoring client and / or the patient care device. Step 1126 allows the user to select a user interface template from the multiple 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 above-mentioned user interface template. The font can be stored in any format such as JPEG, BMP, image format, and pre-stored fonts, and can be sent for use in a field for providing an indication of an operating parameter (e.g., instead of sending a value, an image is sent that shows a number or value that is then displayed on the monitoring client). In some embodiments, a font stored in a monitoring client can be used so that the value of the operating parameter is sent to the monitoring client for display in a template using the font stored in the monitoring client.

[0552] Fig.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. Fig.16 In method 1134, although the monitoring device is described herein as an exemplary device for controlling a 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, Fig. 9 The monitoring client 9, 4 or 11, or other monitoring clients disclosed herein. Optionally, the patient care device of method 1134 can be one 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, Fig. 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 of monitoring server 3.

[0554] Step 1136 docks the patient care device into the base. For example, Figure 1 , 3 , the infusion device 7 of 5 or 7, Figure 8 Infusion device 830, 810 or 812, or Fig. 9The infusion device 904 can be docked into the corresponding base. In step 1138, the monitoring client identifies the patient care device. For example, the patient care device can transmit, for example, an ID number, a serial number, instructions, a prescription, a treatment plan, patient treatment parameters, etc. to the monitoring client, for example, 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 a 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 is communicatively and operably connected 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 Fig.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, 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 criteria.

[0556] Fig.17 1 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, Fig. 9 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, cellular phone, handheld computer, tablet computer, laptop computer, personal computer and personal digital assistant, etc.

[0558] Step 1202 uses the user interface...

Claims

1. An electronic patient monitoring system comprising: a first module monitoring client configured to receive and store information related to a patient, the information comprising: data related to a first parameter of the patient measured by a device connected to the patient; and data related to a second parameter of the patient received from a first database containing information about the patient; and a second module, the second module being configured to receive a treatment 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, a communication device, the communication device being configured to receive the treatment order from the user via the user interface and send the treatment order to the monitoring client, wherein the monitoring client is further configured to: obtaining, from a second database, medication information regarding a medication or other medication associated with the treatment order, the medication information including data providing constraints under which the medication is typically administered; determining whether the first parameter of the patient is outside a predetermined range; requesting the device to take an unscheduled reading to determine a third parameter of the patient when the first parameter is determined to be outside of a predetermined range, wherein the third parameter of the patient is measured by the device, wherein the request is performed if the first parameter is determined to be outside of a predetermined range; when the first parameter is determined to be outside a predetermined range, verifying the authenticity of the second parameter by using the third parameter; determining whether the treatment order must be confirmed by the second module communication device based on the medication information, the value of the first parameter, and the value of the second parameter; and A pre-established message is sent from the first module monitoring client to the second module communication device for display on the user interface, the message confirming or warning regarding the acceptability of the medication order.

2. The electronic patient monitoring system of claim 1, wherein: The drug information includes 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 medications, known drug allergy history, current blood pressure, current pulse rate, current heart rhythm, current respiratory rate or current ventilation.

3. The electronic patient monitoring system of claim 2, wherein: The pre-established message includes a warning regarding a potential effect of a prescribed medication, the warning including measured data regarding the first parameter, received data regarding the second parameter, or medication information obtained by the first module monitoring client.

4. The electronic patient monitoring system of claim 3, wherein: The first module monitoring client is configured to generate a signal that the medication order should be carried out or a modified medication order after the pre-established message has been sent and a confirmation signal has been received from the second module communication device, and the confirmation signal is triggered by an input signal from the user interface.

5. The electronic patient monitoring system of claim 3, wherein: The first parameter is associated with a timestamp.

6. The electronic patient monitoring system of claim 3, wherein: The third parameter is associated with a timestamp.

7. The electronic patient monitoring system of claim 3, wherein: The monitoring client is further configured to record the first parameter in the first database and associate the first parameter with the patient.

8. The electronic patient monitoring system of claim 3, wherein: The monitoring client is further configured to record the first parameter in the first database and, if the first parameter of a patient is outside of the predetermined range, associate the first parameter with the patient.

9. The electronic patient monitoring system of claim 3, wherein: The monitoring client is further configured to interrupt the infusion pump based on at least one of the first parameter and the third parameter.

10. The electronic patient monitoring system of claim 3, wherein: The monitoring client is further configured to adjust an infusion pump based on at least one of the first parameter and the third parameter.

11. The electronic patient monitoring system of claim 10, wherein: The monitoring client is configured to adjust one of: a flow rate of the infusion pump, an operating parameter of the infusion pump, and a therapy parameter of the infusion pump.

12. The electronic patient monitoring system of claim 3, wherein: The monitoring client includes a display, and the monitoring client is configured to display an indication of a status of a patient-care device on an outer border of the display.

13. The electronic patient monitoring system of claim 3, wherein: The monitoring client includes a display, and the monitoring client is configured to display an indication of the progress of a patient-care device on an outer border of the display.

14. The electronic patient monitoring system of claim 13, wherein: The indication of progress is displayed by illuminating a percentage of the border, wherein the percentage of the border corresponds to a percentage of progress of the patient-care device.

15. A monitoring client, comprising: monitor; as well as at least one processor coupled to the display, wherein the at least one processor is configured to: receiving and storing information related to a patient, the information comprising: data related to a first parameter of the patient measured by a device connected to the patient; and data related to a second parameter of the patient received from a first database, the first database containing information about the patient; Receive medical treatment orders; obtaining, from a second database, medication information regarding a medication associated with the treatment order, the medication information including data providing restrictions under which the medication is typically administered; determining whether the first parameter of the patient is outside a predetermined range; requesting the device to take an unscheduled reading to determine a third parameter of the patient when the first parameter is determined to be outside of a predetermined range, wherein the third parameter of the patient is measured by the device, wherein the request is performed if the first parameter is determined to be outside of a predetermined range; when the first parameter is determined to be outside a predetermined range, verifying the authenticity of the second parameter by using the third parameter; determining whether the treatment order must be confirmed by the communication device; and A pre-established message is sent from the monitoring client to the communication device for display on a user interface, the message confirming or warning regarding the acceptability of the treatment order.

16. The monitoring client according to claim 15, wherein: The processor is further configured to record the first parameter in the first database and associate the first parameter with the patient.

17. The monitoring client according to claim 15, wherein: The processor is further configured to record the first parameter in the first database and, if the first parameter for a patient is outside of the predetermined range, associate the first parameter with the patient.

18. The monitoring client according to claim 15, wherein: The processor is further configured to interrupt an infusion pump based on at least one of the first parameter and the third parameter.

19. The monitoring client according to claim 15, wherein: The processor is further configured to adjust an infusion pump based on at least one of the first parameter and the third parameter.

20. The monitoring client according to claim 15, wherein: The processor is further configured to display an indication of a status of a patient-care device on an outer border of the display.

Images