Systems, methods, and apparatus for electronic patient care

Abstract

To provide systems, methods, and apparatus for electronic patient care. [Solution] The method for electronic patient care is implemented by an operable set of processor-executable instructions configured to be executed by a processor. The method includes the following actions: determining whether a monitoring client is connected to a base through a physical connection; establishing a first communication link between the monitoring client and the base through the physical connection; updating the interface programs on the monitoring client and the base through the first communication link if necessary; establishing a second communication link between the monitoring client and the base using the first communication link; and transmitting data from the base to the monitoring client using the second communication link.

Description

Technical Field

[0001] Cross-reference of related applications This application is a non-provisional patent application claiming priority from U.S. Provisional Patent Application No. 61 / 740,474, entitled "Systems, Methods, and Apparatus for Communication Data" (Attorney Docket No.: J80), filed on December 21, 2012, which is incorporated herein by reference in its entirety.

[0002] This application is also U.S. Patent Application No. 13 / 723,253, entitled "Systems, Methods, and Apparatus for Electronic Patient Care", filed on December 21, 2012, and is a partial continuation application of U.S. Patent Application Publication No. 2013-0191413A1 (Attorney Docket No.: J85), published on July 25, 2013, which claims priority from the following applications: U.S. Provisional Patent Application No. 61 / 578,649, entitled "Systems, Methods, and Apparatus for Infusion" (Attorney Docket No.: J02), filed on December 21, 2011; U.S. Provisional Patent Application No. 61 / 578,658, entitled "Systems, Methods, and Apparatus for Estimating Infusion Delivery Amount" (Attorney Docket No.: J04), filed on December 21, 2011; U.S. Provisional Patent Application No. 61 / 578,674, entitled "Systems, Methods, and Apparatus for Oral Medication Administration" (Attorney Docket No.: J05), filed on December 21, 2011; U.S. Provisional Patent Application No. 61 / 651,322, entitled "Systems, Methods, and Apparatus for Electronic Patient Care" (Attorney Docket No.: J46), filed on May 24, 2012; and U.S. Provisional Patent Application No. 61 / 679,117, entitled "Systems, Methods, and Apparatus for Monitoring, Adjusting, or Controlling Infusion Flow" (Attorney Docket No.: J30), filed on August 3, 2012. Each of the above applications is incorporated herein by reference in its entirety. U.S. Patent Application No. 13 / 723,253 is U.S. Patent Application No. 13 / 333,574, filed on December 21, 2011, entitled “System, Method and Apparatus for Electronic Patient Care,” and subsequently published on July 19, 2012, U.S. Patent Application Publication No. 2012-0185267A1 (Agent Reference Number: J97) and This is a continuation-in-part application of PCT application PCT / US11 / 66588 (Agent Reference Number: I97WO) filed on 21 December 2011, entitled “System, Method and Apparatus for Electronic Patient Care,” both of which are incorporated herein by reference in whole. U.S. Patent Application No. 13 / 333,574 is a continuation of U.S. Patent Application No. 13 / 011,543, filed on 21 January 2011, entitled “Electronic Patient Monitoring System,” and subsequently published on 22 December 2011, entitled U.S. Patent Publication No. 2011-0313789A1 (Agent Reference Number: I52). This application claims priority from U.S. Provisional Patent Application No. 61 / 297,544, filed on 22 January 2010, entitled “Electronic Instruction Intermediation System for Medical Equipment” (Agent Reference Number: H53), both of which are incorporated herein by reference in their entirety.

[0003] This application is also a continuation of U.S. Patent Application No. 13 / 723,239, filed on 21 December 2012, entitled “System, Method and Apparatus for Electronic Patient Care,” and subsequently published on 7 November 2013, entitled U.S. Patent Publication No. 2013-0297330A1 (Agent Reference Number: J77), which claims priority to: U.S. Provisional Patent Application No. 61 / 578,649, filed on 21 December 2011, entitled “System, Method and Apparatus for Infusion,” (Agent Reference Number: J02); U.S. Provisional Patent Application No. 61 / 578,658, filed December 21, 2011, entitled "System, Method, and Apparatus for Estimating Intravenous Fluid Delivery Volume" (Agent Reference Number: J04); U.S. Provisional Patent Application No. 61 / 578,674, filed December 21, 2011, entitled "System, Method, and Apparatus for Oral Drug Administration" (Agent Reference Number: J05); U.S. Provisional Patent Application No. 61 / 651,322, filed on May 24, 2012, entitled “System, Method and Apparatus for Electronic Patient Care” (Agent Reference Number: J46); and U.S. Provisional Patent Application No. 61 / 679,117, filed August 3, 2012, entitled “System, Method and Apparatus for Monitoring, Regulation or Controlling Infusion Flow” (Agent Reference Number: J30). Each of the foregoing is incorporated herein by reference in whole. U.S. Patent Application No. 13 / 723,239 claims priority to the following applications and is a continuation-in-part application of the following applications: This is U.S. Patent Application No. 13 / 333,574, filed on 21 December 2011, entitled “System, Method and Apparatus for Electronic Patient Care,” and subsequently published on 19 July 2012, U.S. Patent Publication No. 2012-0185267A1 (Agent Reference Number: J97). This application is a continuation of U.S. Patent Application No. 13 / 011,543, filed on 21 January 2011, entitled “Electronic Patient Monitoring System,” and subsequently published on 22 December 2011, U.S. Patent Publication No. 2011-0313789A1 (Agent Reference Number: I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, filed on 22 January 2010, entitled “Electronic Instruction Intermediation System for Medical Equipment” (Agent Reference Number: H53); and This refers to PCT application PCT / US11 / 66588, filed on December 21, 2011, entitled “System, Method and Apparatus for Electronic Patient Care,” and subsequently, international application publication WO2013 / 095459 (agent reference number: I97WO), published on September 12, 2013. Each of these is incorporated herein by reference in whole.

[0004] This application is also a continuation of U.S. Patent Application No. 13 / 723,242, filed on 21 December 2012, entitled “System, Method and Apparatus for Electronic Patient Care,” and subsequently published on 28 November 2013, U.S. Patent Application Publication No. 2013-0317753A1 (Agent Reference Number: J78), which claims priority over the following applications: U.S. Patent Application No. 61 / 651,322, filed on 24 May 2012, entitled “System, Method and Apparatus for Electronic Patient Care” (Agent Reference Number: J46), is incorporated herein by reference in its entirety.

[0005] This application is also a continuation of U.S. Patent Application No. 13 / 900,655, filed on 23 May 2013, entitled “System, Method and Apparatus for Electronic Patient Care,” and subsequently published on 28 November 2013, entitled U.S. Patent Publication No. 2013-0317837A1 (Agent Reference Number: K66), which claims priority to U.S. Provisional Patent Application No. 61 / 651,322, filed on 24 May 2012, entitled “System, Method and Apparatus for Electronic Patient Care” (Agent Reference Number: J46), both of which are incorporated herein by reference in whole. U.S. Patent Application No. 13 / 900,655 is also a continuation-in-part application, which claims priority to the following application: This refers to U.S. Patent Application No. 13 / 480,444, filed on May 24, 2012, entitled "Blood Processing System and Method," and subsequently published on February 14, 2013, as U.S. Patent Application Publication No. 2013-0037485A1 (Agent Reference Number: J43); and This refers to PCT application PCT / US12 / 00257, filed on May 24, 2012, entitled "Blood Processing System and Method," which was subsequently published as International Publication WO2012 / 161744 (Agent Reference Number: J43WO) on November 29, 2012.

[0006] This application is also a continuation-in-part application of PCT application PCT / US13 / 42350, filed May 23, 2013, entitled “System, Method and Apparatus for Electronic Patient Care” (Agent Reference Number: K66WO), which claims priority to U.S. Provisional Patent Application No. 61 / 651,322, entitled “System, Method and Apparatus for Electronic Patient Care” (Agent Reference Number: J46), both of which are incorporated herein by reference in whole. PCT application PCT / US13 / 42350 is also a continuation-in-part application, which claims priority to the following application: This refers to U.S. Patent Application No. 13 / 480,444, filed on May 24, 2012, entitled "Blood Processing System and Method," and subsequently published on February 14, 2013, as U.S. Patent Application Publication No. 2013-0037485A1 (Agent Reference Number: J43); and This is PCT application PCT / US12 / 00257, filed on May 24, 2012, entitled "Blood Processing System and Method," and subsequently published internationally on November 29, 2012, as international publication WO2012 / 161744 (agent reference number: J43WO).

[0007] This application may also relate to one or more of the following patent applications filed on December 21, 2012, all of which are incorporated herein by reference in whole: U.S. Non-Provisional Patent Application No. 13 / 723,238 (Agent Reference Number: J47) relating to "System, Method and Apparatus for Clamping" U.S. Non-Provisional Patent Application No. 13 / 723,235 (Agent Reference Number: J74) relating to "System, Method, and Apparatus for Oral Drug Administration" PCT application PCT / US12 / 71131 (agent reference number: J74WO) relating to "Systems, methods, and apparatus for oral drug administration" U.S. Non-Provisional Patent Application No. 13 / 724,568 (Agent Reference Number: J75) for "System, Method, and Apparatus for Estimating Intravenous Fluid Delivery Volume" U.S. Non-Provisional Patent Application No. 13 / 725,790 (Agent Reference Number: J76) relating to "Systems, methods, and apparatus for intravenous fluid administration" PCT application PCT / US12 / 71490 (Agent reference number: J76WO) relating to "Systems, methods, and apparatus for intravenous fluid administration" U.S. Non-Provisional Patent Application No. 13 / 723,244 (Agent Reference Number: J79) relating to "System, Method and Apparatus for Monitoring, Regulating or Controlling Infusion Flow" PCT application PCT / US12 / 71142 (Agent reference number: J79WO) relating to "Systems, methods, and apparatus for monitoring, regulating, or controlling infusion flow" U.S. Nonprovisional Patent Application No. 13 / 723,251 (Agent Reference Number: J81) relating to "System, Method, and Apparatus for Estimating Fluid Delivery Volume"; and PCT application No. PCT / US12 / 71112 (agent reference number: J81WO) relating to "System, method and apparatus for estimating the amount of intravenous fluid delivered".

[0008] This application may also relate to one or more of the following patent applications, all of which are incorporated herein by reference in whole: U.S. Provisional Patent Application No. 61 / 738,447, filed December 18, 2012, entitled "System, Method, and Apparatus for Air Detection in a Liquid Line Using Active Rectification" (Agent Reference Number: J32); U.S. Patent Application No. 13 / 840,339, filed March 15, 2013, entitled "System, Method and Apparatus for Intravenous Fluid Infusion" (Agent Reference Number: K14); PCT application PCT / US13 / 32445, filed on March 15, 2013, entitled "System, method, and apparatus for intravenous fluid administration" (Agent reference number: K14WO); U.S. Patent Application No. 13 / 833,432, filed March 15, 2013, entitled "Syringe Pump and Related Methods" (Agent Reference Number: K21); U.S. Patent Application No. 13 / 836,497, filed on March 15, 2013, entitled "System and Apparatus for Electronic Patient Care" (Agent Reference Number: K22); U.S. Patent Application No. 13 / 833,712, filed March 15, 2013, entitled "System, Method and Apparatus for Clamping" (Agent Reference Number: K23); U.S. Patent Application No. 13 / 834,030, filed March 15, 2013, entitled "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Infusion Flow" (Agent Reference Number: K28); U.S. Provisional Patent Application No. 61 / 860,398, filed on July 31, 2013, entitled "System, Method, and Apparatus for Bubble Detection in a Liquid Line Using a Split Ring Resonant Circuit" (Agent Reference Number: J31); U.S. Provisional Patent Application No. 61 / 900,431, filed November 6, 2013, entitled "System, Method and Apparatus for Monitoring, Regulation or Controlling Infusion Flow" (Agent Reference Number: K52); U.S. Provisional Patent Application No. 61 / 894,801, filed October 23, 2013, entitled "Syringe Pump and Related Methods" (Agent Reference Number: K88); U.S. Provisional Patent Application No. 61 / 843,574, filed on July 8, 2013, entitled "System, Method and Apparatus for Clamping" (Agent Reference Number: K74); U.S. Patent Application No. 13 / 971,258, filed on August 20, 2013, entitled “Electronic Patient Monitoring System” (Agent Reference Number: K84); U.S. Provisional Patent Application No. 61 / 904,123, filed November 14, 2013, entitled "Syringe Pump and Related Methods" (Agent Reference Number: L33); U.S. Patent Application No. 14 / 101,848, filed December 10, 2013, entitled "System, Method, and Apparatus for Bubble Detection in a Liquid Line Using a Split Ring Resonant Circuit" (Agent Reference Number: L05); U.S. patent application filed December 20, 2013, for "System, method, and apparatus for data communication" (Agent reference number: L49); PCT application filed on December 20, 2013, concerning "Systems, methods, and apparatus for data communication" (Agent reference number: L49WO); U.S. Patent Application filed December 20, 2013, for "Computer-Implemented Methods, Systems, and Apparatus for Electronic Patient Care" (Agent Reference Number: K50); PCT application filed on December 20, 2013, relating to "Computer-implemented methods, systems and apparatus for electronic patient care" (Agent reference number: K50WO); and U.S. Patent Application related to "System, Method and Apparatus for Electronic Patient Care" filed on December 20, 2013 (Attorney Docket No.: L52).

[0009] Technical field This disclosure relates to patient care. More particularly, this disclosure relates to systems, methods, and apparatuses for electronic patient care.

Background Art

[0010] Providing patient care in a hospital generally requires the interaction of many specialists and caregivers (e.g., physicians, nurses, pharmacists, technicians, nurse practitioners, etc.) and a number of medical devices / systems necessary for the treatment of a given patient.

Summary of the Invention

Problems to be Solved by the Invention

[0011] Despite the existence of systems intended to facilitate care processes such as those incorporating electronic medical records (EMR) and computerized provider order entry (CPOE), the process of providing comprehensive care to patients, including instructing and delivering medical treatments such as medications, is associated with several important problems.

Means for Solving the Problems

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

[0013] In other embodiments, the electronic patient care system can provide the user with editable default values ​​derived from standard medication and administration guidelines obtained from a drug information database, and can alert the user to changes that may be indicated based on the patient's current and existing medical conditions, allergies, existing medications, or other patient status parameters. Preferably, the electronic patient care system minimizes the amount of typing input required from the user.

[0014] In other embodiments, the first module or other modules of the electronic patient care system may also be used to identify prescribed medications to be delivered to the patient's bedside (e.g., via barcodes and readers, or RFID tags and scanners) and to verify that the appropriate medications and dosages have been prepared and delivered to the patient. In one embodiment, the first module may also interact with a patient care device administering treatment, such as an infusion pump or pill dispenser, via a wired or wireless communication link. In the case of an infusion pump, the first module or another connected module may provide the infusion pump with patient treatment parameters, such as infusion setpoints including infusion rate or infusion pressure, from which it may receive various operating parameters, such as the presence of air in the infusion line, the amount of solution remaining in the connected intravenous bag, or the pressure of the fluid in the infusion line. If an abnormality is detected in the operating parameters, the first module may be configured to respond by signaling the infusion pump to interrupt the infusion, by signaling a mechanical occlusion to occlude the venous line, by changing the infusion rate, and / or by directly using an alarm built into the first module or by transmitting the alarm to the second module, thereby alerting a healthcare provider or the like. In another embodiment, the first module may also be configured to monitor the patient's condition and communicate with various patient care devices used to determine patient condition parameters, such as blood pressure monitors, ECG monitors, pulse oximetry monitors, and temperature monitors. The various parameters measured can be monitored and / or recorded by the portable device and / or within the EMR. In some cases, the first module may be programmed to alert the patient or other person if the monitored patient condition parameters are outside a predetermined range. In some embodiments, the first module may transmit a signal to the monitoring client to perform measurements not scheduled by the patient care device to obtain other patient condition parameters.The first module can communicate with various healthcare providers at various locations, and in one embodiment, the first module can notify an assigned patient of an abnormality, for example, by audible alert or recorded message, recommending corrective action.

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

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

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

[0018] The sandbox component is configured to control access to at least one of hardware and software resources. The hub is further configured to identify patient care devices, run applications, and monitor patient care devices. The hub can run applications within the sandbox component, thereby allowing the applications to access at least one of hardware and software resources through the sandbox component.

[0019] The hub may be further configured to control patient care devices. Patient care devices may include one or more of the following: infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters, CO2 capnometers, intravenous bags, and / or infusion flowmeters.

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

[0021] Hardware resources may include disk drives, memory, buzzers, microphones, speakers, and cameras. Software resources may include variables, secure data objects, secure variables, protected APIs, APIs, and software representations of hardware components.

[0022] In yet another embodiment, the system for electronic patient care includes a hub. The hub is configured to monitor patient care devices. A sandbox may be configured to control access to at least one of hardware resources and software resources. The hub is further configured to identify patient care devices, run applications, and monitor patient care devices. The hub runs applications within a sandbox component, thereby allowing the applications to access at least one of hardware resources and software resources through the sandbox component. The hub may be further configured to control patient care devices. The hub may be further configured to receive identification information from patient care devices and download applications from servers associated with the identification information. The hub may be further configured to receive identification information from patient care devices and update applications from servers associated with the identification information.

[0023] Hardware resources may include disk drives, memory, buzzers, microphones, speakers, and cameras. Software resources may include variables, secure data objects, secure variables, protected APIs, APIs, and software representations of hardware components.

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

[0025] Patient care devices may include infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters and / or CO2 capnometers, intravenous bags, and infusion flow meters.

[0026] The monitoring client may be further configured to receive identification information from the patient care device and download applications from the server associated with the identification information. The monitoring client may also be further configured to receive identification information from the patient care device and update applications from the server associated with the identification information.

[0027] Hardware resources may include disk drives, memory, buzzers, microphones, speakers, and cameras. Software resources may include variables, secure data objects, secure variables, protected APIs, APIs, and software representations of hardware components.

[0028] In yet another embodiment, a system for electronic patient care includes a monitoring client configured to monitor patient care devices. The monitoring client includes a sandbox component configured to control access to at least one of hardware resources and software resources. The monitoring client may be further configured to identify patient care devices, run an application, and monitor the patient care devices. The monitoring client runs the application within the sandbox component, thereby allowing the application to access at least one of hardware resources and software resources through the sandbox component. The monitoring client may be further configured to control patient care devices.

[0029] Patient care devices may include infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters and / or CO2 capnometers, intravenous bags, and infusion flow meters.

[0030] The monitoring client may be further configured to receive identification information from the patient care device and download applications from the server associated with the identification information. The monitoring client may also be further configured to receive identification information from the patient care device and update applications from the server associated with the identification information.

[0031] Hardware resources may include disk drives, memory, buzzers, microphones, speakers, and cameras. Software resources may include variables, secure data objects, secure variables, protected APIs, APIs, and software representations of hardware components.

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

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

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

[0035] In one embodiment, the monitoring client dock and the device dock are configured to communicate wirelessly and, on the other hand, through cables operably coupled to the monitoring client dock and the device dock.

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

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

[0038] In another embodiment, the monitoring client uses wireless communication with the monitoring client dock to communicate at least one patient care parameter in an operational manner when the monitoring client determines that at least one of the following is the case: communication via cable is unavailable, or the monitoring client has been undocked from the monitoring client dock.

[0039] In another embodiment, the device dock is configured to communicate wirelessly with a monitoring client, which communicates wirelessly with the device dock to send at least one patient care parameter to the docked patient care device, thereby enabling operational communication with the patient care device.

[0040] In another embodiment, the monitoring client uses wireless communication with the device dock to communicate at least one patient care parameter in an operable manner when the monitoring client determines that at least one of the following is not possible: communication via cable is not available; communication between the monitoring client and the monitoring client dock is not available; or the monitoring client has been undocked from the monitoring client dock.

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

[0042] In another embodiment, the monitoring client communicates at least one patient care parameter wirelessly with the patient care device when the monitoring client determines that at least one of the following is not possible: communication via cable is unavailable; communication between the monitoring client and the monitoring client dock is unavailable; communication between the device dock and the patient care device is unavailable; and the monitoring client has been undocked from the monitoring client dock.

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

[0044] In another embodiment, the monitoring client is configured to communicate with the patient care device via multiple communication links, and the monitoring client communicates via whichever of the multiple communication links is operational.

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

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

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

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

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

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

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

[0052] In yet another embodiment, a system for electronic patient care comprises a patient care device configured to communicate at least one patient care parameter, a hub client configured to communicate at least one patient care parameter, and a device dock configured to receive the patient care device for docking therein. The hub can be plugged into the device dock to establish a communication link between them. The system may further include a monitoring client that operably communicates with the hub to receive at least one patient care parameter. Patient treatment parameters can be operably communicated to the hub, which then communicates the patient treatment parameters to the patient care device.

[0053] In certain embodiments, the hub may include a user interface, and the hub may require user authentication before transmitting patient treatment parameters to the patient care device.

[0054] In certain embodiments, the monitoring client may include a user interface, and the monitoring client may require user authentication before transmitting patient treatment parameters to the patient care device through the hub.

[0055] In certain embodiments, the patient care device may include a user interface, and the patient care device may require user authentication of patient treatment parameters before treating the patient.

[0056] The hub can be configured to monitor patient care devices. In certain embodiments, the hub may include a sandbox component configured to control access to at least one of hardware and software resources.

[0057] The hub can also be configured to identify patient care devices, run applications, and monitor them. The hub can run applications within a sandbox component, thereby allowing the applications to access at least one of hardware and software resources through the sandbox component.

[0058] In another embodiment, a system for electronic patient care comprises: at least one patient monitor adapted to monitor at least one patient parameter; a monitoring client operably communicating with the at least one patient monitor to receive at least one patient parameter from it; and a monitoring server operably communicating with the monitoring client to receive at least one patient parameter from the monitoring client.

[0059] In another embodiment, the system may further include a remote communicator that operably communicates with at least one patient monitor and receives at least one patient parameter.

[0060] At least one patient monitor may comprise at least one of the following: an electrocardiogram monitor, a blood pressure monitor, a pulse oximeter monitor, and a CO2 capnometer. The monitoring client may be configured to download patient information according to a designated unique patient identifier. The unique patient identifier may be encoded on a barcode placed on a wristband. The unique patient identifier may be encoded on an RFID tag (e.g., an RFID caller) attached to the wristband. The patient information may include patient status or patient care parameters. The unique patient identifier may be operably transmitted to the monitoring server to obtain electronic authorization to communicate patient-specific data. A subset of patient-specific data may be stored in the monitoring client's memory. The monitoring client may be adapted to determine whether a new instruction meets predetermined criteria based on the subset of patient-specific data stored in memory.

[0061] In another embodiment, the system further includes a portable monitoring client adapted to present new instructions to the monitoring client. At least one of the monitoring clients and / or remote communicators may be adapted to communicate new instructions to a monitoring server, which may be adapted to determine whether the new instructions meet other predetermined criteria.

[0062] In another embodiment, the new instruction may be a drug instruction, and the monitoring server may be configured to determine whether the new instruction meets another predetermined criterion by determining whether the drug instruction is contraindicated to any currently prescribed medication. The monitoring server can communicate with a database to determine whether the new instruction meets another predetermined criterion. The monitoring server may be configured to send an alert to the monitoring client if the new instruction does not meet the other predetermined criterion.

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

[0064] In another embodiment, the monitoring client may be a desk-based device, a portable device, a handheld controller, a notebook PC, a netbook PC, a tablet PC, or a smartphone. The monitoring client is equipped with a touchscreen.

[0065] In another embodiment, the system may further include an injection pump, and the monitoring client operably communicates with the injection pump. The injection pump may be attachable to the monitoring client. The injection pump may be detachable from the monitoring client.

[0066] In another embodiment, the system further includes a dock configured to dock a monitoring client with the injection pump.

[0067] In another embodiment, the monitoring client communicates operably with the injection pump via a wireless link.

[0068] In another embodiment, the monitoring server is configured to communicate with multiple databases, at least one of which includes a different data format or communication protocol than the other databases.

[0069] In another embodiment, the monitoring server is adapted to format data from multiple databases and download the data to the monitoring client. Optionally, and in some specific embodiments, the monitoring client may communicate at least one patient parameter to the monitoring server. In certain embodiments, the patient parameter may be one or more of the following: the progress of treatment with an infusion pump, an electrocardiogram signal, a blood pressure signal, a pulse oximeter signal, a CO2 capnometer signal, and / or a temperature signal, and / or include at least one of these.

[0070] In another embodiment, the monitoring server may be configured to download operational instructions to the injection pump via the monitoring client.

[0071] The monitoring client can receive user requests and read patient parameters, and can also query the monitoring device to receive patient parameters.

[0072] In another embodiment, the system may further include a portable monitoring client. The portable monitoring client may communicate operationally with the monitoring client to communicate patient information directly, thereby bypassing the monitoring server. The portable monitoring client may be configured to change at least one parameter of the infusion pump and communicate that at least one changed parameter to the monitoring server.

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

[0074] In another embodiment, the monitoring client is configured to periodically upload information to the monitoring server and store it in a patient-specific database.

[0075] The system can also include a separate monitoring client adapted to receive information from a patient-specific database.

[0076] The information may include at least one of the following: patient instructions, patient medications, progress notes, monitoring data from patient monitors, and treatment data from attached devices.

[0077] The monitoring server can be configured to query an electronic health record database and receive patient information from it. The monitoring server can also be configured to input a predetermined set of information to the monitoring client based on the patient information.

[0078] The information in the specified set may include at least one of the following: patient's age, height, weight, diagnosis, current medications, medication category, and drug allergies and hypersensitivity.

[0079] 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 a tablet PC, a netbook, or a PC. The remote portable monitoring client may be equipped with a touchscreen.

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

[0081] In some specific embodiments, the above method may further include the step of transmitting alerts from a monitoring client to a portable remote communicator device having a display.

[0082] In yet another embodiment, the electronic patient care system comprises: a monitoring client configured to communicate at least one patient care parameter; a patient care device configured to communicate at least one patient care parameter; and a communication interface configured to facilitate communication between the monitoring client and at least one patient care device by detecting the presence of at least one patient care device and translating communication signals from that device into a communication protocol associated with the monitoring client.

[0083] In certain embodiments, the communication interface is further configured to detect the presence of additional other patient care devices that are different from each other and to translate communication signals from these devices into the communication protocol associated with the monitoring client.

[0084] In another specific embodiment, the communication interface is further configured to provide a power supply suitable for each device. In yet another specific embodiment, the system further comprises one or more databases accessible by a monitoring client, taking into account at least one central storage of patient information, and / or downloadable information that can be used for the treatment of patients associated with the monitoring client.

[0085] In yet another specific embodiment, the communication interface is further configured to perform fault checks on at least one of the following: evaluating the data integrity of communications with the 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.

[0086] In yet another embodiment, the electronic patient care system comprises: a hub client configured to communicate at least one patient care parameter; a patient care device configured to communicate at least one patient care parameter; and a communication interface configured to facilitate communication between the hub and at least one patient care device by detecting the presence of at least one patient care device and translating communication signals from that device into a communication protocol associated with the hub.

[0087] In certain embodiments, the communication interface is further configured to detect the presence of additional other patient care devices that are different from each other and to translate communication signals from those devices into the communication protocol associated with the hub.

[0088] In another specific embodiment, the communication interface is further configured to provide a power supply suitable for each device. In yet another specific embodiment, the system further comprises one or more databases accessible by a hub that takes into account at least one central storage of patient information, and / or downloadable information that can be used for the treatment of patients associated with the hub.

[0089] In yet another specific embodiment, the communication interface is further configured to perform fault checks on at least one of the following: evaluating the data integrity of communications with the 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.

[0090] In yet another embodiment, the electronic patient care system comprises: a dock configured to communicate at least one patient care parameter; a patient care device configured to communicate at least one patient care parameter; and a communication interface configured to facilitate communication between the dock and the at least one patient care device by detecting the presence of the at least one patient care device and translating the communication signals from the device into a communication protocol associated with the dock.

[0091] In certain embodiments, the communication interface is further configured to detect the presence of additional other patient care devices that are different from each other and to translate communication signals from those devices into the communication protocol associated with the dock.

[0092] In another specific embodiment, the communication interface is further configured to provide a power supply suitable for each device. In yet another specific embodiment, the system further comprises one or more databases accessible by the dock, taking into account at least one central storage of patient information, and / or downloadable information that can be used for the treatment of patients associated with the dock.

[0093] In yet another specific embodiment, the communication interface is further configured to perform fault checks on at least one of the following: evaluating the data integrity of communications with the 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.

[0094] In one embodiment, the patient care device comprises: a main body; conduits within the main body configured to receive a support column; and two friction members coupled to the main body and configured to frictionally lock the main body to the support column within the conduits.

[0095] In one embodiment, the hub comprises: a patient care device interface; a power supply coupled to the patient care device interface and configured to supply power to the patient care device; a processor; and a transceiver coupled to the patient care device interface and configured to enable communication between the processor and the patient care device. In some specific embodiments, the processor may be configured to disable the patient care device if it is in an alarm state.

[0096] In one embodiment, the dock comprises: a patient care device interface; a power supply coupled to the patient care device interface and configured to supply power to the patient care device; a processor; and a transceiver coupled to the patient care device interface and configured to enable communication between the processor and the patient care device. In some specific embodiments, the processor may be configured to disable the patient care device if it is in an alarm state.

[0097] In one embodiment, the communication module comprises: a patient care device interface; a power supply coupled to the patient care device interface and configured to power the patient care device; a processor; and a transceiver coupled to the patient care device interface and configured to enable communication between the patient care device and another device. In some specific embodiments, the processor may be configured to disable the patient care device if it is in an alarm state.

[0098] In another embodiment, the patient care system comprises: a dock; a plurality of modular patient care devices configured to dock with the dock; and a retractable display for a monitoring client. The modular patient care devices may interface with the dock horizontally, either staggered or via connectors.

[0099] In yet another embodiment, the electronic patient care system comprises a first module configured to receive and store information about a patient, the first module including data relating to first parameters of the patient measured by a device connected to the patient, and data relating to second parameters of the patient received from a first database containing information about the patient; and a second module configured to receive medication instructions from a user via a user interface associated with the second module, and further configured to transmit such medication instructions to the first module, the first module further configured to a) retrieve medication information from the second database, including data providing limitations on when such medication is generally administered; b) determine whether the medication instructions must be confirmed by the second module (in this particular embodiment) based on the medication information, the values ​​of the first parameters, and the values ​​of the second parameters; and c) transmit a predetermined 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 instructions.

[0100] Drug information may include drug interaction information, drug allergy information, blood pressure effect information, heart rate effect information, cardiac rhythm effect information, or respiratory effect information, and the first or second parameter may include data on the patient's currently administered drugs, known drug allergies, current blood pressure, current heart rate, current cardiac rhythm, current respiratory rate, or current tidal volume.

[0101] A predetermined message may include a warning regarding the potential effects of the prescribed drug, and such warning may include measured data regarding a first parameter, received data regarding a second parameter, or drug information obtained by the first module.

[0102] The first module may be configured to generate a signal indicating that a drug instruction or a modified drug instruction will be processed after a predetermined message has been transmitted and after it has received an acknowledgment signal from a second module, which has been triggered by an input signal from the user interface.

[0103] In another embodiment, the patient care device includes a first communication link and a second communication link, and the dock includes a first communication link and a second communication link. When the patient care device is within a predetermined range from the dock, the patient care device and the dock are paired using the first communication link, and after pairing, they remain in a state where they can communicate using the second communication link. Pairing performed using the first communication link may be pairing the patient care device and the dock with the second communication link. The first communication link may be short-range wireless communication, and the second communication link may be Bluetooth, Bluetooth Low Energy, Wi-Fi, or another communication link.

[0104] In another embodiment, the patient care device comprises a first communication link and a second communication link, and the monitoring client comprises a first communication link and a second communication link. When the patient care device is within range of the monitoring client, the patient care device and the monitoring client pair using the first communication link and, after pairing, remain communicating using the second communication link. Pairing that occurs using the first communication link can pair the patient care device and the monitoring client with respect to the second communication link. The first communication link may be short-range wireless communication, and the second communication link may be Bluetooth®, Bluetooth Low Energy, WiFi, or another communication link.

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

[0106] In yet another embodiment, the injection pump includes a mountable electronic component, which comprises at least one processor, a power regulator, and a control system.

[0107] In one embodiment, the communication module comprises at least one processor and one or more transceivers, batteries, and power supplies to provide communication capabilities and at least one of power to the patient care device.

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

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

[0110] In yet another embodiment, the method includes one or more of the following steps: establishing a communication link between a monitoring server and multiple patient care devices associated with multiple patients; communicating multiple patient care parameters from the multiple patient care devices to the monitoring server; de-identifying the patient care parameters; storing the patient care parameters in the monitoring server; treating multiple patients; and analyzing a subset of the multiple patient care parameters associated with multiple patients to determine the effectiveness of the treatment.

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

[0112] In yet another embodiment, a method having a hot-swappable patient care device, such as 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 one or more patient care parameters in the non-volatile memory of the patient care device; loading one or more patient care parameters into the active memory; and restarting the operation of the patient care device. In an additional embodiment, the method may include determining that the operation of the patient care device can be restarted.

[0113] In yet another embodiment, a method having a hot-swappable patient care device, such as an infusion pump, includes one or more of the following steps: calculating one or more operating parameters associated with the patient care device; storing one or more operating parameters in the non-volatile memory of the patient care device; loading one or more operating parameters into the operating memory; and restarting the operation of the patient care device. In an additional embodiment, the method may include determining that the operation of the patient care device can be restarted.

[0114] In yet another embodiment, the pairing method includes the steps of: positioning a hub having a monitoring client and / or user interface within the operating distance of a patient care device (e.g., an infusion pump); displaying identification information for the patient care device on the user interface; selecting the patient care device for pairing using the user interface; pairing the patient care device with the monitoring client and / or hub; and / or communicating patient care parameters to the monitoring client and / or hub. In yet another embodiment, and optionally, the method may also include the step of operably communicating additional patient care parameters through the patient care device to another patient care device, for example, to the monitoring client and / or hub.

[0115] In yet another embodiment, the method includes the steps of: docking a patient care device into a dock; identifying the patient care device; querying a server for an application to control the patient care device; downloading the application into the dock, hub, and / or monitoring client; running the application using the dock, hub, and / or monitoring client; and controlling the patient care device using the application.

[0116] In yet another embodiment, the method includes the step of arranging a patient care device to communicate operably with a hub, the hub being able to identify the patient care device, query a server for an application to control the patient care device, download the application into the hub, run the application, and control the patient care device using the application.

[0117] In yet another embodiment, the method includes the step of arranging a patient care device to communicate operably with a dock, the dock being able to identify the patient care device, query a server for an application to control the patient care device, download the application into the dock, run the application, and control the patient care device using the application.

[0118] In yet another embodiment, the method includes the step of arranging a patient care device to communicate operablely with a monitoring client, the monitoring client being able to identify the patient care device, query a server for an application to control the patient care device, download the application to the monitoring client, run the application, and control the patient care device using the application.

[0119] In yet another embodiment, the method may include the following steps: presenting a request on the user interface of a communication device; confirming the request; transmitting the request; receiving the request with a check value; and confirming that the check value conforms to the request before transmission.

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

[0121] In yet another embodiment, the hub operably communicates with at least one of the electronic medical record, DERS, CPOE, and / or the internet in order to control and / or monitor patient care devices.

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

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

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

[0125] In yet another embodiment, the electronic patient care system comprises a monitoring client and a dock configured to be coupled to a support column. An adapter may be coupled to the dock. The adapter may be equipped with at least one electronic coupler to enable patient care devices to communicate operationally with the monitoring client. The patient care devices may slide into the adapter.

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

[0127] For the embodiments described below, the base may be a medical device, dock, cradle, hub, pill dispenser, syringe pump, infusion pump, microinfusion pump, communication module, ECG monitor, blood pressure monitor, pulse oximeter, CO2 capnometer, communication relay, etc.

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

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

[0130] In another embodiment, the method, which is implemented by an operable set of processor-executable instructions, is performed when the processor is located on a base.

[0131] In another embodiment, a method implemented by an operable set of processor-executable instructions is performed such that the act of communicating data from a base to a monitoring client using a second communication link includes the step of the base transmitting the data to the monitoring client using the second communication link.

[0132] In another embodiment, a method implemented by an operable set of processor-executable instructions is performed such that the act of communicating data from a base to a monitoring client using a second communication link includes the step of the monitoring client receiving the data using the second communication link.

[0133] In another embodiment, a method implemented by an operable set of processor-executable instructions further includes the step of displaying data to a monitoring client in accordance with data communicated from a base.

[0134] In another embodiment, a method implemented by an operable set of processor-executable instructions further includes the step of initializing patient treatment using a monitoring client.

[0135] In another embodiment, a method implemented by an operable set of processor-executable instructions further includes the step of initializing patient treatment using a monitoring client, and also further includes the step of treating the patient using a base.

[0136] In another embodiment, a method implemented by an operable set of processor-executable instructions, further comprising the step of initializing patient treatment using a monitoring client, also further comprises the step of treating the patient using a hemodialysis system as a basis.

[0137] In another embodiment, a method implemented by an operable set of processor-executable instructions includes the step of a monitoring client sending an initiation treatment signal to the base.

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

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

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

[0141] In another embodiment, a method implemented by an operable set of processor-executable instructions further includes the step of communicating data between a monitoring client and a base, provided that the link quality value exceeds a predetermined threshold.

[0142] In another embodiment, a method implemented by an operable set of processor-executable instructions further includes the step of putting a monitoring client into a state without screen display when the link quality value falls below a first predetermined threshold.

[0143] In another embodiment, a method implemented by an operable set of processor-executable instructions further includes the step of putting a monitoring client into a no-screen display state when the link quality value falls below a first predetermined threshold, in which case the monitoring client displays a message on the user interface in response to the no-screen display state.

[0144] In another embodiment, a method implemented by an operable set of processor-executable instructions includes the step of putting the monitoring client into a state of no screen display when the link quality value falls below a first predetermined threshold, in which case a message instructs the user to move the monitoring client closer to the base.

[0145] In another embodiment, a method implemented by an operable set of processor-executable instructions, which includes the step of putting a monitoring client into a state with no screen display when the link quality value falls below a first predetermined threshold, further includes the step of measuring each link quality value at regular intervals and determining whether each link quality value exceeds the first predetermined threshold.

[0146] In another embodiment, a method implemented by an operable set of processor-executable instructions, which includes the step of putting a monitoring client into a no-screen display state when the link quality value falls below a first predetermined threshold, further includes the step of leaving the no-screen display state in place when the link quality value exceeds the first predetermined threshold.

[0147] In another embodiment, a method implemented by an operable set of processor-executable instructions, which includes the step of putting a monitoring client into a no-screen display state when the link quality value falls below a first predetermined threshold, further includes the step of leaving the no-screen display state in place when the link quality value exceeds a second predetermined threshold greater than the first predetermined threshold.

[0148] In another embodiment, a method implemented by an operable set of processor-executable instructions includes, if necessary, updating an interface program on a monitoring client via a first communication link, the act of communicating the version number of the interface program from the monitoring client to the base via the first communication link, determining whether the interface program on the monitoring client is the latest version, the base incorporating the latest version of the interface program from the server, and overwriting the interface program with the latest version of the interface program.

[0149] In another embodiment, a method implemented by an operable set of processor-executable instructions is performed when the act of establishing a second communication link between a monitoring client and a base using a first communication link includes the steps of determining whether the base is paired with another monitoring client, interrupting the pairing between the other monitoring client and the base if necessary, creating a configuration file using the base, communicating the configuration file from the base to the monitoring client using the first communication link, having the monitoring client read the configuration file received from the base, and pairing the base with the monitoring client for wireless communication to establish a second communication link between the monitoring client and the base according to the configuration file.

[0150] In another embodiment, a method implemented by an operable set of processor-executable instructions includes the steps of: putting the monitoring client into a no-screen state when the link quality value falls below a predetermined threshold; interrupting data communication between the base and the monitoring client; and displaying a message on the graphical user interface requesting the user to move the monitoring client closer to the base.

[0151] In another embodiment, a method implemented by an operable set of processor-executable instructions includes the steps of: putting the base into a no-screen display state when the link quality value falls below a predetermined threshold; interrupting data communication between the base and the monitoring client; and indicating that the base has entered a no-screen display state.

[0152] In another embodiment, a method implemented by an operable set of processor-executable instructions configured to be executed by a processor includes the steps of: communicating data between a monitoring client and a base as long as the link quality value is above a predetermined threshold; entering a no-screen display state if the link quality value falls below the predetermined threshold; remaining in the no-screen display 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 no-screen display state when the link quality value returns to above the predetermined threshold.

[0153] In another embodiment, a method implemented by an operable set of processor-executable instructions configured to be executed by a processor includes the steps of: communicating data between a monitoring client and a base as long as the link quality value exceeds a first predetermined threshold; entering a no-screen display state if the link quality value falls below the first predetermined threshold; remaining in a no-screen display state as long as the link quality value remains below a predetermined second threshold; determining whether the link quality value increases to exceed a second predetermined threshold; and exiting the no-screen display state if the link quality value exceeds the second predetermined threshold.

[0154] In one embodiment of the present disclosure, a system for communicating between a monitoring client and a base comprises a base having a communication component, the communication component being configured to: communicate data between the monitoring client and the base as long as the link quality value is above a predetermined threshold; enter a no-screen display state if the link quality value falls below a predetermined threshold; remain in a no-screen display state as long as the link quality value remains below a predetermined threshold; determine whether the link quality value returns to above a predetermined threshold; and exit the no-screen display state if the link quality value returns to above a predetermined threshold.

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

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

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

[0158] In one embodiment of this disclosure, the update component runs within a sandbox. In some embodiments, the sandbox may reside within at least one of a hub, a dock, and a cradle.

[0159] In one embodiment of the present disclosure, a system enabling electronic patient care comprises a monitoring client connected to a base through a physical connection, wherein at least one of the monitoring client and the base has a processor configured to: establish a first communication link between the monitoring client and the base through the physical connection; update an interface program on the monitoring client and the base through the first communication link; and establish a second communication link between the monitoring client and the base using the first communication link.

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

[0161] In one embodiment of the present disclosure, the base is a patient care device. In one embodiment of the present disclosure, the patient care device is selected from the group consisting of infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters, CO2 capnometers, intravenous bags, and infusion flowmeters.

[0162] In one embodiment of the present disclosure, the system further comprises a monitoring client configured to send an initiation treatment signal to the base. In one embodiment of the present disclosure, the communication link between the monitoring client and the base is wireless. In one embodiment of the present disclosure, the base is configured to monitor a link quality value of a second communication link. In one embodiment of the present disclosure, the system is configured to communicate data between the monitoring client and the base as long as the link quality value exceeds a predetermined threshold.

[0163] In one embodiment of the present disclosure, a monitoring client is configured to enter a no-screen display state when the link quality value falls below a first predetermined threshold. In one embodiment of the present disclosure, the monitoring client is configured to display a message on the user interface in response to the no-screen display state. In one embodiment of the present disclosure, the message instructs the user to move the monitoring client closer to the base. In one embodiment of the present disclosure, the base is configured to measure each link quality value at regular intervals and determine whether each link quality value exceeds a first predetermined threshold.

[0164] In one embodiment of the present disclosure, the base is configured to remain in a state of no screen display if the link quality value exceeds a first predetermined threshold. In one embodiment of the present disclosure, the base is configured to remain in a state of no screen display if the link quality value exceeds a second predetermined threshold which is greater than the first predetermined threshold.

[0165] In one embodiment of the present disclosure, at least one of a monitoring client and a base is configured to update an interface program through a first communication link, such that: the monitoring client is configured to transmit the version number of the interface program to the base through the first communication link; the monitoring client is further configured to determine whether the interface program on the monitoring client is the latest version; the base is configured to read the latest version of the interface program from the server; and the base is further configured to overwrite the interface program with the latest version of the interface program.

[0166] In one embodiment of the present disclosure, the system is configured to establish a second communication link between a monitoring client and a base using a first communication link, the system being at least one of the following: a processor being configured to determine whether the base is paired with another monitoring client; the processor being further configured to interrupt the pairing of the base with another monitoring client if necessary; the base being configured to create a configuration file; the first communication link being configured to transmit the configuration file from the base to the monitoring client; the monitoring client being configured to read the configuration file received from the base; and the base being paired with a monitoring client for wireless communication, with the base being paired with the monitoring client for wireless communication establishing a second communication link between the monitoring client and the base according to the configuration file.

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

[0168] The tablet may be configured to: (1) monitor the operation of the base; (2) control the operation of the base; (3) receive error conditions from the base; (4) monitor the operation of the base to determine if any error conditions exist; (5) monitor the operation of the base to determine if any unsafe conditions exist; (6) store errors or operation parameters and send them to the server; (7) store errors or operation parameters and send them to the base for storage within the base; (8) store errors or operation parameters and send them to the base for relay to the server; and / or (9) provide patient entertainment selected from a group consisting of video games, movies, pre-recorded songs and web browsing while the patient is receiving treatment. [Brief explanation of the drawing]

[0169] Other embodiments of these will become more apparent from the following detailed description of various embodiments of this disclosure with reference to the drawings.

[0170] [Figure 1] This is a block diagram of an electronic patient care system having two docks according to an embodiment of the present disclosure. [Figure 2]This flowchart illustrates a method for maintaining communication between the monitoring client and the patient care device shown in Figure 1, according to an embodiment of the present disclosure. [Figure 3] This is a block diagram of an electronic patient care system having two docks and communicating wirelessly between them, according to another embodiment of the present disclosure. [Figure 4] This flowchart illustrates a method for maintaining communication between the monitoring client and the patient care device shown in Figure 3, according to an embodiment of the present disclosure. [Figure 5] This is a block diagram of an electronic patient care system having a dock for docking together a monitoring client and a patient care device, according to yet another embodiment of the present disclosure. [Figure 6] This flowchart illustrates a method for maintaining communication between the monitoring client and the patient care device shown in Figure 5, according to an embodiment of the present disclosure. [Figure 7] A block diagram of an electronic patient care system having a monitoring client with an integrated dock for docking a patient care device thereto, according to yet another embodiment of the present disclosure. [Figure 8] This is a block diagram of an electronic patient care system having a hub according to yet another embodiment of the present disclosure. [Figure 9] This is a block diagram of an electronic patient care system having a stackable monitoring client and stackable patient care devices according to yet another embodiment of the present disclosure. [Figure 10] This is a flowchart illustrating a method for communicating patient care parameters of a patient care device to a monitoring server according to an embodiment of the present disclosure. [Figure 11] This is a flowchart illustrating a method for collecting patient care parameters for multiple patients in a monitoring server according to an embodiment of the present disclosure. [Figure 12] This is a flowchart illustrating a method for recovering a patient care device when its operation is interrupted, according to an embodiment of the present disclosure. [Figure 13]This is a flowchart illustrating a method for pairing a monitoring client with a patient care device according to an embodiment of the present disclosure. [Figure 14] This is a flowchart illustrating a method for monitoring the operation of a patient care device using a wearable system monitor paired with the patient care device, according to an embodiment of the present disclosure. [Figure 15] This is a flowchart illustrating a method for displaying a user interface using a user interface template according to an embodiment of the present disclosure. [Figure 16] This is a flowchart illustrating a method for downloading an application to control a patient care device according to an embodiment of the present disclosure. [Figure 17] This is a flowchart illustrating a method for ensuring data integrity when communicating data for a patient care device according to an embodiment of the present disclosure. [Figure 18] This is a block diagram of an electronic patient care system according to yet another embodiment of the present disclosure. [Figure 19] This is a block diagram of an electronic patient care system according to another embodiment of the present disclosure. [Figure 20] This is a block diagram of the dock of the electronic patient care system shown in Figure 19, according to an embodiment of the present disclosure.

[0171] [Figure 21] This figure shows an electronic patient care system according to an embodiment of the present disclosure, which has a tablet docked in a dock having a cable electrically coupled to a patient care device. [Figure 22] This figure shows an electronic patient care system having a tablet docked in a dock for wireless communication with a patient care device, according to an embodiment of the present disclosure. [Figure 23] This figure shows an electronic patient care system according to an embodiment of the present disclosure, having a modular infusion pump docked in a dock with a monitoring client equipped with a retractable user interface. [Figure 24]This is a side view of the electronic patient care system shown in Figure 23, according to an embodiment of the present disclosure. [Figure 25] This figure shows an electronic patient care system according to another embodiment of the present disclosure, having staggered modular infusion pumps docked in a dock having a monitoring client with a retractable user interface. [Figure 26] This figure shows an electronic patient care system according to yet another embodiment of the present disclosure, having a modular infusion pump that docks in a dock along a common horizontal plane, including a monitoring client with a retractable user interface. [Figure 27] Figure 26 is a side view of an electronic patient care system according to another embodiment of the present disclosure. [Figure 28] This figure shows an electronic patient care system according to yet another embodiment of the present disclosure, which includes a scanner and a dock-coupled hub, as well as a modular infusion pump that docks in a dock along a common horizontal plane, and a monitoring client with a retractable user interface. [Figure 29] Figure 28 is a side view of an electronic patient care system according to another embodiment of the present disclosure. [Figure 30-32] These are some figures illustrating a clutch system for mounting an electronic patient care system on a support column according to embodiments of the present disclosure. [Figure 33] This figure shows an injection pump and a dock coupled to a support column according to an embodiment of the present disclosure. [Figure 34] This figure shows another injection pump coupled to an open connector, and an injection pump equipped with an open connector, according to an embodiment of the present disclosure. [Figure 35] This figure shows the injection pump of Figure 33, in which two additional injection pumps are each connected to an open connector, according to an embodiment of the present disclosure. [Figure 36] Figures 33-35 show a top view of one of the injection pumps and a hub according to an embodiment of the present disclosure. [Figure 37]This figure shows a rectangular hub having several connectors according to an embodiment of the present disclosure. [Figure 38] This figure shows an electronic patient care system having a hub coupled to a support column, according to another embodiment of the present disclosure. [Figure 39] This figure shows an electronic patient care system according to another embodiment of the present disclosure, having a hub coupled to a support column and a portable dock, with a quick-release handle for removing the portable dock from the hub. [Figure 40] This figure shows an electronic patient care system according to another embodiment of the present disclosure, having a hub coupled to a support column and a dock coupled to the hub.

[0172] [Figure 41] This figure shows an electronic patient care system having a hub coupled to a support column, according to another embodiment of the present disclosure. [Figure 42] This figure shows an electronic patient care system according to another embodiment of the present disclosure, having a monitoring client coupled to a hub having a notch for receiving patient care devices. [Figure 43] This is an enlarged view of a T-shaped connector connecting to a hub notch, as shown in Figure 42, according to another embodiment of the present disclosure. [Figure 44] This figure shows an electronic patient care system having a stackable patient care device and a stackable container for storing infusion bags, according to another embodiment of the present disclosure. [Figure 45] This figure shows an electronic patient care system having stackable patient care devices that can be stacked next to another stack of patient care devices, according to yet another embodiment of the present disclosure. [Figure 46] This figure shows an electronic patient care system having a stackable patient care device equipped with a syringe-pump patient care device having a single syringe, according to another embodiment of the present disclosure. [Figure 47]This figure shows an electronic patient care system having a stackable patient care device equipped with a syringe-pump patient care device having two syringes, according to another embodiment of the present disclosure. [Figure 48] This figure shows an electronic patient care system having stackable patient care devices, each having a display, according to another embodiment of the present disclosure. [Figure 49] This is an enlarged view of the handle of the electronic patient care device shown in Figure 48, according to another embodiment of the present disclosure. [Figure 50] Figure 48 is an enlarged view of the infusion line port of the electronic patient care system according to another embodiment of the present disclosure, showing the infusion line arranged through it. [Figure 51] This figure shows another embodiment of an electronic patient care system, illustrating the removal of stackable patient care devices according to another embodiment of the present disclosure. [Figure 52] This figure shows an electronic patient care system prepared for transport according to another embodiment of the present disclosure. [Figure 53] This figure shows an electronic patient care system having stackable patient care devices according to another embodiment of the present disclosure. [Figure 54] This figure shows an electronic patient care system having stackable patient care devices that can be stacked from bottom to top, according to another embodiment of the present disclosure. [Figure 55] This figure shows an electronic patient care system having stackable patient care devices that are coupled to a support column and stackable from top to bottom, according to another embodiment of the present disclosure. [Figure 56] This is a perspective view of a clutch system for gripping a support column by friction, having a release handle, according to another embodiment of the present disclosure. [Figure 57] Figure 56 is a rear view of the clutch system, showing a transparent back, according to another embodiment of the present disclosure. [Figure 58] Figure 56 shows a top cross-sectional view of the clutch system according to another embodiment of the present disclosure. [Figure 59]This is a block diagram of a system for controlling an injection pump according to an embodiment of the present disclosure. [Figure 60] This is a block diagram of an electronic patient care system having a hub for communicating with several electronic patient care devices according to an embodiment of the present disclosure.

[0173] [Figure 61] This is a block diagram of an electronic patient care system having a dock that can be connected to a patient care device via USB connection, according to an embodiment of the present disclosure. [Figure 62] This is a process diagram illustrating several stages of electronic patient care according to embodiments of the present disclosure. [Figure 63-66] This figure shows several configurations of an electronic patient care system according to embodiments of the present disclosure. [Figure 67] This is a timing diagram of an electronic patient care treatment using an infusion pump according to an embodiment of the present disclosure. [Figures 68A-68B] This is a flowchart illustrating the method for illustrating the timing diagram in Figure 67 according to an embodiment of the present disclosure. [Figure 69-70] This figure shows an additional configuration of the electronic patient care system according to an embodiment of the present disclosure. [Figure 71] This is a timing diagram of an electronic patient care treatment using an infusion pump according to an embodiment of the present disclosure. [Figures 72A-72B] This is a flowchart illustrating the method for illustrating the timing diagram in Figure 71 according to an embodiment of the present disclosure. [Figure 73] This is another timing diagram of an electronic patient care treatment using an infusion pump according to an embodiment of the present disclosure. [Figure 74] This is a flowchart illustrating the method for illustrating the timing diagram in Figure 73 according to an embodiment of the present disclosure. [Figure 75] This is yet another timing diagram of an electronic patient care treatment using an infusion pump, according to another embodiment of the present disclosure. [Figure 76] This is a flowchart illustrating the method for illustrating the timing diagram in Figure 75 according to an embodiment of the present disclosure. [Figures 77-78] This figure shows several configurations of an electronic patient care system according to embodiments of the present disclosure. [Figure 79] This is another timing diagram of an electronic patient care treatment using an infusion pump, according to another embodiment of the present disclosure. [Figures 80A-80B] This is a flowchart illustrating the method for illustrating the timing diagram in Figure 79 according to an embodiment of the present disclosure.

[0174] [Figure 81] This is another timing diagram of an electronic patient care treatment using an infusion pump, according to another embodiment of the present disclosure. [Figures 82A-82B] This is a flowchart illustrating the method for illustrating the timing diagram in Figure 81 according to an embodiment of the present disclosure. [Figure 83-89] This figure shows some additional embodiments of an electronic patient care system according to some embodiments of the present disclosure. [Figure 90] This is a block diagram of the electronic circuit of an embodiment of a hub according to the embodiments of the present disclosure. [Figure 91] This is a block diagram of an electronic circuit for interface connection with an injection pump according to an embodiment of the present disclosure. [Figure 92] This figure shows another embodiment of an electronic patient care system having patient care devices docked in a dock and arranged vertically, according to embodiments of the present disclosure. [Figure 93] This is a block diagram of the electronic circuit of an embodiment of a hub according to the embodiments of the present disclosure. [Figure 94] This is a block diagram of the electronic circuit of a communication module according to an embodiment of the present disclosure. [Figures 95-98] This figure shows some embodiments of an electronic patient care system having an infusion pump coupled to a communication module, according to some embodiments of the present disclosure. [Figure 99-101] These are some block diagrams of the electronic circuits of a dock according to some embodiments of the present disclosure.

[0175] [Figure 102] This is a block diagram of a battery pack according to an embodiment of the present disclosure. [Figure 103-104] This figure shows an additional embodiment of the electronic circuit of the dock according to an additional embodiment of the present disclosure. [Figure 105-116] This figure shows some embodiments of a mountable pump attached to a monitoring client, according to additional embodiments of the present disclosure. [Figure 117] This figure shows a backplane for use in an injection pump according to an embodiment of the present disclosure. [Figure 118] This is a cross-sectional view of the backplane panel shown in Figure 117 according to an embodiment of the present disclosure. [Figure 119-120] This figure shows some embodiments of a mountable pump attached to a monitoring client, according to additional embodiments of the present disclosure.

[0176] [Figure 121] This figure shows a communication module according to an embodiment of the present disclosure. [Figure 122] This figure shows a communication module attached to a patient monitoring device according to an embodiment of the present disclosure. [Figure 123] This is a diagram of the electronic circuit of the communication module shown in Figure 121, according to an embodiment of the present disclosure. [Figure 124] This is a diagram of an electronic circuit that converts short-range wireless communication to UHF according to an embodiment of the present disclosure. [Figure 125-127] This figure shows several antennas according to additional embodiments of the present disclosure. [Figure 128] This figure shows a patient wristband with an RFID tag according to an embodiment of the present disclosure. [Figure 129] This figure shows a split-ring resonant circuit used on the wrist band in Figure 128, according to an embodiment of the present disclosure. [Figure 130] This figure shows a near-field antenna according to an embodiment of the present disclosure. [Figure 131]This figure shows the equivalent circuit of the split ring resonant circuit of Figure 130 according to an embodiment of the present disclosure. [Figure 132] This figure shows a 5R checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. [Figure 133] This figure shows a blockage checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. [Figure 134] This figure shows a display of a monitoring client that communicates operably with several injection pumps according to an embodiment of the present disclosure. [Figure 135] This figure shows a display on a healthcare provider's portable monitoring client, illustrating a list of patients whose patient information the provider can access, according to an embodiment of the present disclosure. [Figure 136] This figure shows a display on a healthcare provider's portable monitoring client showing a device associated with a specific patient, with one-touch access to current data from the device and some of the patient's medical information, according to an embodiment of the present disclosure. [Figure 137] This figure shows a display on a healthcare provider's portable monitoring client indicating a data input area for a drug prescription, for use with an intravenous infusion pump, according to an embodiment of the present disclosure. [Figure 138] This figure shows a display on a healthcare provider's portable monitoring client, as created by the monitoring client, indicating the risk factors associated with the prescribed medication and the suggested course of action, according to an embodiment of the disclosure. [Figure 139] This figure shows a display on a healthcare provider's portable monitoring client showing a drug prescription ready to be presented by the prescribing provider, according to an embodiment of the present disclosure. [Figure 140] This figure shows a display on a healthcare provider's portable monitoring client illustrating how a monitoring system according to an embodiment of the present disclosure can display to a prescription provider confirmation that a prescription has been delivered to a pharmacist.

[0177] [Figure 141] This is a perspective view of a microinfusion pump coupled to an adapter according to an embodiment of the present disclosure. [Figure 142] This is a perspective view of a wireless hub device according to an embodiment of the present disclosure, which wirelessly relays data from a patient care device to a monitoring client, another hub, or dock. [Figure 143] This is a front perspective view of an electronic patient care system having modular patient care devices coupled to a monitoring client via an adapter and a dock, according to an embodiment of the present disclosure. [Figure 144] Figure 143 is a side perspective view of the electronic patient care system according to an embodiment of the present disclosure. [Figure 145] Figure 143 is an enlarged perspective view of one interface of the patient care device according to an embodiment of the present disclosure. [Figure 146] Figure 143 is a top view of the electronic patient care system according to an embodiment of the present disclosure. [Figure 147] This figure shows a system for an electronic patient care system according to an embodiment of the present disclosure. [Figure 148] This is a block diagram of an electronic patient care system according to an embodiment of the present disclosure. [Figure 149] This is a block diagram of the bedside portion of the electronic patient care system according to an embodiment of the present disclosure, as shown in Figure 147 and / or Figure 148. [Figure 150] Block diagrams of the dock / hub according to embodiments of the present disclosure are shown in Figures 147, 148, and / or 149. [Figure 151] This is a block diagram showing the injection pump circuit of Figures 148 and / or 149 according to an embodiment of the present disclosure. [Figure 152] This is a block diagram showing a sensor coupled to the mechanism of an injection pump according to an embodiment of the present disclosure.

[0178] [Figures 153A-153B]This flowchart illustrates a method of communication between a tablet and a base according to an embodiment of the disclosed invention. [Figure 154] This flowchart illustrates a method for updating an interface program according to an embodiment of the disclosed invention. [Figure 155] This flowchart illustrates a method for establishing a second communication link between a tablet and a base according to an embodiment of the disclosed invention. [Figure 156] This flowchart illustrates a method for communicating data between a tablet and a base, as long as the link quality value of the second communication link exceeds a threshold, according to an embodiment of the disclosed invention. [Figure 157] This flowchart illustrates an example of a method, according to an embodiment of the disclosed invention, for entering a state where there is no screen display when the link quality value falls below a threshold. [Modes for carrying out the invention]

[0179] A technology for facilitating patient care is disclosed. This technology can be implemented, for example, in a system having one or more patient care devices communicably coupled to a monitoring client, according to one exemplary embodiment. The patient care devices can have any number of diverse functions and / or can be manufactured by different manufacturers. In one such case, the communication interface between the client monitoring station and the various diverse patient care devices, along with discovery and protocol conversion, also enables various other functions, such as power provisioning, compliance with various standards and user interfaces, to name a few. The patient care devices may be infusion pumps, microinfusion pumps, insulin pumps, syringe pumps, pill dispensers, dialyzers, ventilators, ultrasound diagnostic devices, ECG monitors, blood pressure monitors, pulse oximeters, CO2 capnometers, infusion counters, infusion flow meters, optical Doppler devices, heart rate monitors, intravenous bags, hemodialyzers, peritoneal dialyzers, intestinal dialyzers, patient thermometers and / or other bedside patient care devices.

[0180] U.S. Patent Application No. 11 / 704,899, filed on February 9, 2007, entitled "Fluid Delivery System and Method," subsequently published on October 4, 2007, as U.S. Patent Publication No. 2007-0228071A1 (Agent Reference Number: E70); U.S. Patent Application No. 11 / 704,896, filed on February 9, 2007, entitled "Pump Fluid Delivery System and Method Using a Force-Applying Assembly," subsequently published on September 20, 2007, as U.S. Patent Publication No. 2007-0219496 (Agent Reference Number: E71); 2007 U.S. Patent Application No. 11 / 704,886, filed on February 9, titled "Patch-Size Fluid Delivery System and Method," subsequently published on September 20, 2007, U.S. Patent Publication No. 2007-0219481 (Agent Reference Number: E72); U.S. Patent Application No. 11 / 704,897, filed on February 7, 2007, titled "Adhesives and Peripheral Systems and Methods for Medical Devices," subsequently published on September 20, 2007, U.S. Patent Publication No. 2007-0219597 (Agent Reference Number: E73); December 31, 2008 U.S. Patent Application No. 12 / 347,985, filed on December 3, 2009, titled "Injection Pump Assembly," subsequently published as U.S. Patent Application Publication No. 2009-0299277 (Agent Reference Number: G75) on December 31, 2008, titled "Wearable Pump Assembly," subsequently published as U.S. Patent Application Publication No. 2009-0281497 (Agent Reference Number: G76) on November 12, 2009, and "Injection Pump Assembly" filed on December 31, 2008. U.S. Patent Application No. 12 / 347,981, with the title "Pump Assembly with Switch," subsequently published on November 5, 2009, U.S. Patent Application Publication No. 2009-0275896 (Agent Reference Number: G77), filed on December 31, 2008, with the title "Pump Assembly with Switch," subsequently published on December 3, 2009, U.S. Patent Application Publication No. 2009-0299289 (Agent Reference Number: G79), filed on October 10, 2008, with the title "Injection Pump Assembly,"This is U.S. Patent Application Publication No. 882, subsequently published on April 15, 2010, U.S. Patent Application No. 2010-0094222 (Agent Reference Number: F51), filed on October 10, 2008, titled "System and Method for Administering Injectable Fluids," U.S. Patent Application No. 12 / 249,636, subsequently published on April 15, 2010, U.S. Patent Application Publication No. 2010-0094261 (Agent Reference Number: F52), filed on October 10, 2008, titled "Occlusion Detection System and Method," U.S. Patent Application No. 12 / 249,621, subsequently published on April 15, 2010, U.S. Patent Application Publication No. 2010-0090843 (Agent Reference Number: F53), filed on October 10, 2008, titled "Multilingual / Multiprocessor Injection Pump" U.S. Patent Application No. 12 / 249,600, titled "Assembly," subsequently published on April 15, 2010, U.S. Patent Publication No. 2010-0094221 (Agent Reference Number: F54), issued on November 29, 2011, titled "Injection Pump Assembly with Backup Power Supply" (Agent Reference Number: F55), U.S. Patent No. 8,066,672 (Agent Reference Number: F55), issued on September 13, 2011, titled "Pump Assembly with Removable Cover Assembly" (Agent Reference Number: F56), and U.S. Patent No. 7,306,578 (Agent Reference Number: C54), issued on December 11, 2007, titled "Load Mechanism for Injection Pump," are all incorporated herein by reference in their entirety. These technologies can be used to enable seamless communication and fail-safe operation. Numerous other features, functions, and applications will be obvious in light of this disclosure.

[0181] General Overview As mentioned above, the process of providing comprehensive care to patients, such as prescribing and delivering treatment, is associated with several significant issues. For example, there is a high possibility that important information may be miscommunicated, treatment decisions may be made without immediate access to complete information, and / or that prescriptions may be delayed due to unnecessarily redundant and inefficient procedures.

[0182] More specifically, medication errors can cause hundreds of deaths and may affect thousands, or even millions, of people each year in the United States alone. Hospitals under financial pressure may experience a greater number of medication error incidents. Among the most dangerous medications leading to errors are insulin, narcotics, heparin, and chemotherapy. Causes of medication errors include administering the wrong medication, administering the wrong concentration of medication, delivering medication at the wrong rate, or delivering medication via the wrong route (medications can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, eye, or ear, intrathecally, intraperitoneally, or even intrabladder). Even with proper instructions and labeling, medications can still be administered improperly due to illegible handwriting, miscommunication of medication prescriptions, and mispronunciation of medications with similar names. To reduce medication error incidents, there is a growing trend to use electronic medical records (EMRs) and barcode systems for medications. EMR systems can hastily advance computer-provided information entry (CPOE) and flag prescriptions that are not appropriate for the patient's diagnosis, allergies, weight, and / or age. However, these systems have not yet been widely adopted, and their implementation can result in significant delays and inefficiencies in ordering, preparing, and administering medications.

[0183] In addition, drug infusion devices, such as infusion pumps, are associated with a significant number (e.g., up to one-third) of all drug administration errors that can lead to considerable damage. This could include the wrong drug being administered, incorrect parameters (e.g., drug concentration or infusion rate) being entered, or existing infusion parameters being improperly modified. Nearly half of deaths related to infusion pumps are due to user error, and many of these errors may stem from errors in programming the infusion pump.

[0184] An effective monitoring system can help minimize any of the many adverse events that may result from the treatment by monitoring and eliminating inconsistencies at every stage of the drug prescription and administration process. Conceptually, the drug therapy process can be divided into three stages: the prescription stage, the drug preparation stage, and the drug administration stage. Errors can occur when a drug prescription is written or entered, when the drug is read out for use or mixed into a solution, or when the drug is administered to the patient.

[0185] Accordingly, embodiments of the present disclosure disclose an electronic patient care system comprising a monitoring client configured to communicate at least one patient care parameter, a patient care device configured to communicate at least one patient care parameter, and a communication interface configured to facilitate communication between the monitoring client and at least one patient care device by detecting the presence of at least one patient care device and translating the 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 modules described below. The communication interface can further be configured to detect the presence of other additional patient care devices that are different from each other (e.g., different manufacturers, functions, and / or communication protocols, etc.) and translate the communication signals from these devices into a communication protocol associated with the monitoring client or hub. Thus, the communication interface makes it possible to effectively use a monitoring client, such as a tablet computer, as a common general user interface that a healthcare provider can use when providing treatment to a patient associated with the monitoring client. One or more databases accessible by the monitoring client provide centralized storage of patient information (in any format and database structure desired by the healthcare facility or database maintenance provider) and allow for the download of information that can be used by healthcare providers when treating patients associated with the monitoring client. The communication interface can be implemented in several ways using wired and / or wireless technologies, enabling seamless communication and fail-safe operation of multiple patient care devices. Several patient care devices, hubs, docks, and / or monitoring clients can communicate simultaneously over two or more communication links and / or over two frequency channels (in some embodiments, data may be redundant).In some embodiments, the communication module enables the patient care device to be used portable by providing a battery and sufficient circuitry for mobile operation, such as for a patient care device, such as an infusion pump. In addition, or alternatively, a patient wristband can power the patient care device by providing a battery that can be plugged into the communication module (or, in some embodiments, plugged directly into the patient care device). The communication module can be charged wirelessly.

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

[0187] System Architecture As shown in Figure 1, the electronic patient care system 100 comprises one or more monitoring clients 1, 4, each assigned to an individual patient 2 and capable of being physically close to the patient 2, and a remote monitoring server 3 that uploads information from several different monitoring clients 1, 4 and downloads information and instructions to the monitoring clients 1, 4 from various sources. When in the patient's room, the healthcare provider can interact directly with the monitoring client 1 to obtain information about patient 2 or enter instructions regarding patient 2. Multiple monitoring clients 1 can interact with one monitoring server 3. The monitoring server 3 may be equipped with middleware (e.g., middleware on the monitoring server 3 in Figure 1). In addition, or alternatively, providers in remote locations (e.g., a doctor's office, a nurse's station 5, a hospital pharmacy 6) can interact with individual monitoring clients 1 through a communication link with the monitoring server 3 or directly through a hospital local area network having each monitoring client 1, 4 as a node.

[0188] A remote communicator 11, another monitoring client 4, a nurse's station 5, or a doctor's office may enter a prescription sent to update a patient's personal EHR 19 or to a pharmacy 6 for dispensing. The prescription may be for pills, for fluid infusion or for other treatments. The prescription may be for infusion using an infusion pump 7, a syringe pump 126 or a microinfusion pump 130, or for dispensing pills using a pill dispenser 128.

[0189] Pharmacy 6 has one or more computers connected to a network, for example, the Internet, which can receive prescriptions and place them in a queue on the one or more computers. The pharmacy can use the prescription to: (1) compound the drugs (for example, using an automated compounding device connected to the one or more computers that can compound fluids or produce pills, or manually by a pharmacist monitoring the queue on the one or more computers); (2) pre-fill the fluid reservoir of the syringe pump 126; (3) program the syringe pump 126 (for example, a treatment plan is programmed into the syringe pump 126); (4) pre-fill the microinfusion pump 130; (5) program the microinfusion pump 130; (6) pre-fill the intravenous bag 170; (7) program the infusion pump 7; (8) pre-fill the pill dispenser 128; or (9) program the pill dispenser 128 in the pharmacy according to the prescription. The automated compounding device can automatically fill one or more of the syringe pump 126, intravenous bag 170, or microinfusion pump 130 with fluid, and / or automatically fill a pill dispenser 128 with pills. The automated compounding device can generate barcodes, RFID tags, and / or data. Information in the barcodes, RFID tags, and / or data may include treatment plans, prescriptions, and / or patient information.

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

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

[0192] For example, the scanners of the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 can scan the barcode of another patient care device to obtain the serial number of the patient care device, and the barcode of the patient to determine the patient's serial number, and can query electronic medical record data to determine whether the serial number of the patient care device corresponds to the patient's serial number stored in the electronic medical record (which may have been updated, for example, by the pharmacy 22 or the pharmacy's automated compounding device).

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

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

[0195] Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 100 is operating properly or within a given boundary, and / or can send data back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11 in order to display the data on the displays of monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate to one or more monitoring clients 1, other monitoring clients 4, and / or remote communicators 11 (if applicable) the upstream pressure, changes in upstream pressure, downstream pressure relative to patient 2, changes in downstream pressure relative to patient 2, presence or absence of air in the infusion line, actual bolus volume 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 may optionally return data to monitoring client 1, other monitoring clients 4, and / or remote communicators 11, such as the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criterion was exceeded.

[0196] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 can be analyzed for any given condition to issue alarms and / or warnings. For example, one or more monitoring clients 1, 4, and 11 can use an increase in downstream pressure in the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 as a manifestation of one of the following: excessive coagulation, osmosis, blockage, or kinking of the tubing to the patient, or an obstruction occurring downstream by a substance such as contamination found in the intravenous bag 170. In response to a rapid increase in downstream pressure, one or more monitoring clients 1, 4, and 11 can issue a visual or audible alarm or warning to the user. These alarms and / or alerts can also prompt nurses to take other appropriate actions, such as suggesting a needle change in response to an obstruction (e.g., caused by coagulation) if the downstream pressure to the patient rises above a predetermined threshold, or suggesting checking for kinks in the line if the downstream pressure to the patient rises above a predetermined threshold.

[0197] In addition, or alternatively, a sudden drop in downstream pressure to patient 2 is an indication that the tube has detached from the needle and / or the needle is now detached from the patient, and accordingly, one or more monitoring clients 1, 4, and 11 may issue a visual or audible alarm or warning to the user to reattach the tube to the needle or insert a new needle for continued infusion. The alarm may also indicate, for example, that the patient may be bleeding when the tube detaches from the needle, and that immediate action is needed because the patient is bleeding due to an unattached needle coupler.

[0198] In some embodiments, in addition to or alternative to this, the upstream pressure to one or more infusion pumps 7 can be monitored for any upstream occlusion. For example, contamination in the intravenous bag 170 could block the tubing upstream of the infusion pump 7. Each time the infusion pump 7 attempts to pump fluid from the intravenous bag 170, the upstream pressure relative to the infusion pump 7 may drop lower than what would occur if there were no obstruction upstream. Therefore, one or more of the monitoring clients 1, 4, and 11 may issue an alarm or warning if the upstream pressure drops below a predetermined threshold, and may, for example, suggest or request that the caregiver reduce the obstruction by replacing the tubing or intravenous bag 170.

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

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

[0201] In this exemplary embodiment, the cable 110 is coupled to both docks 102, 104 to provide a communication link between them. The cable 110 can be permanently attached to one or both of the docks 102, 104, or is attachable. In addition, or alternatively, the cable 110 may have one or more connectors (not explicitly shown) for plugging the cable into one or both of the docks 102, 104.

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

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

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

[0205] Further referring to the exemplary embodiment shown in Figure 1, the device dock 104 may be equipped with various accessories, each optional, such as a mountable display 134, a camera 136, and a microphone 138. Similarly, the monitoring client dock 102 may be equipped with various accessories, each optional, such as a camera 140 and a microphone 142. The monitoring client 1 may be equipped with various accessories, each optional, such as a camera 144 and a microphone 146. Cameras 136, 140, and 144 can be used by facial recognition software, for example, to authenticate or identify the presence of a provider (e.g., a nurse, nurse practitioner, doctor, etc.) and / or a patient. In addition, or alternatively, microphones 138, 142, and 146 can be used by speech recognition software, for example, to authenticate or identify the presence of a provider and / or a patient. As can be seen in light of this disclosure, cameras 136, 140, 144 and microphones 138, 142, 146 can also be used, for example, to enable a patient to communicate with a remote care provider before treatment begins, and / or to verify the patient's identification information (e.g., using voice and / or facial recognition technology, retinal scans, etc.) to ensure that the correct patient receives the correct treatment.

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

[0207] In some embodiments, the monitoring client 1 can determine whether cable 110 is available as a communication link by electrically determining whether one or more electrical contacts of one or more connectors are electrically engaged with the monitoring client dock 102, for example, for docking to the monitoring client dock 102 and for providing telecommunications between the monitoring client dock 102 and the monitoring client 1, by measuring the voltage or impedance between two electrical contacts of the monitoring client 1's connectors. Alternatively, if the monitoring client 1 determines that it is not electrically coupled to cable 110, it can determine that cable 110 is not available. In addition, or alternatively, in some embodiments, a magnetic field in the dock 102 engages with a Hall effect sensor in the monitoring client 1, which the monitoring client 1 then uses to determine whether it is docked, so that the monitoring client 1 infers that cable 110 is not available as a communication link if the monitoring client 1 is not docked. In addition, or alternatively, circuitry in the monitoring client dock 102 can send a signal to the monitoring client 1 if the cable is not available as a communication link. In some embodiments, the monitoring client 1 can periodically "ping" the device dock 104 via cable 110 to check network connectivity. If the monitoring client does not receive a response from the device dock 104 within a predetermined time, the monitoring client 1 infers that cable 110 is not available as a communication link.

[0208] If monitoring client 1 determines that cable 110 is not available as a communication link, monitoring client 1 may issue an alarm or alert using a speaker and / or vibration motor, transmit the alarm or alert to remote communicator 11, issue an alarm or alert to remote communicator using a speaker and / or vibration motor, and / or monitoring client 1 may attempt to communicate with patient care devices via other communication links. As used herein, the term “alert” is intended to include, for example, “soft” alerts that do not draw attention to a person until the cause of the alert remains after a predetermined period of time has elapsed.

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

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

[0211] The monitoring client 1 can run a Linux®-based operating system, an Android-based operating system, a BlackBerry-based operating system, a tablet-based operating system, iOS, iPad®OS, iPhone®OS, etc. Assigning a specific monitoring client 1 to a specific patient 2 can be done using one of several methods, including (but not limited to) a unique patient identifier encoded on a barcode 114 or RFID tag 116 embedded in a wristband 118. The device dock 104 includes a scanner 120 to determine the unique patient identifier of the barcode 114 or RFID tag 116. The scanner 120 may be a laser barcode scanner, a CCD-based barcode scanner, a near-field communicator or caller, an RFID reader, etc. In other embodiments, the unique patient identifier may be based on the patient's biometric data. In one such exemplary case, biometric capabilities (e.g., facial and / or voice recognition, retinal scanning, blood type monitoring, fingerprint scanning, etc.) can be embedded in or otherwise associated with the monitoring client 1. The device dock 104 can facilitate the treatment of patient 2 by communicating a unique patient identifier to the monitoring client dock 102, monitoring client 1, monitoring server 3, remote communicator 11, other monitoring clients 4, another server, or electronic computing device.

[0212] The monitoring client 1 comprises one or more components such as a microprocessor, microcontroller, logic device, digital circuit, and analog circuit, and can communicate (e.g., transmit or receive) information related to the care, condition, illness, or treatment of patient 2. For example, the monitoring client 1 can transmit or receive patient care parameters such as patient condition parameters and / or patient treatment parameters. Some exemplary patient condition parameters are measurements such as blood pressure, body temperature, heart rate, pulse oximeter readings, CO2 levels, blood oxygen levels, patient alertness, patient consciousness, and patient response. Some exemplary patient treatment parameters include drugs to be administered, drug or fluid flow rates, drug administration schedules, or other bedside treatment parameters.

[0213] In some embodiments, for example, the monitoring client 1 can be physically associated with the infusion pump 7, permanently attached, installable, detachable, or installably detachable. This can be achieved by a docking interface between two devices, for example, a monitoring client dock 102 and a device dock 104. In one such embodiment, the monitoring client 1 communicates with the pump 7 (or other patient care device) in several ways, including, for example, through electrical contact with the docks 102, 104, by electrical connectors, or wirelessly by transceivers on each device using their respective antennas 112, 122A. In addition to or alternatively, the infusion pump may have pre-programmed treatment data indicating specific treatments for a particular patient, which are uploaded to the monitoring client 1 when the infusion pump 7 is operationally communicating with the monitoring client 1.

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

[0215] In embodiments of the present disclosure, the facility service 8 and / or the drug adverse 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 soft alarms and / or a second set of predetermined criteria for triggering hard alarms. Soft alarms can be deactivated (e.g., stopped) by a caregiver using the user interface of the infusion pump 7 and / or monitoring client 1 (and may also be audible and / or vibrating alarms only), while hard alarms interrupt treatment until the cause is removed.

[0216] In further embodiments of the present disclosure, the DERS system may include a first set of predetermined criteria defining soft limits and / or a second set of predetermined criteria defining hard limits. The hard and soft limits define treatment limits, such as drug dose limits, based on physique, weight, age, other patient parameters, or other criteria. The soft limits allow treatment to be initiated by a caregiver using the user interface of the infusion pump 7 and / or monitoring client 1, even if the treatment falls outside the predetermined criteria of the first set, while the hard limits prevent treatment from initiating until the settings are changed to meet the predetermined criteria of the second set defining hard limits.

[0217] As can be seen further in the exemplary embodiment of Figure 1, the system 100 also comprises communication modules 124A to 124K, each having its own antenna 122A to 122K. In some embodiments, each of the communication modules 124A to 124K is optional and / or each device may have integrated communication capabilities. Each of the communication modules 124A to 124K is provided with a connector for coupling to its respective device. In other embodiments, each of the communication modules 124A to 124K is permanently integrated with the device shown mounted in Figure 1.

[0218] Each of the communication modules 124A to 124K optionally includes one or more transceivers for communicating with each other, with the device dock 104, the monitoring client dock 102, the monitoring client 1, the remote communicator 11, the monitoring server 3, with the hub 802 (see Figure 8) via a local area network and / or a wide area network (e.g., the Internet), and / or with any other device that otherwise has sufficient wireless communication capabilities. In some specific embodiments, the communication modules 124A to 124K can operate as, for example, a wireless mesh network using, for example, IEEE 802.14.4, Zigbee®, XBee, Wibree, IEEE 802.11, etc. In a more general sense, communication between modules 124A-124K and other components of system 100 (e.g., docks 102 and 104, monitoring clients 1, 4, 11, etc.) can be carried out using any wireless communication protocol that enables device discovery, handshake, and / or interdevice communication as described herein, whether in a static, dynamic, or ad-hoc topology (e.g., to accommodate the mobility of various medical devices associated with monitoring clients 1, 4, 11 and / or dock 104).

[0219] In other embodiments, each patient care device may not have modules, or it may have three or more modules (e.g., communication modules). For example, each module may have a specific function, such as WiFi, and a user can select multiple modules, each having a specific function, and combine them with one another. The group of modules can then be applied to a patient care device, such as an infusion pump. In yet another embodiment, each module may have a primary processor, a backup processor, and functional circuits, all of which communicate with each other in an operable manner. The functional circuit may include a wireless transceiver, a battery, an interface to a touchscreen or display (the display can be mounted in the housing), wired connections, Bluetooth, Bluetooth Low Energy, WiFi, 3G, 4G, a coprocessor, a control system (for example, to control an injection pump), and a drug delivery system with a fluid measurement circuit. Selected modules can be connected to each other, for example in a daisy-chain, and then connected to an injection pump. In this embodiment, the selected modules can communicate with each other in an operable manner to coordinate their operation and / or functions, for example via a CAN bus, wired communication, wireless and / or other means.

[0220] Each module may be equipped with a speaker and a microphone. When several modules are connected to each other, these modules can coordinate their operation so that one module sends an audible signal to the speaker and another module uses the microphone to determine whether the speaker is functioning properly. Several modules may each use their speaker at different frequencies, so that any one of the modules can sense sound through its microphone, demodulate those different frequencies, and test several of the speakers simultaneously. The test may be requested by a first module to a second module, and the second module may transmit the test results to the first module.

[0221] Referring again to Figure 1, one or more of the communication modules 124A to 124K may also optionally include one or more batteries to power the device coupled thereto. For example, communication module 124A may be coupled to the injection pump 7 to power it. Other structures and functions of communication modules 124A to 124K may be provided depending on the purpose and function of the device associated with them. For example, in some embodiments, injection control is performed by the injection pump, and input regarding the desired delivery is performed by the injection pump. Thus, in some embodiments of this disclosure, communication module 124A controls the injection pump 7 by executing a control algorithm, for example, a proportional-integral-derivative (PID) control loop. In such cases, monitoring client 1 may communicate a fluid flow signal to communication module 124A (for example, via a wireless link), and then apply a signal corresponding to the fluid flow signal through an electrical contact coupled to the motor of the injection pump 7 (not explicitly shown) to achieve the desired flow rate. In some embodiments, the injection pump 7 provides one or more feedback signals from a flow meter located within the injection pump 7 to a communication module 124A, thereby enabling the communication module 124A to control the operation of the injection pump 7 (e.g., several modes of operation such as a PID control system). The results are delivered to a monitoring client 1 and can be displayed to the user using a GUI such as a QT-based GUI (in some embodiments, the monitoring client 1 is a tablet). In addition to or alternatively, in some embodiments, a drip flow meter 148 can be used to wirelessly transmit the flow to the communication module 124A via a communication module 124K and antenna 122K associated with the drip flow meter 148.

[0222] As can be seen in light of this disclosure, communication modules 124A to 124K can be operably coupled to various patient care devices 7, 14, 15, 16, 17, 35, 126, 128, and 148. For example, referring further to Figure 1, communication module 124B is operably coupled to syringe pump 126, and communication module 124C is operably coupled to pill dispenser 128. In addition, or alternatively, communication module 124E is operably coupled to ECG monitor 12, communication module 124F is operably coupled to blood pressure monitor 15, communication module 124G is operably coupled to pulse oximeter / CO2 capnometer 16, communication module 124H is operably coupled to other monitors 17, communication module 124I is operably coupled to patient intravenous access 35, and communication module 124K is operably coupled to infusion flowmeter 148. Each communication module 124A-124K can provide, for example, an appropriate control system, control algorithm, battery power supply, or other functions to the respective patient care devices 7, 14, 15, 16, 17, 35, 126, 128, or 148 coupled to it.

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

[0224] In addition, or alternatively, in some embodiments, it is optional to configure the communication module 124 to provide sufficient power to each of the devices 7, 14, 15, 16, 17, 35, 126, and 148, each of which can be supplemented by one or more wired power sources, for example, power sources accessible through a bus or backplane in the device dock 104. As described above, in some embodiments of the present disclosure, the communication module 124D provides sufficient power to devices 7, 126, 128, 130, and 133.

[0225] As described above, in some embodiments, the communication module 124 each comprises a power circuit (e.g., a voltage converter, a regulating circuit, a rectifier and filtering circuit, a buck circuit, a boost circuit, a buck-boost circuit, a switch-mode power supply, etc.) that provides sufficient power to the corresponding devices 7, 126, 128, and 130. In some such cases, this power circuit can be configured to enable the provision of various power supply characteristics (e.g., voltage level, maximum load / current requirements, and A / C frequency) associated with different patient care devices 7, 14, 15, 16, 17, 35, 126, 128, and 148. Any number of power supply and management schemes are obvious in light of this disclosure.

[0226] Optionally, in other embodiments of the present disclosure, a power module 132 having one or more battery cells, for example lithium-ion battery cells, is mounted on the device dock 104 to provide sufficient power to devices 7, 126, 128, 130, and 133 for the entire duration of treatment. In addition to or alternatively, the power module 132 may be plugged into an outlet in the patient's room (generally shown as an AC source in Figure 1) if available. In such a case, outlet power, if available, can be used to power the devices in the dock 104 and to charge the batteries contained within the power module 132 (this may be done simultaneously). If outlet power is lost or otherwise unavailable, the batteries in the power module 132 and / or in the communication modules 124A, 124B, and 124C can provide power to the docked devices.

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

[0228] In some embodiments, the dongle 133 can communicate patient care parameters, such as patient treatment parameters or patient status parameters, from one or more patient care devices and retransmit them to the monitoring client 1, the hub 802 in Figure 8, and / or the monitoring server 3, and vice versa. Optionally, in some embodiments, the dongle 133 may have a wired mounting connector, such as an RS-232 connector, and be connectable to a legacy device, which can then transmit communications from that legacy device to one or more other patient care devices, the monitoring client 1, the hub 802 in Figure 8, and / or the monitoring server 3, etc. The legacy device may be, for example, a legacy patient care device, a legacy computing device, or other devices using legacy wired communication protocols.

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

[0230] Communication from the wearable system monitor 131 includes one or more query signals that can determine whether the device being queried is functioning properly, functioning within predetermined operating parameters, and / or otherwise in an undesirable state or situation. The system monitor 131 can communicate the detected state or error to one or more devices, such as the monitoring server 3, monitoring client 1, or hub 802 in Figure 8, to alert the provider, initiate a shutdown procedure, and / or initiate other appropriate corrective actions instructed for the malfunctioning device. For example, the system monitor 131 can send alert and / or alarm signals due to an abnormal query response or lack of query response using the transceiver of the communication module 124J, which communicates with monitoring client 1, monitoring server 3, other monitoring clients 4, and other devices consisting of the communication module 124 or remote communicator 11 via a WiFi router connected to the network and / or the internet. Alerts and / or alarms can cause the device to sound an audible alarm or display a visual indication of the alert and / or alarm. In some embodiments of this disclosure, the system monitor 131 includes a call button (not explicitly shown) for enabling patient 2 to make a request to a care provider, for example, the request is routed to a monitoring client 1 or remote communicator 11 to visually and / or audibly indicate the request to the user who owns the device.

[0231] The system monitor 131 can perform its functions in a variety of ways, including, for example, (1) predicting a response to a query within a predetermined time, (2) incrementing a counter within the device receiving the query and then requesting the value of the counter from the device, (3) a challenge-response query, and / or (4) other system monitoring techniques or methods.

[0232] As described above, in some embodiments, the system monitor 131 queries the patient care device paired with the system monitor 131 and then predicts a response to the query within a predetermined time. For example, the system monitor 131 may send a text string message "System Monitor Query" to the infusion pump 7. In this embodiment, the infusion pump 7 receives the message labeled "System Monitor Query" from the system monitor 131 and processes the message using one or more of its processors. When the infusion pump 7 processes the message, its software routine executes code to send a response message back to the system monitor 131, for example, the response message may be a text string message "System Monitor Response" sent to the system monitor 131. In this embodiment, the system monitor 131 can predict that it will receive a response message within a predetermined time, such as 2 seconds, and if the system monitor 131 does not receive a response message within 2 seconds, the system monitor 131 will warn and / or send an alert to other devices (for example, the system monitor 131 can broadcast an alert or error message, or can cause the processor to provide an alarm or alert audibly or visually via the remote communicator 11).

[0233] As described above, in some embodiments, the system monitor 131 increments a counter in the queried device and requests the device to provide the incremented value of the counter. For example, the system monitor 131 can send the request to a patient care device, such as an infusion pump 7, by sending a message such as “increment counter” to the device. The device's processor receives the “increment counter” message, reads the value from the device's memory location, increments the value found in the memory location, and stores the new value in the same memory location by overwriting the previous value. In this embodiment, the processor then 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 queried device. In this embodiment, the system monitor 131 predicts a specific value from the queried device (this predicted value can be stored in the system monitor's memory, for example, in a table). For example, the system monitor 131 can store in its memory a value 48 previously received from the device and predicts receiving a value 49 from the device after requesting that the value be updated in the queried device.

[0234] Furthermore, as described above, a challenge-response query can be used by the system monitor 131. For example, the system monitor 131 can send an encrypted message to a patient care device. The patient care device is then tasked with decrypting the message using, for example, an encryption key and sending the message back to the system monitor 131. The system monitor 131 can predict that an unencrypted message will be returned within a predetermined time. In this embodiment, if the system monitor 131 does not receive a response message within a predetermined time, the system monitor 131 will warn and / or transmit a warning to other devices (for example, the system monitor 131 can broadcast a warning or alarm message and / or transmit them to the monitoring client 1, monitoring server 3, hub 802 in Figure 8, or remote communicator 11, which then display or audibly indicate the warning or alarm).

[0235] In embodiments of the present disclosure, the monitoring client 1 has the ability to communicate and interact directly with a healthcare provider using a handheld or portable remote communicator 11 (which may be, for example, a smartphone, tablet computer, PDA, laptop, or other portable computing device). This can be achieved wirelessly 12, thereby maintaining communication regardless of the patient's location within the facility or the provider's location within or outside the facility. In one embodiment, patient-specific information can be stored locally within the monitoring client 1, thereby allowing the patient's healthcare provider to access the information directly without needing to access the monitoring server 3.

[0236] In some embodiments, optionally by incorporating appropriate safety and security checks, changes to the settings or flow parameters of the connected infusion pump 7 or patient monitoring devices 14-17, 35, 126, 128, 130, 148 can be directly achieved (via wired or wireless communication) between the provider's monitoring client 11 and the monitoring client 1, and selected changes can also be communicated to the monitoring server 3, and therefore optionally to other appropriate locations such as the nurse station 5 and / or pharmacy 6. Furthermore, any new instructions regarding patient 2 can be entered into the provider's remote communicator 11 (e.g., a smartphone) and transmitted to the monitoring client 1, and then communicated to the caregiver (e.g., a nurse, nurse practitioner, physician, internist, or other healthcare professional) via the caregiver's own portable communicator 11. In addition, or alternatively, in some embodiments, new instructions can be communicated to the infusion pump 7 or patient monitoring devices 14-17, 35, 126, 128, 130, 148, so that the control systems located within or coupled thereto can change their operation, for example, setpoints, in response to the new instructions. In some embodiments, any information acquired and stored within the monitoring client 1 is periodically uploaded to the monitoring server 3 and stored in a patient-specific database. Therefore, if the patient's monitoring client 1 is down, a new device can be assigned to patient 2, and the patient's current information from the monitoring server 3 can be quickly added again. Instructions, medications, progress notes, monitoring data, treatment data, patient treatment parameters, patient monitoring parameters, and / or operational parameters from the patient's attached devices can also be uploaded from the monitoring client 1 to the patient's EHR 19, any applicable remote communicator 11, the hub 802 in Figure 8, and / or the monitoring server 3 for permanent, temporary, or transient storage, and / or for analysis to verify that they conform to predetermined criteria, such as ranges, thresholds, etc.

[0237] In some embodiments, the monitoring server 3 may include a computer capable of communicating with and providing several elements of control to several monitoring clients 1, 4, 11 within the facility 8. The monitoring server 3 may provide monitoring clients 1, 4, 11 with data extracted from numerous databases both within the facility 8 and outside the facility 9. In embodiments of this disclosure, the monitoring server 3 may query the facility's EHR system 19 for target information about patient 2 and then add a predetermined set of information (e.g., patient's age, height, weight, disease category, current medications and medication categories, drug allergies and hypersensitivity, etc.) to the patient's monitoring client 1. According to one such embodiment, the monitoring server 3 may establish communication links to the EHR 19, laboratory 20, radiology department 21, pharmacy 22 and / or other systems within the facility (e.g., cardiology 23 or scheduling database 24, etc.) when, for example, monitoring client 1 is assigned to patient 2. With a unique patient identifier, the monitoring server 3 can obtain electronic access (permission) to receive and transmit patient-specific data from these systems. A predetermined (selectable) subset of the data can be downloaded into the memory of monitoring client 1 (not explicitly shown in Figure 1).

[0238] The information thus acquired can then serve as a key database from which new instructions can be analyzed in comparison. Instructions entered into the monitoring client 1 can be checked for compatibility with patient-specific information obtained by the monitoring server 3. Optionally, for security duplication, instructions entered remotely from the communicator 11 can be intercepted and similarly checked by the monitoring server 3. The monitoring server 3 can also obtain information from a drug database located in the facility's pharmacy 22 or externally 9 to determine whether a new patient instruction may result in, for example, incompatibility with the patient's existing medications. In embodiments of this disclosure, the monitoring server 3 can be programmed to access a publicly available internet site 25 to download new information about the patient's prescribed medications and determine whether it should be communicated to the patient's healthcare provider(s) as a warning or alarm 13. The monitoring server 3 can also route information between the remote portable communicator 11 and the patient's monitoring client 1.

[0239] In embodiments of this disclosure, a patient's physician, nurse, or pharmacist may have access to a patient monitoring client 1 to relay or receive new instructions (e.g., medication instructions) concerning patient 2. The monitoring client 1 or server 3 may then record the new instructions and relay the requests 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” (e.g., in particular Google’s Nexus One phone, Apple’s iPhone®, or RIM’s BlackBerry OS) having a customized communication application with the monitoring client 1 can act as a portable communicator 11 convenient for providers who are not in a fixed location (such as an office or remote nurse's station). A tablet PC, netbook, or laptop computer can also act as a portable communicator 11 convenient for both portable and fixed locations. A PC can act as a communication device 11 convenient for fixed or desktop locations. If the provider is in the patient's room, the provider may input or receive information about patient 2 using direct input via the keyboard or touchscreen on monitoring client 1.

[0240] The monitoring client 1 can receive, process, and transmit information about a specific patient 2 that is assigned or designated. The monitoring client 1 is most conveniently mountable or dockable to the monitoring client dock 102 to communicate with the infusion pump 7 or any other device to which patient 2 can be connected or associated. The monitoring client 1 may be, for example, a handheld device roughly the size of a wireless phone or a tablet netbook. It is convenient for the monitoring client 1 to have a touchscreen interface used by the patient's provider. It is also possible to provide output to a larger, fixed display in the patient's room or at the nurse's station 5 or other convenient location, either via a wired or wireless connection. Each monitoring client 1 can communicate with the central monitoring server 3, through which it can access patient data from the facility's EHR database 19, laboratory database 20, radiology database 21, pharmacy database 22, or other databases from various other facility departments. In some cases, the monitoring client 1 can upload information received from patient monitoring devices 14-17 or from provider inputs to the patient's EHR 19 via the monitoring server 3. Monitoring clients 1, 4 can also receive information from databases outside the facility via the monitoring server 3, which has an internet connection 25. Thus, various external databases 9, including various drug information databases and alert networks dealing with adverse drug-related events, are accessible.

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

[0242] In some embodiments, the communication link between monitoring clients 1, 4 and the monitoring server 3 may exist via an Ethernet network, if widely available within the facility, or via wireless transmission using one of several standards, allowing all patient-specific monitoring clients 1, 4 to be linked to the central monitoring server 3. Server 3 can then act as a relay for communication with other facility servers 8, web-based servers 25, and in-facility and out-of-facility portable communicators 11 held by healthcare providers. In some embodiments, the wireless network provides additional functionality, enabling communication between patient 2 and the monitoring server 3 regardless of their location within the facility.

[0243] One way to cover the entire facility with wireless range is to have the facility license a private cellular network. One or more micro cellular frequencies can be acquired or leased to provide a local communication network throughout the facility. Such an arrangement can maintain communication as patients and monitoring clients 1, 4 move from one location to another within the facility, maintaining connectivity with users of the monitoring server 3, various in-hospital and out-of-hospital databases 8, 25 and fixed stations (e.g., in some embodiments, nurse stations 5 and pharmacies 6), or with monitoring clients 11 (e.g., mobile smartphones, laptops, or tablet-type devices) either inside or outside the hospital. In some embodiments, this type of system provides additional security via the authorized cellular communication infrastructure. In addition, in some embodiments, the active wireless system can monitor the usage intensity within an area and direct additional channel frequencies to that area. However, in some embodiments, the network bandwidth capacity may not allow for the efficient transmission of large data files, such as those containing radiographic images. Such bandwidth-intensive data files can be transmitted more efficiently via wired connections.

[0244] Alternatively, or in addition, the hospital may implement an internet or intranet-based communication system in which the 802.11 WiFi type protocol is used for wireless communication between individual monitoring clients 1, 4 and the monitoring server 3. To ensure proper signal reception throughout the facility, broadband antennas may be installed on the building's roof to collect mobile phone signals from local radio telephone companies. Fiber optic or cable networks can then distribute the signals throughout the facility. In addition, or alternatively, the monitoring server 3 may use the private mobile phone network described above. Such systems are typically capable of providing secure communication and efficiently transmitting large files, such as radiographic images stored in the radiographic database 21. Home or office-based users can connect to the hospital server via, for example, VPN or another secure access using wired or fiber optic cables, or via DSL telephone lines. Data encryption can be used to provide patient data security. In some applications, it may be advantageous to implement an asymmetric bandwidth communication network to optimize infrastructure capabilities. This embodiment uses licensed cellular frequencies in the "upstream" direction from monitoring client 1 to monitoring server 3, and unlicensed 802.11 WiFi frequencies in the "downstream" direction from monitoring server 3 to monitoring client 1. In this embodiment, the upstream bandwidth and data transfer rate requirements are relatively small compared to the downstream requirements. For the lower-priority upstream transmission, monitoring client 1 is allowed to transmit data through a more distributed and cost-effective network, such as a ZigBee® network, a Bluetooth network, or a mesh network.

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

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

[0247] In many cases, the information transmitted to the monitoring client 1 may include a single parameter value (e.g., blood pressure) and a timestamp. The monitoring client 1 can be programmed to determine if the value is outside a predetermined range, record the value in the patient's EHR 19, and notify the appropriate provider via its monitoring client 11. Furthermore, the network enables bidirectional communication, allowing the monitoring client 1 to query a patient monitoring device (e.g., a BP monitor 15) and instruct it to perform an unscheduled reading. This may be useful, for example, when an abnormal reading is received and its authenticity needs to be verified. The monitoring client 1 can be programmed to request repeated readings to verify the abnormal reading. In another embodiment, the monitoring client 1 can be programmed to interrupt or adjust the flow rate, operating parameters, and / or therapeutic parameters of the infusion pump 7 based on readings received from monitoring devices 14-17. For example, if the BP monitor 15 shows a blood pressure below a predetermined tolerance range, the monitoring client 1 can be programmed to instruct the infusion pump 7 to stop infusion and transmit an emergency notification 12 to the monitoring clients 11 of (one or more) healthcare providers. In another embodiment, if the infusion pump 7 is capable of determining the amount of fluid being delivered to the patient 2 (e.g., the flow rate or cumulative amount of fluid pumped in over a period of time), the processor in the monitoring client 1 can track the cumulative amount delivered and estimate the amount of fluid remaining in the drug bag 170. (Alternatively, the monitoring client 1 or the processor in the infusion pump 7 may calculate the amount delivered from the infusion rate and the elapsed time of infusion.)

[0248] When the estimated residual 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 intravenous access 35 from becoming empty. For example, if the monitoring client 1 determines that a nurse is scheduled to return at a specific time to change the bag, rather than warning and / or sending an alarm that the intravenous fluid will run out before the nurse's scheduled return time, the monitoring client 1 may signal the infusion pump 7 to slow down the infusion rate so that the intravenous bag is empty when the nurse arrives or a predetermined time after the nurse's scheduled return time. Alternatively, a notification recommending the replenishment of the intravenous bag 17 may be sent to the nurse's monitoring client 11.

[0249] In some embodiments, the progress of the operation of a patient care device is indicated by the outer edge of the display of the monitoring client 1 to show the state and / or progress of the patient care device. For example, the outer edge is displayed on the display of the monitoring client 1 so that the percentage of the outer edge that is lit up (e.g., as the outer edge fills in, it begins to form a fully filled perimeter) indicates the progress of treatment achieved by the patient care device, e.g., infusion pump 7. This outer edge may be sent from the infusion pump 7 to the monitoring client 1 in an image format (e.g., JPEG, BMP, etc.) and / or as a filled percentage value to the monitoring client 1, in which case the monitoring client 1 creates the outer edge.

[0250] In some embodiments, GPS and / or ranging modules (e.g., ultrasonic ranging modules using time-of-flight estimation) may be installed in the infusion pump 7, monitoring client 1, caregivers and / or patients. A predetermined configuration may require that a predetermined group of infusion pump 7, monitoring client 1, hub 802 in Figure 8, caregivers and / or patients be within a predetermined distance of each other before initiating treatment and / or before configuring one of the infusion pump 7 and / or monitoring client 1.

[0251] In some embodiments, patient care devices 7, 170, 126, 128, 130, 14, 15, 16, 17, 124 or 148, dock 102 or 104, monitoring client 1, and hub 802 in Figure 8 may transmit soft alarms, hard alarms, and / or non-critical alarms to the remote communicator 11 without warning at the alarm-emitting device and / or monitoring client 1 until a predetermined time has elapsed (for example, to allow the caregiver to find a solution to remove the cause of the alarm without disturbing the patient). If the cause of the alarm has been removed before the predetermined time, the alarm-emitting device and / or monitoring client 1 may not warn, thereby preventing further disturbance to the patient.

[0252] In some embodiments, the AC cable in Figure 1 is equipped with a clip, which allows a venous tube to be clipped to it.

[0253] In some embodiments, the infusion pump 7 is equipped with LED lights that indicate one or more of the following: that a safety check has been passed; that the pump is injecting; that there is an obstruction; and / or that the pump is off. The user can use the monitoring client 1 to read a barcode on the intravenous bag 170 (for example, using camera 144 or camera 136 and / or scanner 120), at which point the LED on the plug may flash to indicate to the user that a tube connected to the intravenous bag 170 should be inserted into it.

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

[0255] In addition, in some embodiments, several items, components, devices, patient care devices, docks, and computing devices, both numbered and unnumbered, as shown in Figure 1 or described herein, are intended to be used as a single item, component, device, patient care device, dock, or computing device, but multiple items, components, devices, patient care devices, docks, and computing devices are intended. For example, although a single infusion pump 7 is shown in Figure 1, in some embodiments, two infusion pumps 7 may be used, a number of infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. In addition, or alternatively, in some embodiments, a number of device docks 104 and / or a number of monitoring client docks 102 may be used.

[0256] In addition, or as an alternative, although specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, and 148 are shown, other combinations, subsets, multitude, or combinations thereof of specific patient care devices may also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is used, and in this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered off, or not part of system 100 in Figure 1. In addition, or alternatively, in some specific embodiments, only the patient care device being used is dockable to the device dock 104. For example, in this particular embodiment, the infusion pump 7 is the only device docked within the device dock 104, and the device dock 104 receives only one device, e.g., the infusion pump 7. In addition, or alternatively, or optionally, in some specific embodiments, the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be dockable, operate undocked, and / or not dockable, and can operate as standalone patient care devices.

[0257] In some embodiments, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130 and / or 148, monitoring client 1, remote communicator 11, and docks 102 and / or 104 may have safety data classes, for example via an API.

[0258] Any of the functions described with reference to Figure 1 may, in some embodiments, be performed by the hub 802 in Figure 8.

[0259] Figure 2 shows a flowchart illustrating a method 150 for maintaining communication between a monitoring client, e.g., monitoring client 1 in Figure 1, and one or more patient care devices, e.g., one or more of patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 in Figure 1, according to an embodiment of the present disclosure. Method 150 of this embodiment includes actions 152 to 169. Monitoring client 1 may display an icon indicating that communication has been established with the pairing and / or designated patient care device. Monitoring client 1 may check to determine that communication with the pairing and / or designated patient care device is available at predetermined intervals, and if communication with the pairing or designated patient care device is unavailable for a predetermined period of time, monitoring client 1 may sound an alarm or alert.

[0260] Action 152 determines whether the monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock via the dock connector. If the communication link for act 152 is available, method 150 proceeds to act 154; otherwise, method 150 proceeds to act 156.

[0261] Act 156 determines whether the monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock via a wireless link. If the link in Act 156 is available, method 150 proceeds to act 154; otherwise, method 150 proceeds to act 158.

[0262] Act 154 determines whether the monitoring client dock is available as a communication link between the monitoring client dock and the device dock using a cable. If the communication link in Act 154 is available, Method 150 proceeds to Act 160; otherwise, Method 150 proceeds to Act 158. Act 160 determines whether the device dock is available as a communication link between the device dock and the patient care device, for example, via a wireless or wired communication link. If the communication link in Act 160 is available, Method 150 proceeds to Act 166; otherwise, Method 150 proceeds to Act 162. Act 162 determines whether the patient care device is available as a communication link between the monitoring client and the patient care device dock via a direct wireless link. If the communication link in Act 162 is available, Method 150 proceeds to Act 166; otherwise, Method 150 proceeds to Act 164.

[0263] Act 158 ​​determines whether the device dock is available as a communication link between the monitoring client and the device dock via a wireless link. If the communication link in Act 158 ​​is not available, method 150 proceeds to act 162; otherwise, method 150 proceeds to act 160.

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

[0265] Method 150 is an exemplary embodiment of the present disclosure, describing a method for maintaining communication between a monitoring client and one or more patient care devices. In some embodiments, Method 150 includes scheduling of communication links, but other scheduling methods may be used, broadcast, anycast, multicast or unicast may be used, routing algorithms may be used, distance vector routing protocols may be used, link state routing protocols may be used, optimized link state routing protocols may be used, path vector protocols may be used, static routing on a given alternative communication path may be used, and / or adaptive networking may be used. For example, in some embodiments of the present disclosure, weights may be assigned to each communication path, and Dijkstra's algorithm may be used for communication between monitoring client 1 and one or more patient care devices. The weights may be determined in any known way, for example, as a function of bandwidth, signal quality, bit error rate, or linear to available data throughput or latency, and / or similar.

[0266] Referring to the drawings, Figure 3 shows a block diagram of an electronic patient care system 300 having two docks 102, 104 and communicating wirelessly between them, according to another embodiment of the present disclosure. System 300 is similar to System 100 in Figure 1, except that communication between the monitoring client dock 102 and the device dock 104 is via a wireless link. For example, in some embodiments, System 300 in Figure 3 is System 100 in Figure 1 with the cable 110 of Figure 1 absent or not operational, and in addition, or alternatively, System 300 in Figure 3 may have docks 102 and 104 that are not connected together using a cable.

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

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

[0269] Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 300 is operating properly or within a given boundary, and / or send data back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11 in order to display the data on the displays of monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate to one or more monitoring clients 1, other monitoring clients 4, and / or remote communicators 11 (if applicable) the upstream pressure, changes in upstream pressure, downstream pressure relative to patient 2, changes in downstream pressure relative to patient 2, presence or absence of air in the infusion line, actual bolus volume 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 may optionally return data to monitoring client 1, other monitoring clients 4, and / or remote communicators 11, such as the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criterion was exceeded.

[0270] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 can be analyzed for any given condition to issue alarms and / or warnings. For example, one or more monitoring clients 1, 4, and 11 can use an increase in downstream pressure in the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 as one manifestation of excessive coagulation, infiltration, blockage, or kinking of the tubing to the patient, or blockage by other material in the intravenous bag 170. In response to a rapid increase in downstream pressure, one or more monitoring clients 1, 4, and 11 can issue a visual or audible warning or alert to the user. In addition, or alternatively, a sudden drop in downstream pressure to patient 2 is an indication that the tube has detached from the needle and / or the needle is now detached from the patient, and accordingly, one or more of the monitoring clients 1, 4, and 11 may issue a visual or auditory warning or alert to the user. Optionally, one or more of the monitoring clients 1, 4, and 11 may send an instruction to one or more of the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

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

[0272] In addition, in some embodiments, several items, components, devices, patient care devices, docks, and computing devices, both numbered and unnumbered, as shown in Figure 3 or described herein, are intended to be used as single items, components, devices, patient care devices, docks, or computing devices, although multiple items, components, devices, patient care devices, docks, and computing devices are intended. For example, although a single infusion pump 7 is shown in Figure 3, in some embodiments, two infusion pumps 7 may be used, a number of infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. In addition, or alternatively, in some embodiments, a number of device docks 104 and / or a number of monitoring client docks 102 may be used.

[0273] In addition, or alternatively, although specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, and 148 are shown, other combinations, subsets, multitude, or combinations thereof of specific patient care devices may also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is used, and in this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered off, or not part of the system 300 in Figure 3. In addition, or alternatively, in some embodiments, only the patient care devices used are dockable in the device dock 104. For example, in a particular embodiment, the infusion pump 7 is the only device docked in the device dock 104, and the device dock 104 receives only one device, e.g., the infusion pump 7. In addition, as an alternative or optional, in some specific embodiments, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be dockable, can operate undocked, and / or can be non-dockable and operate as standalone patient care devices.

[0274] Although Figure 3 shows that the device dock 104 is capable of receiving several patient care devices, in other embodiments, the device dock 104 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Also, there may be unused compartments in the dock; for example, an empty compartment 170 is shown within the device dock 104 as shown in Figure 3. In addition, although the monitoring client dock 102 is shown as capable of receiving one monitoring client 1, in other embodiments, the monitoring client dock 102 can receive two monitoring clients 1, three or more monitoring clients 1, or any number of monitoring clients 1.

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

[0276] Act 204 determines whether the monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock via the dock connector. If the communication link in Act 204 is available, method 202 proceeds to Act 206; otherwise, method 202 proceeds to Act 208. Act 208 determines whether the monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock via the wireless link. If the communication link in Act 208 is available, method 202 proceeds to Act 206; otherwise, method 202 proceeds to Act 210.

[0277] Act 206 determines whether the monitoring client dock is available as a communication link between the monitoring client dock and the device dock via a wireless link. If the communication link in act 206 is available, method 202 proceeds to act 212; otherwise, method 202 proceeds to act 210.

[0278] Act 210 determines whether the device dock is available as a communication link between the monitoring client and the device dock via a wireless link. If the communication link in act 210 is available, method 202 proceeds to act 212; otherwise, method 202 proceeds to act 214.

[0279] Action 212 determines whether the device dock is available as a communication link between the device dock and the patient care device. If the communication link in Action 212 is available, Method 202 proceeds to Action 216; otherwise, Method 202 proceeds to Action 214.

[0280] Action 214 determines whether the patient care device is available as a communication link between the monitoring client and the patient care device via a direct wireless link. If the communication link in Action 214 is available, Method 202 proceeds to Action 216; otherwise, Action 218 determines that communication with the patient care device is not available.

[0281] Action 216 attempts a handshake between the monitoring client and the patient care device using one or more available communication links. In alternative embodiments, no handshake is attempted, and some communication protocols, for example, do not utilize handshakes. Decision action 220 determines whether the handshake was successful and whether communication between the monitoring client and the device has been established. If action 220 determines that a communication link has been established, method 202 communicates data between the monitoring client and the device during action 222 using one or more available communication links. If decision action 220 determines that the handshake was unsuccessful, method 202 determines that communication with the device is not available in action 218, or method 202 attempts to communicate between monitoring clients through an unverified communication link (not explicitly shown).

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

[0283] Referring now to Figure 5, an electronic patient care system 500 in block diagram form is shown, according to yet another embodiment of the present disclosure, having a dock 502 for docking together 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 dongle 133. The electronic patient care system 500 of Figure 5 is similar to the electronic patient care system 100 of Figure 1, except that each of the monitoring client 1, patient care devices 7, 126, 128, 130, communication module 124D, and dongle 133 is dockable to the dock 502. As can be seen in light of this disclosure, the dock 502 may include one or more buses, backplanes, communication paths, electronic circuits, etc., to facilitate communication.

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

[0285] Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 500 is operating properly or within a given boundary, and / or send data back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11 in order to display the data on the displays of monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate to one or more monitoring clients 1, other monitoring clients 4, and / or remote communicators 11 (if applicable) the upstream pressure, changes in upstream pressure, downstream pressure relative to patient 2, changes in downstream pressure relative to patient 2, presence or absence of air in the infusion line, actual bolus volume 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 may optionally return data to monitoring client 1, other monitoring clients 4, and / or remote communicators 11, such as the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criterion was exceeded.

[0286] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 can be analyzed for any given condition to issue alarms and / or warnings. For example, one or more monitoring clients 1, 4, and 11 can use an increase in downstream pressure in the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 as one manifestation of excessive coagulation, infiltration, blockage, or kinking of the tubing to the patient, or blockage by other material in the intravenous bag 170. In response to a rapid increase in downstream pressure, one or more monitoring clients 1, 4, and 11 can issue a visual or audible warning or alert to the user. In addition, or alternatively, a sudden drop in downstream pressure to patient 2 is an indication that the tube has detached from the needle and / or the needle is now detached from the patient, and accordingly, one or more of the monitoring clients 1, 4, and 11 may issue a visual or auditory warning or alert to the user. Optionally, one or more of the monitoring clients 1, 4, and 11 may send an instruction to one or more of the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

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

[0288] In addition, in some embodiments, several items, components, devices, patient care devices, docks, and computing devices, both numbered and unnumbered, as shown in Figure 5 or described herein, are intended to be used as a single item, component, device, patient care device, dock, or computing device, although multiple items, components, devices, patient care devices, docks, and computing devices are intended. For example, although a single infusion pump 7 is shown in Figure 5, in some embodiments, two infusion pumps 7 may be used, a number of infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. In addition, or alternatively, in some embodiments, a number of docks 502 may be used.

[0289] In addition, or alternatively, although specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, and 148 are shown, other combinations, subsets, multitude, or combinations thereof of specific patient care devices may also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is used, and in this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered off, or not part of system 500 in Figure 5. In addition, or alternatively, in some specific embodiments, only the patient care devices used are dockable in dock 502. For example, in one particular embodiment, the infusion pump 7 is the only device docked in device dock 502, and device dock 502 receives only one device, e.g., the infusion pump 7. In addition, as an alternative or optional, in some specific embodiments, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be dockable, can operate undocked, and / or can be non-dockable and operate as standalone patient care devices.

[0290] Although Figure 5 shows that the dock 502 is capable of receiving several patient care devices, in other embodiments, the dock 502 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Also, there may be unused compartments in the dock; for example, as shown in Figure 5, an empty compartment 170 is shown within the dock 502. In addition, although the dock 502 is shown as capable of receiving one monitoring client 1, in other embodiments, the dock 502 can receive two monitoring clients 1, three or more monitoring clients 1, or any number of monitoring clients 1.

[0291] Figure 6 is a flowchart illustrating a method 304 for maintaining communication between a monitoring client, for example, monitoring client 1 in Figure 5, and one or more patient care devices, for example, one or more of the patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 in Figure 5, according to an embodiment of the present disclosure.

[0292] The method determines during action 306 whether the dock is available as a communication link between the monitoring client and the dock via the dock connector. If the communication link in action 306 is not available, method 304 proceeds to action 308; otherwise, method 304 proceeds to action 310. Action 310 determines whether the dock is available as a communication link between the dock and the patient care device. If the communication link in action 310 is not available, method 304 proceeds to action 312; otherwise, method 304 proceeds to action 314.

[0293] Act 308 determines whether the dock is available as a communication link between the monitoring client and the dock via a wireless link. If the communication link in act 308 is not available, method 304 proceeds to act 310; otherwise, method 304 proceeds to act 312.

[0294] Action 312 determines whether the patient care device is available as a communication link between the monitoring client and the patient care device via a direct wireless link. If the communication link in Action 312 is not available, Action 316 determines that communication between the monitoring client and the patient care device is not available.

[0295] Action 314 attempts a handshake between the monitoring client and the device using one or more available communication links. In alternative embodiments, the handshake is not used; for example, some protocols do not utilize the handshake. Decision action 318 determines whether the handshake was successful, and if successful, method 304 proceeds to action 320 to communicate data using one or more available communication links. If decision action 318 determines that the handshake was unsuccessful in action 314, action 316 determines that communication with the device is not available. In other embodiments, if decision action 318 determines that the handshake was unsuccessful in action 314, method 304 attempts to communicate with the patient care device via an unverified communication link (not explicitly shown).

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

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

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

[0299] Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 700 is operating properly or within a given boundary, and / or can send data back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11 to display the data on the displays of monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, optionally, the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may communicate to one or more monitoring clients 1, other monitoring clients 4, and / or remote communicators 11 (if applicable) the upstream pressure, changes in upstream pressure, downstream pressure relative to patient 2, changes in downstream pressure relative to patient 2, presence or absence of air in the infusion line, actual bolus volume 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 may optionally return data to monitoring client 1, other monitoring clients 4, and / or remote communicators 11, such as the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criterion was exceeded.

[0300] Data received from patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 can be analyzed for any given condition to issue alarms and / or warnings. For example, one or more monitoring clients 1, 4, and 11 can use an increase in downstream pressure in the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 as one manifestation of excessive coagulation, infiltration, blockage, or kinking of the tubing to the patient, or blockage by other material in the intravenous bag 170. In response to a rapid increase in downstream pressure, one or more monitoring clients 1, 4, and 11 can issue a visual or audible warning or alert to the user. In addition, or alternatively, a sudden drop in downstream pressure to patient 2 is an indication that the tube has detached from the needle and / or the needle is now detached from the patient, and accordingly, one or more of the monitoring clients 1, 4, and 11 may issue a visual or auditory warning or alert to the user. Optionally, one or more of the monitoring clients 1, 4, and 11 may send an instruction to one or more of the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

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

[0302] In addition, in some embodiments, several items, components, devices, patient care devices, docks, and computing devices, both numbered and unnumbered, as shown in Figure 7 or described herein, are intended to be used as single items, components, devices, patient care devices, docks, or computing devices, although multiple items, components, devices, patient care devices, docks, and computing devices are intended. For example, although a single infusion pump 7 is shown in Figure 7, in some embodiments, two infusion pumps 7 may be used, a number of infusion pumps 7 may be used, or any number of infusion pumps 7 may be used. In addition, or as an alternative, in some embodiments, an integrated dock 702 may be used.

[0303] In addition, or alternatively, although specific patient care devices 7, 14, 15, 16, 17, 126, 128, 130, and 148 are shown, other combinations, subsets, multitude, or combinations thereof of specific patient care devices may also be used. For example, in some embodiments, only the infusion pump 7 among the patient care devices is used, and in this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered off, or not part of the system 700 in Figure 7. In addition, or alternatively, in some particular embodiments, only the patient care devices used are dockable in the integrated dock 702. For example, in one particular embodiment, the infusion pump 7 is the only device docked in the integrated dock 702, and the integrated dock 702 receives only one device, e.g., the infusion pump 7. In addition, as an alternative or optional, in some specific embodiments, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be dockable, can operate undocked, and / or can be non-dockable and operate as standalone patient care devices.

[0304] Although Figure 7 shows that the integrated dock 702 is capable of receiving several patient care devices, in other embodiments, the integrated dock 702 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Also, there may be unused compartments in the dock; for example, as shown in Figure 7, an empty compartment 170 is shown within the integrated dock 702. In addition, although the integrated dock 702 is shown as capable of receiving one integrated monitoring client 1, in other embodiments, the integrated dock 702 can receive two integrated monitoring clients 1, three or more integrated monitoring clients 1, or any number of integrated monitoring clients 1.

[0305] Figure 8 is a block diagram of an electronic patient care system 800 having a hub 802 according to yet another embodiment of the present disclosure. Optionally, in some embodiments, the hub 802 provides a communication interface between the monitoring client dock 102 and the device docks 804, 806. In further embodiments, the hub 802 controls patient care devices without monitoring client 1, other monitoring clients 4, and / or remote communicators 11. For example, the hub 802 can communicate with monitoring server 3, facility services 8, nurse station 5, pharmacy 6, cloud server 25, online drug database or drug adverse 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 thereto (e.g., patient care devices, monitoring clients, remote communicators, etc.) use the hub 802's clock, real-time devices use the hub 802's clock, or time-critical devices use the hub 802's clock.

[0306] In some embodiments, GPS and / or ranging modules (e.g., ultrasonic ranging modules) can be installed on the infusion pump 830, monitoring client 1, hub 802, caregivers, and / or patients. A predetermined configuration may require that a predetermined group of the infusion pump 830, monitoring client 1, hub 802, caregivers, and / or patients be within a predetermined distance of each other before initiating treatment and / or before configuring one of the infusion pump 830, hub 802, and / or monitoring client 1.

[0307] In some embodiments, the hub 802 provides an application programming interface (API) to display a GUI, windows, data, etc., on the monitoring client 1 and / or the remote communicator 11. The API may include a secure data class. In further embodiments, the docks 102, 804, and / or 806 provide an API to display a GUI, windows, data, etc., on the monitoring client 1 or the remote communicator 11. In even further embodiments, the docks 102, 804, or 806, or the hub 802, provide an API to display a GUI, windows, data, etc., on the patient care devices 830, 810, and / or 814.

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

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

[0310] The user interfaces described herein may utilize a request action framework.

[0311] 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 particular embodiment, the hub 802 receives treatment parameters from the monitoring client 1, and the hub 802 ensures that the treatment parameters are safe for patient 2, independently of any safety checks performed somewhere, for example, on the monitoring client 1. In further specific embodiments, the system 800 is optionally fully fault-tolerant to the monitoring client 1 and can ignore instructions, requests, or parameters from the monitoring client 1 if, for example, an independent safety check performed on the monitoring client 1 does not meet a predetermined standard, for example, a predetermined safe range for drug delivery by the infusion pump 7.

[0312] In optional and additional specific embodiments, a barcode attached to the intravenous bag 170 can be scanned by the scanner 120, which downloads a predetermined prescription (e.g., from the patient's personal EHR 19') and / or the infusion pump 830 includes the predetermined prescription uploaded to the hub 802 when the hub 802 is docked to the dock 804. Then, in this particular embodiment, and also optional, the hub 802 initiates the infusion of the intravenous bag 170 into patient 2 and monitors the progress of the treatment to ensure patient 2's safety. In addition, or alternatively, or optionally, in this particular embodiment, the caregiver can interact with the system 800 as shown in Figure 8, solely through the hub 802. In optional and 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 received from the infusion pump 830, or treatment information received from the patient's personal EHR 19' corresponding to a scanned barcode on the intravenous bag 170, to the monitoring client 1, display it to the user, allow the user to review the information, and store it in the monitoring client 1.

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

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

[0315] Optionally, patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 148 may also determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 800 is operating properly or within a predetermined boundary, and / or send data back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11 to display the data on the displays of monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, optionally, one or more of the infusion pumps 830, 810, and 812 may communicate (if applicable) upstream pressure, changes in upstream pressure, downstream pressure relative to patient 2, changes in downstream pressure relative to patient 2, presence or absence of air in the infusion line, actual bolus volume 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 to one or more of the monitoring client 1, other monitoring clients 4, and / or remote communicators 11. In another embodiment, the pill dispenser 814 may optionally return data to the monitoring client 1, other monitoring clients 4, and / or remote communicators 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criterion was exceeded.

[0316] Data received from patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, and 148 may be analyzed for any given condition in order to issue alarms and / or warnings. For example, one or more monitoring clients 1, 4, and 11 may use an increase in the downstream pressure of one or more infusion pumps 830, 810, and 812 as one manifestation of excessive coagulation, infiltration, blockage, or kinking of the tubing to the patient, or blockage by other material in the intravenous bag 170. In response to a rapid increase in downstream pressure, one or more monitoring clients 1, 4, and 11 may issue a visual or audible warning or alert to the user. In addition to or alternatively, a rapid decrease in downstream pressure to patient 2 may be a manifestation of the tubing detaching from the needle and / or the needle now detaching from the patient, and in response, one or more monitoring clients 1, 4, and 11 may issue a visual or audible warning or alert to the user. One or more monitoring clients 1, 4, and 11 may optionally send instructions to one or more infusion pumps 830, 810, and 812 to stop fluid delivery in response to a rapid increase and / or decrease in downstream pressure to patient 2.

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

[0318] In addition, in some embodiments, several items, components, devices, patient care devices, docks, and computing devices, both numbered and unnumbered, as shown in Figure 8 or described herein, are intended to be used as single items, components, devices, patient care devices, docks, or computing devices, although multiple items, components, devices, patient care devices, docks, and computing devices are intended. For example, although a single pill dispenser 814 is shown in Figure 8, 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. In addition, or alternatively, in some embodiments, multiple docks 804 or 806 and / or multiple monitoring client docks 102 may be used.

[0319] In addition, or alternatively, although specific patient care devices 830, 810, and 812 are shown, other combinations, subsets, numerous or any combination of specific patient care devices may also be used. For example, in some embodiments, only the infusion pump 830 among the patient care devices is used, and in this particular embodiment, the other patient care devices 810, 812, and 814 may be disabled, not present or available for system use, powered off, or not part of system 800 in Figure 8. In addition, or alternatively, in some specific embodiments, only the patient care devices used are dockable to dock 804 or 806. For example, in one particular embodiment, the infusion pump 830 is the only device docked in dock 804, and dock 804 receives only one device, e.g., the infusion pump 830.

[0320] Although Figure 8 shows that the dock 804 can receive several patient care devices, in other embodiments, the device dock 804 can receive one patient care device, multiple patient care devices, or any number of patient care devices. Also, the compartments of the dock may not be used (not shown in Figure 8). In addition, although the monitoring client dock 102 is shown to be able to receive one monitoring client 1, in other embodiments, the monitoring client dock 102 can receive two monitoring clients 1, three or more monitoring clients 1, or any number of monitoring clients 1. In addition, as an alternative or optional, in some specific embodiments, patient care devices 14, 15, 16, 17, 35, 830, 810, 812, and 814 can be dockable, can operate undocked, and / or are not dockable and can operate as standalone patient care devices.

[0321] The system 800 in Figure 8 can maintain communication with it using any known communication method. For example, in some embodiments, any communication schedule can be used, broadcast, anycast, multicast or unicast can be used, routing algorithms can be used, distance vector routing protocols can be used, link state routing protocols can be used, optimized link state routing protocols can be used, path vector protocols can be used, static routing on a given alternative communication path can be used and / or adaptive networking can be used. For example, in some embodiments of the present disclosure, weights may be assigned to each communication path, and Dijkstra's algorithm may be used to communicate between the monitoring client 1 or hub 802 and one or more patient care devices (e.g., patient care devices 830, 810, 812, and 814). The weights may be determined in any known way, for example, as a function of bandwidth, signal quality, bit error rate, or linear to available data throughput or latency, and / or similar.

[0322] In embodiments 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 soft alarms and / or a second set of predetermined criteria for triggering hard alarms. Soft alarms may be disabled (e.g., stopped) by a caregiver using the user interface of the infusion pump 830, the user interface 808 of the hub 802 and / or the user interface of the monitoring client 1 (and may also be audible and / or vibratory alarms only), while hard alarms may interrupt treatment until the cause of the hard alarm is removed.

[0323] In further embodiments of the present disclosure, the DERS system may include a first set of predetermined criteria defining soft limits, and / or a second set of predetermined criteria defining hard limits. The hard and soft limits define treatment limits, such as drug dosage, based on physique, weight, age, other patient parameters, or other criteria. The soft limits can be disabled by a caregiver using 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, allowing treatment to be initiated even if the treatment is outside the predetermined criteria of the first set, while the hard limits prevent treatment from being initiated until the settings are changed to meet the predetermined criteria of the second set defining hard limits.

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

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

[0326] Optionally, monitoring clients 902, other monitoring clients 4, and / or remote communicators 11 can be used to send instructions or requests to patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148, for example, bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow rate profile to stackable infusion pump 904, stackable syringe pump 906, and / or other stackable patient care devices 908. In some embodiments, one or more monitoring clients 902, 4, 11 can be used to send instructions or requests to pill dispenser 128, for example, pill distribution instructions, pill type, pill distribution schedule, and / or maximum pill distribution criteria for dispensing pills. The maximum pill dispensing standard is the maximum amount of medication that can be delivered within a given time. For example, a particular medication is taken as needed (i.e., when needed), but if taken in excess, the medication may be unsafe. The maximum pill dispensing standard can prevent patients from taking unsafe amounts of medication, for example, "a prescribed amount within a given time."

[0327] Optionally, patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, and 148 can also send data back to monitoring client 902, other monitoring clients 4, and / or remote communicators 11 to determine whether an alarm or alert should be issued or transmitted, whether a treatment or condition is safe for the patient, whether the system 900 is operating properly or within a given boundary, and / or display the data on the displays of monitoring client 902, other monitoring clients 4, and / or remote communicators 11. For example, optionally, the stackable infusion pump 904, stackable syringe pump 906, and / or other stackable patient care devices 908 may communicate upstream pressure, changes in upstream pressure, downstream pressure relative to patient 2, changes in downstream pressure relative to patient 2, presence or absence of air in the infusion line, actual bolus volume 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 to one or more of the monitoring client 902, other monitoring clients 4, and / or remote communicators 11 (if applicable). In another embodiment, the pill dispenser 128 may optionally return data to the stackable monitoring client 902, other monitoring clients 4, and / or remote communicators 11, such as the actual pills dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or whether the maximum pill dispensing criterion was exceeded.

[0328] Data received from patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, and 148 can be analyzed for the presence or absence of any predetermined condition and may trigger alarms and / or warnings. For example, one or more monitoring clients 902, 4, and 11 may use an increase in downstream pressure of the stackable infusion pump 904 and / or stackable syringe pump 906 as one manifestation of excessive coagulation, infiltration, blockage or kinking of the tubing to the patient, or blockage by other material in the intravenous bag 170. In response to a rapid increase in downstream pressure, one or more monitoring clients 902, 4, and 11 may issue a visual or audible warning or alert to the user. In addition, or alternatively, a sudden drop in downstream pressure to patient 2 is an indication that the tube has detached from the needle and / or the needle is now detached from the patient, and accordingly, one or more of the monitoring clients 902, 4, and 11 may issue a visual or auditory warning or alert to the user. Optionally, one or more of the monitoring clients 902, 4, and 11 may send instructions to one or more of the stackable infusion pumps 904 and / or stackable syringe pumps 906 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

[0329] The stackable monitoring client 902, stackable device 908, stackable infusion pump 904, and stackable syringe pump 906 can be daisy-chained together via connectors coupled to the top and bottom of each device. For example, the stackable syringe pump 906 can instead be stacked on top of the monitoring client 902, thereby electrically coupling the bottom connector of the stackable syringe pump 906 to the top connector of the monitoring client 902.

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

[0331] In addition, or alternatively, the stackable devices 902, 908, 904, and 906 may optionally maintain wireless communication with one another. For example, the stackable monitoring client 902 can detect that a daisy-chained conductor is electrically unresponsive due to an internal short circuit in one of the stackable devices 902, 908, 904, or 906, and the stackable monitoring client 902 can query each of the stackable devices 908, 904, or 906 to determine which device has failed. After making this determination, the stackable monitoring client 902 can wirelessly communicate with the isolated disconnect circuit in the failed device among the stackable devices 902, 908, 904, or 906 to electrically disconnect the failed device from the daisy-chained conductor. In addition, or alternatively, one or more of the stackable devices 902, 908, 904, and 906 may send a warning, alert, and / or display a message if one of the stackable devices 902, 908, 904, and 906 is failing and / or if one of the stackable devices 902, 908, 904, and 906 is communicating wirelessly rather than via a daisy-chained wired communication link.

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

[0333] In addition, in some embodiments, although several items, components, devices, patient care devices, and computing devices are shown as a single item, component, device, patient care device, or computing device, whether numbered or unnumbered, as shown in or described with Figure 9, multiple items, components, devices, patient care devices, and computing devices are intended. For example, although a single pill dispenser 128 is shown in Figure 9, in some embodiments, two pill dispensers 128 may be used, a number of pill dispensers 128 may be used, or any arbitrary number of pill dispensers 128 may be used.

[0334] In addition, or alternatively, although specific patient care devices 904, 906, and 908 are shown, other combinations, subsets, numerous or any combination of specific patient care devices may also be used. For example, in some embodiments, only the stackable infusion pump 904 of the patient care devices is used, and in this particular embodiment, the other patient devices 906 and 908 may be disabled, not present or available for system use, powered off, or not part of system 900 in Figure 9. In addition, or alternatively, in some specific embodiments, only the patient care devices used are stacked. For example, in one particular embodiment, the infusion pump 904 is the only stacked device. In addition, or alternatively, non-stackable patient care devices, such as patient care devices 904, 906, and / or 908, may continue to operate if they are operating as standalone devices. In addition, as an alternative or optional, in some specific embodiments, patient care devices 14, 15, 16, 17, 35, 904, 906, 908, 128, 148 may be dockable, operate undocked, and / or be non-dockable and operate as standalone patient care devices.

[0335] Although Figure 9 shows that the stack can accommodate several patient care devices, in other embodiments the stack may accommodate one patient care device, multiple patient care devices, or any number of patient care devices. In addition, although the stack is shown to accommodate one monitoring client 902, in other embodiments two stackable monitoring clients 902, three or more stackable monitoring clients 902, or any number of stackable monitoring clients 902 may be stacked together in the system 900.

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

[0337] Referring to Figures 1, 3, 5, 7, 8, and 9, various update techniques and / or methods may be used to update hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices. For example, a patient care device can be coupled to a computing device (in some embodiments, a personal computer, or any device that can be used in a similar manner to a personal computer, such as a tablet, for example) by a bus converter that converts RS232 format data to, for example, I2C format data, for example. In some embodiments, the processors in the hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices may perform update programs and control or organize the download of software into flash memory by, for example, a supervisor processor and / or command processor. In some embodiments, the computing device may organize the download of software into the flash memory of the hubs, docks, devices, insulin pumps, infusion pumps, and / or patient care devices. The software update obtained by the computing device can be sent into flash memory (not shown) accessible by the supervisor processor and / or command processor. In some embodiments, the above software update may be a command-line program that can be automatically invoked by a script process.

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

[0339] In some embodiments, the charging station may include a charging area for a hub, dock, device, insulin pump, infusion pump, and / or patient care device to a remote interface which may have a USB plug. In some embodiments, the charging station may have a USB port, and in some embodiments, a mini-USB port, thereby allowing the charging station to receive power to charge the hub, dock, device, insulin pump, infusion pump, patient care device, and / or remote interface via USB, in some embodiments. In addition, and / or alternatively, the USB port may be configured for data transfer to and from the remote interface, and / or the hub, dock, device, insulin pump, infusion pump, and / or patient care device, by connection to a computer or other device, and / or computer-type apparatus. In embodiments including a USB port, while the remote interface is charging, the system may call a personal computer and / or web portal to check for the availability of update software, and if there is any update software available, download the software update, for example, via the USB connection. These updates can then be transferred to the hub, dock, device, insulin pump, infusion pump, and / or patient care device during pairing.

[0340] Therefore, the user can connect the remote interface of the hub, dock, device, insulin pump, infusion pump, and / or patient care device to a personal computer and / or, in some embodiments, upload data from the remote interface to a web portal, etc. In some embodiments, this may be achieved during “recharging” of the remote interface, which in some embodiments may be done using a USB connection to the personal computer, which, in addition to charging / recharging the remote interface, may also synchronize and / or upload / download data from the personal computer, 1908, and / or web portal. At this time, the system can determine if software updates are available for one or more devices and / or the remote interface. The user can select “download updates,” and these updates can be downloaded to the remote interface of the hub, dock, device, insulin pump, infusion pump, and / or patient care device when charging and / or when the remote interface is directly or indirectly connected to the personal computer and / or a web portal specifically designed for that system. As described above, the remote interface has the ability to communicate with various devices. Therefore, software updates can be communicated to any one or more devices via a remote interface. This has many advantages, including, but is not limited to, the ability to upload data / information from all devices and / or download updates and / or applications from a personal computer and / or from the internet / web portal to any device, all of which only requires connecting the remote interface to a personal computer / web portal.This could be desirable for many reasons, including, but are not limited to, the ability to efficiently and easily update all devices from a single connection, and / or to view all data from all devices in one place, and / or to download information and / or settings to any device from a personal computer / web portal via a remote interface.

[0341] Therefore, in some embodiments, since the personal computer / web portal contains all information from all devices, including, but not limited to, remote interfaces, a new “remote interface” can be introduced into the system at any time. This can be achieved by connecting the new remote interface to the personal computer / web portal and downloading all information about the system to the remote interface. In some embodiments, this may first require removing the old remote interface from the “authenticated device,” while in other embodiments, the system can “authorize” additional remote interfaces with permission from the user. Thus, the system has the ability to download all information and applications to any internet connection and / or remote interface that is capable of communicating with the device and / or connecting the personal computer and / or web portal.

[0342] Furthermore, this allows the remote interface to download any application from the internet to any device within the system. Thus, in various embodiments of the system, the user can transform any device (including several parameters such as the ability to wirelessly connect to and connect to a personal computer and / or a web portal) into a device capable of controlling and / or receiving data from various devices, such as infusion pumps and / or CGM sensors / transceivers and / or other specimen sensors and / or other devices such as hubs, docks, 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 protected by a password or the like and paired with one or more devices, such as infusion pumps and / or CGM sensors and / or one or more other devices.

[0343] In some embodiments, information on a remote interface may be uploaded and / or synchronized with another device and / or computer and / or machine, and data may be uploaded to, for example, an internet site (web portal) which may be password protected, for example. Thus, a user can access the information from any device and / or download information including any device-specific application to any device, and thus, user information including, but not limited to, history, preferred settings, etc., can be downloaded to any device.

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

[0345] Action 602 establishes a communication link between the patient care device and the monitoring server. Action 604 communicates patient care parameters to the monitoring server, for example, via Wi-Fi over a local area network and / or the internet, through a monitoring client, one or more hubs or docks, etc. Action 606 de-identifies the patient care parameters. Action 606 can be done automatically and electronically within the monitoring server 3, for example, in Figures 1, 3, 5, 7, 8 and / or 9. For example, the patient's name may be removed and replaced with a random serial number or other identifier that cannot be used to determine the patient's identification information within the monitoring server. Action 608 stores the de-identified patient care parameters in a database within the monitoring server, for example, an SQL database, relational database, associative database, cloud server, etc.

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

[0347] Action 703 establishes a communication link between a monitoring server, e.g., monitoring server 3 in Figures 1, 3, 5, 7, 8, or 9, and multiple patient care devices associated with multiple patients. Optionally, multiple patient care devices may be associated with a single patient, and / or multiple patient care devices may be associated with different patients.

[0348] Action 705 communicates multiple patient care parameters from multiple patient care devices to a monitoring server. Action 707 de-identifies the patient care parameters, and Action 709 stores these patient care parameters in a database on the monitoring server, such as an SQL database, relational database, or associative database. Action 707 can be performed automatically and / or electronically. Action 711 treats a subset of patients from among multiple patients. For example, a patient with hypertension may be treated with medication designated to lower blood pressure. Action 713 analyzes a subset of multiple patient care parameters associated with multiple patients to determine the effectiveness of the treatment. For example, all patients who received the blood pressure medication in Action 711 may have their blood pressure compared to blood pressure readings at a predetermined time, for example, 6 months later, to determine whether the treatment was effective for one or more patients.

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

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

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

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

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

[0354] Action 815 determines that the operation of the patient care device has been interrupted, for example, that power to the patient care device has been lost, that the patient care device has malfunctioned, or that a voltage drop CPU reset has occurred. Action 817 determines that the operation of the patient care device can be resumed.

[0355] Action 819 loads one or more received or calculated operating parameters into the operating memory of the patient care device, and action 821 loads one or more patient care parameters into the operating memory of the patient care device. Action 823 restarts the operation of the patient care device.

[0356] Referring next to Figure 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. Method 900 includes actions 902 to 912. The monitoring client of Method 900 may be monitoring client 1 in Figures 1, 3, 5, 7, or 8, or remote communicator 11, monitoring client 902 in Figure 9, remote communicator 11 in Figures 1, 3, 5, 7, 8, or 9, a mobile phone, a handheld computer, a tablet computer, a laptop computer, a personal computer, a personal digital assistant, etc. Although Method 900 describes pairing between a monitoring client and a patient care device, in some embodiments, Method 900 is used to pair a hub (e.g., hub 802 in Figure 8) with a patient care device (e.g., patient care devices 830, 810, 812, and 814), and to pair a first patient care device (e.g., patient care device 830 in Figure 8) with a second patient care device (e.g., patient care device 814 in Figure 8), thereby enabling the user interface of the first patient care device to connect to the second patient care device. It can be used to control the system and / or pair the system monitor (e.g., system monitor 131 in Figures 1, 3, 5, 7, 8 or 9) with the patient care device (e.g., patient care devices 7, 170, 126, 128, 148, 14, 15, 16, 17 or 170 as shown in Figures 1, 3, 5 and 7, or patient care devices 830, 810, 812, 814, 14, 15, 16, 17 or 148 in Figure 8, and / or patient care devices 904, 906, 908, 14, 15, 16, 17 or 148 in Figure 9).

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

[0358] Act 908 pairs the patient care device with the monitoring client. For example, pairing the patient care device with the monitoring client can utilize Bluetooth, Bluetooth Low Energy (IEEE 802.15.1), Wi-Fi, infrared communication, near-field communication (NFC ISO 13157), IR communication, or optical methods. As will be apparent in light of this disclosure, a custom pairing protocol may also be used, which may or may not utilize a handshake sequence. Act 910 communicates patient care parameters between the patient care device and the monitoring client, which may, for example, allow the monitoring client to control or monitor the patient care device.

[0359] Act 912 optionally enables the operational communication of additional patient care parameters of another patient care device through the patient care device. In Act 912, if the patient care device is operationally coupled to or operationally communicates with another patient care device, the patient care device can act as a relay or router, thereby enabling the monitoring client to communicate with the other patient care device. In addition to or alternatively, the patient care device can use information from another patient care device for its operation; for example, an infusion pump can use the flow rate determined by a flow meter or the temperature from a temperature probe, and / or the infusion pump can relay information from the flow meter to the monitoring client. In addition, the monitoring client can optionally communicate with a number of patient care devices coupled to a paired patient care device, either in parallel or in series. In addition to or alternatively, in some embodiments of the present disclosure, in Method 900, the monitoring client communicates with the patient care device using an intravenous tube. The communication may be performed by using electrical conductors embedded in or attached to the venous tube, by using electrical communication using the fluid in the venous tube as a conductive medium, by using sound waves traveling through the venous tube, or optically using the fluid in the tube as an optical waveguide. The communication via the venous tube may be used to establish pairing with another communication link, such as Bluetooth, Bluetooth Low Energy, WiFi, etc. (for example, between a monitoring client, hub, dock, patient care device and / or a system monitor comprising one or more monitoring clients, hub, dock, patient care device and / or system monitors).

[0360] In further embodiments of this disclosure, pairing from a first device (e.g., a monitoring client, hub, patient care device, or system monitor) to a second device (e.g., a monitoring client, hub, patient care device, or system monitor) may be configured and / or initialized using a first communication link, thereby allowing these devices to pair using a second communication link. For example, near-field communication or IR communication may be used to set up pairing between these devices, e.g., using Bluetooth, Bluetooth Low Energy, or WiFi. The pairing setup (e.g., via near-field communication or IR communication) can prompt a request to the monitoring client, hub, patient care device, and / or system to monitor for user confirmation of device pairing, e.g., pairing via Bluetooth. In some embodiments, once a patient care device is paired with a hub, monitoring client, and / or dock, an ID and software version number are sent to the hub, monitoring client, and / or dock, which then check a server, e.g., monitoring server 3, middleware, cloud server, or other server to determine if the software on the patient care device is up to date. If the software is not up to date, the hub, monitoring client, dock, or the patient care device itself (e.g., directly) can download the update software and program the patient care device. The patient care device can notify the user whether the software is up to date and / or give the user an option on the touchscreen to optionally update the patient care device if the software is not up to date. The communication link used to set up pairing (e.g., NFC) and / or the communication link used for pairing (e.g., Bluetooth or Bluetooth Low Energy) can communicate the update software, ID, software version number, and provide notifications, etc.For example, one pairing that can be used with a pump patient care device or insulin pump can be found in (1) Patent Application No. 12 / 731,843, filed March 25, 2010, entitled “Infusion Pump Method and System” (Agent Reference Number: I06), (2) Patent Application No. 12 / 416,662, filed April 4, 2009, entitled “Method and System for Controlling an Infusion Pump” (Agent Reference Number: G98), and / or (3) Patent Application No. 12 / 347,985, filed December 31, 2009, entitled “Infusion Pump Assembly” (Agent Reference Number: G75), all three of which are incorporated herein by reference in whole.

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

[0362] The wearable system monitor of Method 1000 may be the wearable system monitor 131 shown in Figures 1, 3, 5, 7, 8, and 9. Pairing the system monitor of Method 1000 for monitoring one or more patient care devices can be done using one or more of the devices 1002 to 1012, or any sufficient number of the devices disclosed herein. For example, the wearable system monitor of Method 1000 can be paired with a patient care device using the user interface of monitoring device 1002, the user interface of remote communicator 1004, the user interface of communication device 1006, the user interface of patient care device 1008, the user interface of another patient care device 1010, or the user interface of wearable system monitor 1012.

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

[0364] The system monitor of Method 1000 can be used in System 100 in Figure 1, System 300 in Figure 3, System 500 in Figure 5, System 700 in Figure 7, System 800 in Figure 8, and System 900 in Figure 9, and can be used in a standalone system and / or in any other sufficient system or group of devices disclosed herein.

[0365] Action 1014 identifies the caregiver (e.g., provider) using one or more of the following: voice recognition algorithm, facial recognition algorithm, barcode, RFID tag, near-field communication, simple login, secure signature, etc. For example, the identification of the caregiver in Action 1040 can be performed by a monitoring client, monitoring client docking station, device docking station, communication module, or other dock or hub using an onboard camera and / or microphone. Also, as a safety check, the monitoring client, hub, dock, or patient care device may require the user to input using the font as displayed to prevent font corruption errors. In addition, or alternatively, in some embodiments, if the device takes a photograph and stores that photograph after one or more login or authentication failures, that photograph may be transmitted to a middleware server for storage. Action 1016 records the presence of the caregiver in one or more of the devices 1002-1012. Log entries may be stored in any one of the following: devices 1002-1012, patient care devices as described herein, monitoring clients as described herein, wearable system monitors as described herein, remote communicators as described herein, and / or hubs as described herein. The logging of action 1016 may be for purposes such as caregiver compliance or diagnostic purposes. For example, if a caregiver is scheduled to appear but does not, action 1016 may record that the caregiver did not appear at the scheduled time.

[0366] The facial recognition algorithm of action 1014 can relay any caregiver's facial features, such as relative body size, shape, position of eyes, nose, chin, cheekbones, or other facial features. The facial recognition algorithm of action 1014 may use 3D facial recognition, skin texture analysis, or other facial recognition algorithms. In addition, or alternatively, in some embodiments, the speech recognition algorithm of action 1014 may use a hidden Markov model, dynamic time warping-based speech recognition, or other speech recognition algorithm(s).

[0367] Action 1018 removes the wearable system monitor from the wearable dock. For example, the system monitor 131 in Figure 1 can be worn on the patient's arm, similar to how a wristband on a watch is attached to the patient, and a portion of the wearable system monitor can be removed from the wristband and the dock (also referred to herein as the “wearable dock”) which has a snap-fit ​​base member into which the wearable system monitor snaps. Once the wearable system monitor is removed from its dock, action 1020 starts the timer. The timer and associated actions are optional in method 1000 in Figure 14.

[0368] The timer in action 1020 tracks the elapsed time the wearable system monitor is outside its dock. Action 1022 stops treatment after a predetermined time has elapsed since the wearable system monitor was undocked from the wearable dock. For example, the wearable system monitor in method 1000 can signal the infusion pump to stop pump infusion. When the wearable system monitor is docked again, action 1024 resumes treatment after a predetermined time has elapsed, for example, if treatment was interrupted because the wearable system monitor was undocked from its wearable dock.

[0369] As described above, action 1018 removes the wearable system monitor from the wearable dock. Action 1026 identifies the patient using one or more of the following: for example, a voice recognition algorithm, a facial recognition algorithm, a barcode, an RFID tag, near-field communication, simple login, or caregiver input. Action 1026 may be similar to action 1014, may use the same software used in action 1014, and / or may use one of devices 1002-1020. However, it should be noted that in some embodiments, the patient identification procedure may include more than the caregiver identification information, for example, by using biometric authentication or other identifying patient-specific information. Such patient identification criteria can be used to ensure that a particular treatment is given to the correct patient and / or to provide compliance with a given rule. Actions 1014 and / or 1026 may be performed using a passkey device on the patient and / or caregiver.

[0370] Action 1028 determines whether the caregiver is authorized to pair the wearable system monitor, for example, to pair the wearable system monitor with a patient care device. If the caregiver is not authorized, method 1000 prevents additional pairing (or editing of pairing settings) of the wearable system monitor. If the caregiver is authorized to pair the wearable system monitor, action 1030 allows the caregiver to select one or more patient care devices to pair with the wearable system monitor. Caregiver authorization can be used, for example, to ensure that specific treatments are given to the correct patients and / or to provide compliance with given rules.

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

[0372] Act 1036 reattaches the wearable system monitor to the wearable dock. Act 1038 uses the wearable system monitor to identify and authenticate docking to the wearable dock to determine, for example, whether the wearable system monitor and the wearable dock are authorized to dock with each other. For example, Act 1038 can ensure that the wearable system monitor is docked to the correct patient's wearable dock. For example, if the wearable system monitor is docked to the wrong patient's wearable dock, the wearable system monitor can recognize the error and (in some embodiments) prevent associated treatment from proceeding by sending a signal to the patient care device associated with the wrong patient to stop operation, and can send an alert to a monitoring client, e.g., monitoring clients 1, 4, or 11 in Figures 1, 3, 5, 7, 8, monitoring clients 9, 4, or 11 in Figure 9, or other monitoring clients disclosed herein. Action 1024 allows treatment to be resumed if treatment has been interrupted, or action 1040 allows treatment of the patient according to any update setting 1040.

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

[0374] Figure 15 is a flowchart of Method 1100 for displaying a user interface using a user interface template, according to embodiments of the present disclosure. Method 1100 includes actions 1102-1132. In some embodiments, each of actions 1102-1132 is optional.

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

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

[0377] Act 1102 identifies or selects a patient care device in order to communicate with a monitoring client having a user interface. For example, in Act 1102, the monitoring client can automatically identify a predetermined infusion pump previously designated by the provider for the treatment of the patient. In addition to or alternatively, in Act 1102, the provider may be given a list of patient care devices to select from in order to display information about the operation of the selected patient care device(s) on the monitoring client's user interface.

[0378] Action 1104 determines whether the patient care device has a stored user interface template. For example, an infusion pump may have flash memory in which a user interface template is stored. If the patient care device has a stored user interface template, action 1106 communicates the stored user interface template from the patient care device to a monitoring client that has a user interface. Action 1108 displays the user interface template on the monitoring client's user interface. Action 1110 communicates patient care parameters between the patient care device and the monitoring client. Action 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 space for the current infusion rate, and in this embodiment, action 1112 uses the user interface template to display the current infusion rate (patient care parameter) on the display.

[0379] If action 1104 determines that the patient care device does not have a stored user interface template, method 1100 determines whether the monitoring client has a user interface template that it uses to display patient care parameters of the patient care device. In addition to or alternatively, action 1104 may issue an alarm via the monitoring client and / or the patient care device. Action 1114 determines the type of patient care device. If the type is determined, action 1116 determines whether a user interface template is stored in the monitoring client according to the type of patient care device. If a user interface template exists, action 1118 displays the user interface template on the monitoring client's user interface. Action 1120 communicates patient care parameters between the patient care device and the monitoring client. Action 1122 displays the patient care parameters on the displayed user interface template according to the user interface template. For example, patient care parameters such as infusion rate may be displayed in a predetermined area of ​​the user interface specified by the user interface template.

[0380] If the type is not determined in action 1114, or if a user interface template is not placed in the monitoring client based on the determined type, action 1124 displays a selectable list of multiple user interface templates on the monitoring client's user interface, and in addition to or alternatively, action 1114 can issue an alarm or alert via the monitoring client and / or patient care device. Action 1126 allows the user to select a user interface template from multiple user interface templates using the monitoring client's user interface. Action 1128 displays the user interface template on the monitoring client's user interface. Action 1130 communicates patient care parameters between the patient care device and the monitoring client. Action 1132 displays the patient care parameters on the displayed user interface template according to the user interface template.

[0381] In some embodiments of the present disclosure, the patient care device of Method 1100 may also store one or more fonts for display on a monitoring client, for example, using the user interface template described above. The fonts may be stored in any format such as JPEG, BMP, image format, or pre-stored font, and may be transmitted for use within a region to provide a display of operational parameters (for example, an image showing a number or value is transmitted rather than a value is transmitted, and then it is displayed on the monitoring client). In some embodiments, a font stored within the monitoring client may be used, thereby sending the value of an operational parameter to the monitoring client and displaying it in the template using the font stored within the monitoring client.

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

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

[0384] Action 1136 docks the patient care device into the dock. For example, infusion device 7 in Figures 1, 3, 5, or 7, infusion devices 830, 810, or 812 in Figure 8, or infusion device 904 in Figure 9 can be docked into their respective docks. In Action 1138, the monitoring client identifies the patient care device. For example, the patient care device can communicate to the monitoring client, for example, by a discovery protocol, information such as an ID number, serial number, description, prescription, treatment plan, and patient treatment parameters. The docked patient care device may store treatment information (e.g., drug dosage, infusion rate, total fluid volume, or other patient treatment parameters), each of which may be associated with or correspond to a patient.

[0385] In action 1140, the monitoring client queries the server for an application to control a patient care device (e.g., to set the infusion rate). In action 1142, the monitoring client downloads the application. Communication between the monitoring client and the server may be encrypted. For example, the server may encrypt the application before sending it to the monitoring client, and the monitoring client can decrypt the application using a sufficient encryption key. In addition to this, or alternatively, all communication may be encrypted. During action 1144, the monitoring client runs the application. In action 1146, the monitoring client is coupled to the patient care device in a communicative and operable manner through the application by running the application on one or more processors. The monitoring client may place the application in a sandbox (as described below). In one such embodiment, the application includes an operable set of processor-executable instructions configured to run on one or more processors on the monitoring client. The application may include instructions for displaying a user interface on the monitoring client's display, for example, using the user interface template of method 1100 in Figure 15. In addition, or alternatively, in some embodiments, the application can be used to control the patient care device by optionally transmitting parameters or numerical values ​​to the patient care device, such as bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, delivery flow rate profile, pill distribution instructions for distributing pills, pill type, pill distribution schedule, and / or maximum pill distribution criteria.

[0386] Figure 17 is a flowchart of Method 1200, according to embodiments of the present disclosure, for ensuring data integrity when communicating data (e.g., requests) for a patient care device. Method 1200 includes actions 1202-1222. In some embodiments, each action 1202-1222 is optional. The patient care device of Method 1200 may be any patient care device disclosed herein, for example, patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 in Figures 1, 3, 5, or 7, patient care devices 14, 15, 16, 17, 830, 810, 812, 814 in Figure 8, patient care devices 14, 15, 16, 17, 904, 906, 908 in Figure 9, or other patient care devices disclosed herein.

[0387] The request may optionally be made from any authorized, authenticated, and / or identified monitoring client, such as monitoring client 1 or 4 in Figures 1, 3, 5, 7, or 8, remote communicator 11 in Figures 1, 3, 5, 7, 8, or 9, a mobile phone, handheld computer, tablet computer, laptop computer, personal computer, or personal digital assistant.

[0388] Action 1202 presents a request to the patient care device using the user interface of the monitoring client. For example, using the touchscreen of monitoring client 1 in Figure 1, the user presents the infusion rate to the infusion pump 7. In some embodiments, the request may optionally be parameters related to the patient care device, such as bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, delivery flow rate profile, pill distribution instructions for distributing pills, pill type, pill distribution schedule, and / or maximum pill distribution criteria.

[0389] Action 1204 is optional and displays a "Pending Request" on the monitoring client's user interface. Action 1206 formats the request for the patient care device. For example, action 1206 can prepare the request to meet the communication requirements of the patient care device.

[0390] Act 1208 determines the check value for the request. For example, a periodic redundancy check algorithm is used to determine the check value corresponding to the request. The check value calculated by the periodic redundancy check algorithm is request-dependent. A one-bit change in the request also changes the check value calculated by the periodic redundancy check algorithm. Similarly, a change of several bits also changes the check value. In addition to or as an alternative, in other embodiments, a parity bit (even or odd) or other data integrity checks may be used.

[0391] Action 1210 adds a check value to the request. Action 1212 is optional and requests confirmation from the user to communicate the request using the user interface. The request for confirmation may be a pop-up dialog box on a touchscreen displaying "Have you confirmed a 90 ml / hour injection rate?" with a box for selecting "Confirm". The text and formatting shown in Action 1212 may be in a different font, a different font size, and / or a different display position to provide additional safeguards against poor display pixels, corrupted font tables, user misunderstanding, etc., for example, other display information displayed or otherwise displayed during request input. Action 1214 confirms the request and communicates that request using the user interface. The user can confirm the request to communicate that request by touching the "Confirm" box according to some embodiments of the present disclosure. 【039...

Claims

1. A system for electronic patient care, A first medical sensor connected to a patient and configured to measure the patient's first physiological parameters; A second medical sensor connected to the patient and configured to measure the patient's second physiological parameter; and A medical device configured to operably receive the first and second physiological parameters measured from the first and second medical sensors, A first pattern is detected using the first physiological parameter measured above; The second pattern is detected using the measured second physiological parameter. ; and If the first and second patterns are detected within a predetermined time interval from the time when the other pattern is detected, it is determined that a medical condition exists. A medical device configured in such a way, A system equipped with this feature.

2. The system according to claim 1, wherein the medical device is configured to detect the first and second patterns without considering the magnitude of the measured first and second physiological parameters.

3. The system according to claim 1, wherein the medical device is configured to detect the first and second patterns without considering the initial values ​​of the measured first and second physiological parameters.

4. The system according to claim 1, wherein the first pattern is a tendency.

5. The system according to claim 4, wherein the medical device is configured to detect the first pattern without considering the initial values ​​of the measured first physiological parameters.

6. The system according to claim 4, wherein the second pattern is the second tendency.

7. A system for electronic patient care, A first medical sensor connected to a patient and configured to measure the patient's first physiological parameters; A second medical sensor connected to the patient and configured to measure the patient's second physiological parameter; and A medical device configured to operably receive the measured first and second physiological parameters from the first and second medical sensors and to communicate the measured first and second physiological parameters; and A server that communicates with the aforementioned medical device in an operable manner, A first pattern is detected using the first physiological parameter measured above; The second pattern is detected using the measured second physiological parameter. ; and When the first and second patterns are detected within a predetermined time interval from the time when the other pattern is detected, it is determined that a medical condition exists. Servers configured in such a way, A system equipped with this feature.

8. The system according to claim 7, wherein the server is configured to detect the first and second patterns without considering the magnitude of the measured first and second physiological parameters.

9. The system according to claim 7, wherein the server is configured to detect the first and second patterns without considering the initial values ​​of the measured first and second physiological parameters.

10. The system according to claim 7, wherein the first pattern is a tendency.

11. The system according to claim 10, wherein the server is configured to detect the first pattern without considering the initial values ​​of the measured first physiological parameters.

12. The system according to claim 10, wherein the second pattern is the second tendency.

Images