Systems, methods and devices for electronic patient care

Abstract

A system for electronic patient care is provided having a hub configured to monitor patient-care devices. The electronic patient care system (100) includes one or more monitoring clients (1, 4), each of which can be assigned to be in physical proximity to an individual patient (2), and a remote monitoring server (3) that uploads information from several different monitoring clients (1, 4) and downloads information and instructions from various sources to the monitoring clients (1, 4). When in the patient's room, a healthcare provider can interact directly with the monitoring client (1) to obtain information about or enter instructions regarding the patient (2). Multiple monitoring clients 1 can interact with a single monitoring server 3. The monitoring server 3 can comprise middleware.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation-in-part of U.S. Provisional Patent Application No. 13 / 011,543, entitled Electronic Patient Monitoring System, filed on January 21, 2011 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled Electronic Order Intermediation System for Medical Equipment, filed on January 22, 2010 (Attorney Docket No. H53), both of which are incorporated herein by reference in their entireties.

[0002] The present disclosure relates to patient care. More particularly, the present disclosure relates to systems, methods, and devices for electronic patient care. [Background technology]

[0003] Providing patient care in a hospital typically requires the interaction of many professionals and caregivers (e.g., physicians, nurses, pharmacists, technicians, nurse practitioners, etc.) and any number of medical devices / systems necessary to treat a given patient. Summary of the Invention [Problem to be solved by the invention]

[0004] Despite the existence of systems intended to facilitate the care process, such as those incorporating electronic medical records (EMRs) and computerized provider order entry (CPOE), the process of providing comprehensive care to patients, including ordering and delivering care such as medications, is associated with several significant issues. [Means for solving the problem]

[0005] In an exemplary embodiment related to medication prescription and administration, the electronic patient care system may include a first data collection module (e.g., a monitoring client), a second prescription input module (e.g., a fixed or portable monitoring client) having a user interface for communicating prescriptions or receiving patient-related information. The first module may be configured to receive and store measured parameters related to the patient's current condition (e.g., patient status parameters), such as blood pressure, heart rate, cardiac rhythm, temperature, oxygenation, respiratory rate, or ventilation. The first module may also be configured to receive information about existing parameters related to the patient from a first database (e.g., an EHR database containing information about the patient), including, for example, patient status parameters such as drug allergies or hypersensitivities, other currently administered medications present in the patient's tissue, age, weight, height, renal, or liver function. The first module may also be configured to obtain drug information about the prescribed medication and / or existing medications from a second database (e.g., a drug information database), such as, for example, known drug interactions, drug effects, or existing medications on blood pressure, pulse, cardiac rhythm, or respiration. The first module may be configured to compare the patient's currently measured and received existing patient condition parameters to known normal ranges and create a table of patient condition parameters found to be outside of the normal range. The first module may then compare the table of patient condition parameters to a table of corresponding parameters obtained from the drug information database. If a match is found to exist between the table of patient condition parameters and the table of corresponding parameters, the first module may then retrieve one or more pre-entered and stored messages for communication to the second (instruction input) module. These messages may include, for example, alerts to the user of the second module appropriate to the particular medication prescribed, the patient's existing medications, and the patient's current and existing medical conditions.Optionally, if the alert is received by the second module and the alert is acknowledged by a user of the second module through an input signal from a user interface, further repetition of the alert can be avoided.

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

[0007] In other embodiments, the first module or other modules of the electronic patient-care system may also be used to identify the prescribed medication to be delivered to the patient's bedside (e.g., through a bar code and reader, or an RFID tag and scanner) and to verify that the proper medication and dosage is prepared and delivered to the patient. In embodiments, the first module may also interact with the patient-care device administering the therapy, such as an infusion pump or pill dispenser, through a wired or wireless communication link. In the case of an infusion pump, the first module or another connectivity module may provide the infusion pump with patient treatment parameters, such as infusion settings, including infusion rate or infusion pressure, and receive therefrom various operational parameters, such as, for example, the presence of air in the infusion line, the amount of solution remaining in a connected intravenous bag, or the pressure of the fluid in the infusion line. If the operational parameters are found to be abnormal, the first module may be configured to respond by sending a signal to the infusion pump to interrupt the infusion, to respond by signaling a mechanical occlusion to occlude the venous line, to modify the infusion rate, and / or to alert a healthcare provider or the like of the abnormality, either directly by an alarm built into the first module or by communicating an alarm to the second module. In another embodiment, the first module can also be configured to communicate with various patient-care devices used to monitor the patient's condition and determine patient condition parameters, such as, for example, blood pressure monitors, ECG monitors, pulse oximetry monitors, temperature monitors, etc. 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 can be programmed to alert the patient or others if the monitored patient condition parameter is outside of a predetermined range. In some embodiments, the first module can communicate a signal to a monitoring client to take a measurement not scheduled by the patient-care device to obtain another patient condition parameter.The first module can communicate with various healthcare providers in various locations and, in embodiments, the first module can inform an assigned patient of an abnormality and recommend corrective action, for example, via an audible alarm or a recorded message.

[0008] In one embodiment, a system for preparing a microinfusion pump includes a monitoring client, a pharmacy computer, a composite robot, a microinfusion pump, and a data download device. The monitoring client is configured to communicate a prescription instruction via a user interface. The pharmacy computer is in operative communication with the monitoring client to receive the prescription instruction. The composite robot is configured to prepare the prescription into at least one liquid corresponding to the prescription instruction. The microinfusion pump is configured to receive the at least one liquid corresponding to the prescription instruction. The data download device is configured to download the prescription instruction into a memory of the microinfusion pump.

[0009] In some embodiments, the multirobot fills the microinfusion pump with at least one liquid. The multirobot can be in operative communication with a data download device, and the multirobot can command the data download device to download the prescription instructions into the memory of the microinfusion pump. The data download device can receive the prescription instructions from the multirobot and / or the pharmacy computer. In some embodiments, the multirobot receives the prescription instructions from the pharmacy computer.

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

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

[0012] The hub may be further configured to control patient-care devices, such as an infusion pump, a pill dispenser, a microinfusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO 2 This may be one or more of a capnometer, an intravenous bag, and / or an IV flow meter.

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

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

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

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

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

[0018] Patient care devices may include infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters, and / or CO 2 It may be a capnometer, an intravenous bag, and an infusion flow meter.

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

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

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

[0022] Patient care devices may include infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters, and / or CO 2 It may be a capnometer, an intravenous bag, and an infusion flow meter.

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

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

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

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

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

[0028] In an embodiment, the monitoring client dock and the device dock are configured to communicate one way wirelessly and the other way through a cable operably coupled to the monitoring client dock and the device dock.

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

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

[0031] In another embodiment, the monitoring client operatively communicates at least one patient-care parameter using wireless communications with the monitoring-client dock when the monitoring client determines that communication over a cable is not available and / or the monitoring client is undocked from the monitoring-client dock.

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

[0033] In another embodiment, the monitoring client operatively communicates at least one patient-care parameter using wireless communications with the device dock when the monitoring client determines at least one of: communication over a cable is not available, communication between the monitoring client and the monitoring-client dock is not available, and the monitoring client is undocked from the monitoring-client dock.

[0034] In another embodiment, the patient-care device is configured to wirelessly communicate with the monitoring client, the monitoring client wirelessly communicating the at least one patient-care parameter with the patient-care device.

[0035] In another embodiment, the monitoring client operatively communicates at least one patient-care parameter wirelessly with the patient-care device when the monitoring client determines at least one of: communication over a cable is not available, communication between the monitoring client and the monitoring-client dock is not available, communication between the device dock and the patient-care device is not available, and the monitoring client is undocked from the monitoring-client dock.

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

[0037] In another embodiment, the monitoring client is configured to communicate with the patient-care devices over a plurality of communication links, and the monitoring client communicates over an operable one of the plurality of communication links.

[0038] In another embodiment, the patient care device is an infusion pump, a pill dispenser, a microinfusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO 2 a capnometer, an intravenous bag, and an IV flow meter.

[0039] In another embodiment, the patient care parameter is an intravenous pump flow parameter, an ECG parameter, a blood pressure parameter, a pulse oximeter parameter, a CO 2 The patient care parameter may be a patient condition parameter, and / or a patient treatment parameter, the patient condition parameter being at least one of a capnometer parameter, an intravenous bag parameter, and an IV flow meter value.

[0040] In another embodiment, the patient-care devices are configured to communicate wirelessly as nodes in a mesh network.

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

[0042] In yet another embodiment, a system for electronic patient care includes 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 therewith and to receive the monitoring client for docking therewith.

[0043] In yet another embodiment, a system for electronic patient care includes 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 therewith, wherein the device dock and the monitoring client are integrated together.

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

[0045] In yet another embodiment, a system for electronic patient care includes 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 therewith. The hub can be plugged into the device dock to establish a communication link therebetween. The system can further include a monitoring client in operative communication with the hub to receive the at least one patient-care parameter. Patient treatment parameters can be operatively communicated with the hub, and the hub communicates the patient treatment parameters to the patient-care device.

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

[0047] 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 a patient-care device through the hub.

[0048] 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 prior to treating the patient.

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

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

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

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

[0053] At least one patient monitor includes an electrocardiogram monitor, a blood pressure monitor, a pulse oximeter monitor, and a CO 2The monitoring client may include at least one of a capnometer. The monitoring client may be configured to download the patient information according to a designated unique patient identifier. The unique patient identifier may be encoded within a barcode disposed on the wrist band. The unique patient identifier may be encoded on an RFID tag (e.g., an RFID interrogator) coupled to the wrist band. The patient information includes a patient condition or a patient care parameter. The unique patient identifier may be operatively transmitted to the monitoring server to obtain electronic authorization to communicate the patient-specific data. A subset of the patient-specific data may be stored within a memory of the monitoring client. The monitoring client is adapted to determine whether a new indication meets a predetermined criterion based on the subset of the patient-specific data stored within the memory.

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

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

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

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

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

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

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

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

[0062] In another embodiment, the monitoring server is adapted to format data from the multiple databases for downloading the data to the monitoring client. Optionally, and in some specific embodiments, the monitoring client can communicate at least one patient parameter to the monitoring server. In certain embodiments, the patient parameter can include infusion pump therapy progress, electrocardiogram signals, blood pressure signals, pulse oximeter signals, CO2 signals, and the like. 2 It may comprise one or more and / or at least one of a capnometer signal and / or a temperature signal.

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

[0064] The monitoring client can receive user requests to read patient parameters and can interrogate the monitoring device to receive patient parameters.

[0065] In another embodiment, the system can further include a portable monitoring client in operative communication with the monitoring client to communicate directly with the patient information, thereby bypassing the monitoring server. The portable monitoring client can be configured to modify at least one parameter of the infusion pump and communicate the at least one modified parameter to the monitoring server.

[0066] Changes to patient instructions presented via a portable monitoring client can be communicated to other portable monitoring clients.

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

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

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

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

[0071] The predetermined set of information may include at least one of the patient's age, height, weight, diagnosis, current medications, medication categories, medication allergies, and hypersensitivities.

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

[0073] In another embodiment, a method for electronic patient care includes displaying a plurality of patients on a display, displaying at least one patient parameter associated with a patient 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.

[0074] The method, in some particular embodiments, may further include transmitting the alert from the monitoring client to a portable remote communicator device having a display.

[0075] In yet another embodiment, an electronic patient-care system includes a monitoring client configured to communicate at least one patient-care parameter, a patient-care device configured to communicate the at least one patient-care parameter, and a communications interface configured to facilitate communications between the monitoring client and the at least one patient-care device by discovering the presence of the at least one patient-care device and translating communication signals from the device into a communications protocol associated with the monitoring client.

[0076] In certain embodiments, the communications interface is further configured to discover the presence of additional, distinct patient-care devices and convert communication signals from these devices to a communications protocol associated with the monitoring client.

[0077] In another particular embodiment, the communication interface is further configured to provide appropriate power to each device.In yet another particular embodiment, the system further comprises one or more databases accessible by the monitoring clients that enable at least one of central storage of patient information and / or downloaded information that can be used in the treatment of a patient associated with the monitoring client.

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

[0079] In yet another embodiment, an electronic patient-care system includes a hub client configured to communicate at least one patient-care parameter, a patient-care device configured to communicate at least one patient-care parameter, and a communications interface configured to facilitate communications between the hub and the at least one patient-care device by discovering the presence of the at least one patient-care device and translating communication signals from the device into a communications protocol associated with the hub.

[0080] In certain embodiments, the communications interface is further configured to discover the presence of additional, distinct patient-care devices and convert communication signals from the devices to a communications protocol associated with the hub.

[0081] In another particular embodiment, the communication interface is further configured to provide appropriate power to each device. In yet another particular embodiment, the system further comprises one or more databases accessible by the hub that enable at least one of central storage of patient information and / or download information that can be used in treating patients associated with the hub.

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

[0083] In yet another embodiment, an electronic patient-care system includes a dock configured to communicate at least one patient-care parameter, a patient-care device configured to communicate the at least one patient-care parameter, and a communications interface configured to facilitate communications between the dock and the at least one patient-care device by discovering the presence of the at least one patient-care device and translating communication signals from the device into a communications protocol associated with the dock.

[0084] In certain embodiments, the communications interface is further configured to discover the presence of additional, distinct patient-care devices and convert communication signals from the devices to a communications protocol associated with the dock.

[0085] In another particular embodiment, the communication interface is further configured to provide appropriate power for each device. In yet another particular embodiment, the system further comprises one or more databases accessible by the dock that enable at least one of central storage of patient information and / or download information that can be used in treating a patient associated with the dock.

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

[0087] In an embodiment, the patient-care device includes a body, a track within the body configured to receive a post, and two functional members coupled to the body and configured to functionally lock the body to the post within the track.

[0088] In some embodiments, the hub includes a patient-care device interface, a power source 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 configured to enable communication between the processor and the patient-care device. The processor, in some specific embodiments, can be configured to disable the patient-care device when an alarm condition occurs.

[0089] In some embodiments, the dock includes a patient-care device interface, a power source coupled to the patient-care device interface and configured to provide power to the patient-care device, a processor, and a transceiver coupled to the patient-care device interface configured to enable communication between the processor and the patient-care device. The processor, in some specific embodiments, can be configured to disable the patient-care device when an alarm condition occurs.

[0090] In some embodiments, the communication module includes a patient-care device interface, a power source coupled to the patient-care device interface and configured to provide power to the patient-care device, a processor, and a transceiver coupled to the patient-care device interface configured to enable communication to the patient-care device and to another device. The processor, in some specific embodiments, can be configured to disable the patient-care device when an alarm condition occurs.

[0091] In another embodiment, a patient-care system includes a dock, a plurality of modular patient-care devices configured to dock with the dock, and a monitoring client retractable display, The modular patient-care devices can interface with the dock along a horizontal plane, either staggered or via connectors.

[0092] In yet another embodiment, an electronic patient care system comprises a first module configured to receive and store information regarding a patient, the information including data related to a first parameter of the patient measured by a device connected to the patient and data related to a second parameter of the patient received from a first database containing information regarding the patient; and a second module configured to receive a medication order from a user via a user interface associated with the second module and further configured to communicate the treatment order to the first module, the first module being further configured to a) obtain medication information regarding the medication or other drug from the second database, the medication information including data providing limits within which such medication is normally administered; b) determine whether the medication order should be confirmed by the second module based on the medication information, the value of the first parameter, and the value of the second parameter; and c) communicate a pre-established message confirming the acceptability of the medication order or warning thereabout from the first module to the second module for display on the user interface.

[0093] The 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 parameter or second parameter includes data regarding the patient's currently administered medication, known drug allergies, current blood pressure, current heart rate, current cardiac rhythm, current respiratory rate, or current ventilation.

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

[0095] The first module can be configured to generate a signal that the medication order or modified medication order is processed upon receiving a confirmation signal from the second module triggered by an input signal from the user interface after the pre-established message has been communicated.

[0096] 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 with the dock, the patient-care device and the dock are paired using the first communication link, and after pairing, remain in communication using the second communication link. The pairing that occurs using the first communication link can pair the patient-care device and the dock to the second communication link. The first communication link can be a short-range wireless communication, and the second communication link can be Bluetooth, Bluetooth low energy, WiFi, or other communication link.

[0097] In another embodiment, the patient-care device includes a first communication link and a second communication link, and the monitoring client includes a first communication link and a second communication link. When the patient-care device is within a predetermined range with the monitoring client, the patient-care device and the monitoring client are paired using the first communication link and remain in communication using the second communication link after pairing. The pairing that occurs using the first communication link can pair the patient-care device and the monitoring client to the second communication link. The first communication link can be a short-range wireless communication, and the second communication link can be Bluetooth, Bluetooth low energy, WiFi, or other communication link.

[0098] In some embodiments, the patient-care device includes a memory having a user interface template stored therein that can be communicated to the dock, hub, and / or monitoring client for display on a user interface of the dock, hub, and / or monitoring client. The user interface template can be configured to display one or more patient-care parameters received from a patient-care device (eg, in real-time).

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

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

[0101] In yet another embodiment, a wearable system monitor includes a watchdog component and a transceiver. The wearable system monitor can include a processor coupled to the watchdog component and the transceiver for performing a watchdog function for at least one paired device. The paired device can be at least one of a dock, a hub, a monitoring client, and / or a patient-care device.

[0102] In yet another embodiment, the method includes one or more of the steps of establishing a communication link between the patient-care device and the monitoring server, communicating the 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.

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

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

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

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

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

[0108] In yet another embodiment, a method includes steps of docking a patient-care device into a dock, identifying the patient-care device, querying a server for an application for controlling the patient-care device, downloading the application into the dock, 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.

[0109] In yet another embodiment, a method includes placing a patient-care device in operative communication with a hub, the hub can identify the patient-care device, can query a server for an application for controlling the patient-care device, can download the application into the hub, can execute the application, and can control the patient-care device using the application.

[0110] In yet another embodiment, a method includes placing a patient-care device in operative communication with a dock, where the dock can identify the patient-care device, can query a server for an application for controlling the patient-care device, can download the application into the dock, can execute the application, and can control the patient-care device using the application.

[0111] In yet another embodiment, a method includes placing a patient-care device in operative communication with a monitoring client, the monitoring client capable of identifying the patient-care device, querying a server for an application for controlling the patient-care device, downloading the application to the monitoring client, executing the application, and controlling the patient-care device using the application.

[0112] In yet another embodiment, the method may include the steps of presenting a request on a user interface of a communication device, verifying the request, sending the request, receiving the request with a check value, and verifying that the check value is in accordance with the request prior to sending.

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

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

[0115] In another embodiment, the hub is adapted to connect to the cradle for controlling one or more patient-care devices coupled to the cradle.

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

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

[0118] In yet another embodiment, an electronic patient-care system includes a monitoring client and a dock configured to couple to the post. An adapter can be coupled to the dock. The adapter can include at least one electronic coupler to place the patient-care device in operative communication with the monitoring client. The patient-care device can slide into the adapter.

[0119] In yet another embodiment, an electronic patient-care system includes a monitoring client, a patient-care device, and a communications module, wherein the patient-care device and / or the communications module are fault-tolerant of the monitoring client, e.g., the monitoring client cannot instruct the patient-care device to perform an unsafe operation.

[0120] These and other aspects will become more apparent from the following detailed description of various embodiments of the present disclosure, taken in conjunction with the drawings. [Brief description of the drawings]

[0121] [Figure 1] FIG. 1 is a block diagram of an electronic patient-care system having two docks according to an embodiment of the present disclosure. [Diagram 2]2 is a flow chart diagram illustrating a method for maintaining communication between the monitoring client and the patient-care device of FIG. 1 according to an embodiment of the present disclosure. [Diagram 3] FIG. 13 is a block diagram of an electronic patient-care system having two docks for wireless communication therebetween in accordance with another embodiment of the present disclosure. [Figure 4] 4 is a flow chart diagram illustrating a method for maintaining communication between the monitoring client and the patient-care device of FIG. 3 according to an embodiment of the present disclosure. [Diagram 5] FIG. 13 is a block diagram of an electronic patient-care system having a dock for docking both a monitoring client and a patient-care device in accordance with yet another embodiment of the present disclosure. [Figure 6] 6 is a flow chart diagram illustrating a method for maintaining communication between the monitoring client and the patient-care device of FIG. 5 according to an embodiment of the present disclosure. [Figure 7] FIG. 13 is a block diagram of an electronic patient-care system having a monitoring client with an integrated dock for docking a patient-care device thereto in accordance with yet another embodiment of the present disclosure. [Figure 8] FIG. 13 is a block diagram of an electronic patient-care system having a hub according to yet another embodiment of the present disclosure. [Figure 9] FIG. 13 is a block diagram of an electronic patient-care system having stackable monitoring clients and stackable patient-care devices according to yet another embodiment of the present disclosure. [Figure 10] 1 is a flowchart diagram of 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] FIG. 1 is a flow chart diagram of a method for aggregating patient-care parameters for multiple patients in a monitoring server according to an embodiment of the present disclosure. [Figure 12] 1 is a flowchart diagram of a method for recovering a patient-care device when operation of the patient-care device is interrupted according to an embodiment of the present disclosure. [Figure 13]FIG. 13 is a flowchart diagram of a method for pairing a monitoring client with a patient-care device according to an embodiment of the present disclosure. [Figure 14] FIG. 13 is a flowchart diagram of a method for monitoring operation of a patient-care device using a wearable system monitor paired to the patient-care device according to an embodiment of the present disclosure. [Figure 15] 1 is a flowchart diagram of a method for displaying a user interface using a user interface template according to an embodiment of the present disclosure. [Figure 16] FIG. 11 is a flowchart diagram of a method for downloading an application to control a patient-care device according to an embodiment of the present disclosure. [Figure 17] 1 is a flowchart diagram of a method for ensuring data integrity when communicating data for a patient-care device according to an embodiment of the present disclosure. [Figure 18] FIG. 13 is a block diagram of an electronic patient-care system according to yet another embodiment of the present disclosure. [Figure 19] FIG. 2 is a block diagram of an electronic patient-care system according to another embodiment of the present disclosure. [Figure 20] FIG. 20 is a block diagram of a dock of the electronic patient-care system of FIG. 19 in accordance with an embodiment of the present disclosure. [Figure 21] FIG. 1 illustrates an electronic patient-care system having a tablet docked in a dock having a cable electrically coupled to a patient-care device in accordance with an embodiment of the present disclosure. [Figure 22] FIG. 1 illustrates 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] FIG. 1 illustrates an electronic patient care system having a modular infusion pump that docks into a dock having a monitoring client with a retractable user interface, according to an embodiment of the present disclosure. [Figure 24] 24 is a side view of the electronic patient-care system of FIG. 23 in accordance with an embodiment of the present disclosure. [Diagram 25] A diagram showing an electronic patient care system having staggered modular infusion pumps that dock into a dock having a monitoring client with a retractable user interface in accordance with another embodiment of the present disclosure. [Figure 26] A diagram showing an electronic patient care system having modular infusion pumps that dock in a dock along a common horizontal plane, including a monitoring client with a retractable user interface, according to yet another embodiment of the present disclosure. [Figure 27] 27 is a side view of the electronic patient-care system of FIG. 26 in accordance with another embodiment of the present disclosure. [Figure 28] FIG. 13 illustrates an electronic patient care system having modular infusion pumps that dock in a dock along a common horizontal plane, including a monitoring client with a retractable user interface, and having a hub coupled to a scanner and dock, in accordance with yet another embodiment of the present disclosure. [Figure 29] 29 is a side view of the electronic patient-care system of FIG. 28 in accordance with another embodiment of the present disclosure. [Figure 30-32] 1A-1D illustrate several views of a clutch system for mounting an electronic patient-care system on a pole in accordance with an embodiment of the present disclosure. [Diagram 33] 1 illustrates an infusion pump and a dock coupled to a support pole, according to an embodiment of the present disclosure. [Diagram 34] 13A-13C show another infusion pump coupled to an open connector and an infusion pump with an open connector according to an embodiment of the present disclosure. [Diagram 35] FIG. 34 illustrates the infusion pump of FIG. 33 with two additional infusion pumps each coupled to an open connector in accordance with an embodiment of the present disclosure. [Diagram 36] FIG. 36 is a top view of one of the infusion pumps and hubs of FIGS. 33-35 in accordance with an embodiment of the present disclosure. [Figure 37] FIG. 1 illustrates a square hub having several connectors according to an embodiment of the present disclosure. [Figure 38]FIG. 13 illustrates an electronic patient-care system having a hub coupled to a post according to another embodiment of the present disclosure. [Figure 39] FIG. 13 illustrates an electronic patient-care system having a hub coupled to a pole and a portable dock with a quick release handle for removing the portable dock from the hub in accordance with another embodiment of the present disclosure. [Diagram 40] FIG. 13 illustrates an electronic patient-care system having a hub coupled to a post and a dock coupled to the hub in accordance with another embodiment of the present disclosure. [Diagram 41] FIG. 13 illustrates an electronic patient-care system having a hub coupled to a post according to another embodiment of the present disclosure. [Diagram 42] FIG. 13 illustrates an electronic patient-care system having a monitoring client coupled to a hub having a notch for receiving a patient-care device according to another embodiment of the present disclosure. [Diagram 43] FIG. 43 is a close-up view of a T-shaped connector that interfaces with a notch in a hub as shown in FIG. 42 according to another embodiment of the present disclosure. [Diagram 44] FIG. 13 illustrates an electronic patient-care system having stackable patient-care devices and stackable containers for storing infusion bags according to another embodiment of the present disclosure. [Diagram 45] FIG. 13 illustrates an electronic patient-care system having a stackable patient-care device that is stackable next to another stack of patient-care devices in accordance with yet another embodiment of the present disclosure. [Figure 46] FIG. 13 illustrates an electronic patient-care system having stackable patient-care devices including a syringe pump patient-care device having a single syringe according to another embodiment of the present disclosure. [Figure 47] FIG. 13 illustrates an electronic patient-care system having a stackable patient-care device including a syringe pump patient-care device having two syringes according to another embodiment of the present disclosure. [Figure 48]FIG. 13 illustrates an electronic patient-care system having stackable patient-care devices, each having a display, according to another embodiment of the present disclosure. [Figure 49] 49 is a close-up view of a handle of the electronic patient-care device of FIG. 48 according to another embodiment of the present disclosure. [Figure 50] FIG. 49 is an enlarged view of an infusion line port of the electronic patient-care system of FIG. 48 showing an infusion line positioned therethrough, in accordance with another embodiment of the present disclosure. [Figure 51] 1 illustrates another embodiment of an electronic patient-care system showing removal of stackable patient-care devices in accordance with another embodiment of the present disclosure. [Figure 52] FIG. 1 illustrates an electronic patient-care system prepared for transport according to another embodiment of the present disclosure. [Figure 53] FIG. 13 illustrates an electronic patient-care system having stackable patient-care devices according to another embodiment of the present disclosure. [Figure 54] FIG. 13 illustrates an electronic patient-care system having stackable patient-care devices that are stackable from the bottom up according to another embodiment of the present disclosure. [Figure 55] FIG. 13 illustrates an electronic patient-care system having stackable patient-care devices coupled to a post and stackable from the top down according to another embodiment of the present disclosure. [Figure 56] FIG. 13 is a perspective view of a clutch system having a release handle for operatively gripping a support pole according to another embodiment of the present disclosure. [Figure 57] FIG. 57 is a rear view of the clutch system of FIG. 56 showing a transparent back surface according to another embodiment of the present disclosure. [Figure 58] FIG. 57 is a top cross-sectional view of the clutch system of FIG. 56 according to another embodiment of the present disclosure. [Figure 59] FIG. 1 is a block diagram of a system for controlling an infusion pump according to an embodiment of the present disclosure. [Figure 60]FIG. 1 is a block diagram of an electronic patient-care system having a hub for communicating with a number of electronic patient-care devices according to an embodiment of the present disclosure. [Figure 61] FIG. 1 is a block diagram of an electronic patient-care system having a dock connectable to a patient-care device via a USB connection according to an embodiment of the present disclosure. [Figure 62] FIG. 1 is a process diagram illustrating several stages of electronic patient care, according to an embodiment of the present disclosure. [Figure 63-66] 1A-1D illustrate several configurations of an electronic patient-care system according to embodiments of the present disclosure. [Figure 67] FIG. 1 is a timing diagram of an electronic patient care therapy using an infusion pump according to an embodiment of the present disclosure. [Fig. 68A-68B] FIG. 68 is a flowchart diagram of a method illustrating the timing diagram of FIG. 67 according to an embodiment of the present disclosure. [Figure 69-70] 1 illustrates an additional arrangement of an electronic patient-care system according to an embodiment of the present disclosure. [Figure 71] FIG. 1 is a timing diagram of an electronic patient care therapy using an infusion pump according to an embodiment of the present disclosure. [Fig. 72A-72B] FIG. 72 is a flowchart diagram of a method illustrating the timing diagram of FIG. 71 according to an embodiment of the present disclosure. [Figure 73] FIG. 13 is another timing diagram of an electronic patient care therapy using an infusion pump according to an embodiment of the present disclosure. [Figure 74] FIG. 74 is a flowchart diagram of a method illustrating the timing diagram of FIG. 73 according to an embodiment of the present disclosure. [Figure 75] FIG. 11 is yet another timing diagram of an electronic patient care therapy using an infusion pump, according to another embodiment of the present disclosure. [Figure 76] FIG. 76 is a flowchart diagram of a method illustrating the timing diagram of FIG. 75 according to an embodiment of the present disclosure. [Fig. 77-78] 1A-1D illustrate several configurations of an electronic patient-care system according to embodiments of the present disclosure. [Figure 79]FIG. 11 is another timing diagram of an electronic patient care therapy using an infusion pump according to another embodiment of the present disclosure. [Fig. 80A-80B] FIG. 80 is a flow chart diagram of a method illustrating the timing diagram of FIG. 79 according to an embodiment of the present disclosure. [Figure 81] FIG. 11 is another timing diagram of an electronic patient care therapy using an infusion pump according to another embodiment of the present disclosure. [Fig. 82A-82B] 82 is a flow chart diagram of a method illustrating the timing diagram of FIG. 81 according to an embodiment of the present disclosure. [Fig. 83-89] 1A-1C illustrate several additional embodiments of an electronic patient-care system according to some embodiments of the present disclosure. [Figure 90] FIG. 2 is a block diagram of the electronics of an embodiment of a hub, according to an embodiment of the present disclosure. [Figure 91] FIG. 2 is a block diagram of an electronic circuit for interfacing with an infusion pump, according to an embodiment of the present disclosure. [Figure 92] FIG. 13 illustrates another embodiment of an electronic patient-care system having vertically arranged patient-care devices docked within a dock in accordance with an embodiment of the present disclosure. [Figure 93] FIG. 2 is a block diagram of the electronics of an embodiment of a hub, according to an embodiment of the present disclosure. [Figure 94] FIG. 2 is a block diagram of the electronic circuitry of a communication module according to an embodiment of the present disclosure. [Fig. 95-98] 1A-1D illustrate some embodiments of an electronic patient-care system having an infusion pump coupled to a communications module in accordance with some embodiments of the present disclosure. [Figure 99-101] 2 is a block diagram of some of the electronic circuitry of the dock, according to some embodiments of the present disclosure. [Figure 102] FIG. 1 is a block diagram of a battery pack according to an embodiment of the present disclosure. [Fig. 103-104] 13A-13C illustrate additional embodiments of the electronic circuitry of the dock according to additional embodiments of the present disclosure. [Fig. 105-116]11A-11D illustrate several embodiments of an attachable pump attached to a monitoring client according to additional embodiments of the present disclosure. [Fig. 117] FIG. 1 illustrates a backplane for use in an infusion pump, according to an embodiment of the present disclosure. [Fig. 118] A cross-sectional view of the backplane panel of Figure 117 according to an embodiment of the present disclosure. [Figure 119-120] 11A-11D illustrate several embodiments of an attachable pump attached to a monitoring client according to additional embodiments of the present disclosure. [Figure 121] FIG. 2 illustrates a communication module according to an embodiment of the present disclosure. [Figure 122] FIG. 1 illustrates a communication module attached to a patient monitoring device according to an embodiment of the present disclosure. [Figure 123] FIG. 122 is a diagram of the electronic circuitry of the communication module of FIG. 121 in accordance with an embodiment of the present disclosure. [Figure 124] FIG. 2 is a diagram of an electronic circuit for converting short-range wireless communication to UHF, according to an embodiment of the present disclosure. [Fig. 125-127] FIG. 13 illustrates several antennas according to additional embodiments of the present disclosure. [Figure 128] FIG. 1 illustrates a patient wrist band with an RFID tag attached thereto, according to an embodiment of the present disclosure. [Figure 129] FIG. 129 illustrates a split-ring resonant circuit for use on the wrist band of FIG. 128 in accordance with an embodiment of the present disclosure. [Fig. 130] FIG. 2 illustrates a near field antenna according to an embodiment of the present disclosure. [Fig. 131] FIG. 131 illustrates an equivalent circuit of the split ring resonator circuit of FIG. 130 in accordance with an embodiment of the present disclosure. [Fig. 132] FIG. 1 illustrates a 5R checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. [Fig. 133] FIG. 13 illustrates an occlusion checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. [Fig. 134] FIG. 1 illustrates a display of a monitoring client in operative communication with several infusion pumps, according to an embodiment of the present disclosure. [Fig. 135] 1 is a diagram of a display on a healthcare provider's portable monitoring client showing a list of patients whose information the provider has access to in accordance with an embodiment of the present disclosure. [Fig. 136] FIG. 1 illustrates a display on a healthcare provider's portable monitoring client showing devices associated with a particular patient, with one-touch access to current data from the devices and some of the patient's medical information, in accordance with an embodiment of the present disclosure. [Fig. 137] A diagram illustrating a display on a healthcare provider's portable monitoring client showing a data entry area for a drug prescription for use with an intravenous infusion pump in accordance with an embodiment of the present disclosure. [Figure 138] FIG. 13 illustrates a display on a healthcare provider's portable monitoring client showing a risk profile associated with a prescribed medication and a proposed course of action, as generated by the monitoring client, in accordance with an embodiment of the present disclosure. [Figure 139] A diagram illustrating a display on a healthcare provider's portable monitoring client showing a drug prescription ready for submission by the ordering provider in accordance with an embodiment of the present disclosure. [Fig. 140] FIG. 13 illustrates a display on a healthcare provider's portable monitoring client showing how the monitoring system can display confirmation to the ordering provider that the prescription has been transmitted to the pharmacist in accordance with an embodiment of the present disclosure. [Fig. 141] FIG. 1 is a perspective view of a micro-infusion pump coupled to an adapter according to an embodiment of the present disclosure. [Fig. 142] FIG. 1 is a perspective view of a wireless hub device that wirelessly relays data from a patient-care device to a monitoring client, another hub, or a dock, according to an embodiment of the present disclosure. [Fig. 143]FIG. 1 illustrates a front perspective view of an electronic patient-care system having a modular patient-care device coupled to a monitoring client via an adapter and a dock in accordance with an embodiment of the present disclosure. [Fig. 144] FIG. 144 is a side perspective view of the electronic patient-care system of FIG. 143 in accordance with an embodiment of the present disclosure. [Fig. 145] 144 is an enlarged perspective view of one interface of the patient-care device shown in FIG. 143 in accordance with an embodiment of the present disclosure. [Fig. 146] FIG. 144 is a top view of the electronic patient-care system of FIG. 143 in accordance with an embodiment of the present disclosure. [Fig. 147] FIG. 1 illustrates a system for an electronic patient care system according to an embodiment of the present disclosure. [Fig. 148] 1 is a block diagram of an electronic patient care system according to an embodiment of the present disclosure. [Figure 149] FIG. 149 is a block diagram of a bedside portion of the electronic patient-care system of FIG. 147 and / or FIG. 148 in accordance with an embodiment of the present disclosure. [Fig. 150] FIG. 147, 148, and / or 149 is a block diagram of the dock / hub according to an embodiment of the present disclosure. [Fig. 151] FIG. 148 is a block diagram illustrating the infusion pump circuit of FIG. 149 in accordance with an embodiment of the present disclosure. [Fig. 152] FIG. 1 is a block diagram illustrating a sensor coupled to a mechanism of an infusion pump according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0122] Techniques are disclosed for facilitating patient care. The techniques can be implemented, for example, in a system having one or more patient-care devices communicatively coupled to a monitoring client, according to one exemplary embodiment. The patient-care devices can include any number of diverse functions and / or can be manufactured by different manufacturers. In one such case, a communication interface between the client monitoring station and the various diverse patient-care devices allows for discovery and protocol conversion, as well as various other functions, such as, for example, power provision, conformance with various standards, and user interfaces. The patient-care devices can include infusion pumps, microinfusion pumps, insulin pumps, syringe pumps, pill dispensers, dialysis machines, ventilators, ultrasound machines, ECG monitors, blood pressure monitors, pulse oximeters, CO2 monitors, and other devices. 2The device may be a capnometer, drip counter, drip flow meter, optical Doppler device, heart rate monitor, intravenous bag, hemodialysis machine, peritoneal dialysis machine, enteral dialysis machine, patient thermometer, and / or other bedside patient care device. U.S. patent application Ser. No. 11 / 704,899, filed Feb. 9, 2007, entitled Fluid Delivery System and Method, thereafter published Oct. 4, 2007 as U.S. Patent Application Publication No. 2007-0228071-A1 (Attorney Docket No. E70); U.S. patent application Ser. No. 11 / 704,896, filed Feb. 9, 2007, entitled Pump Fluid Delivery System and Method Using the Force Applying Assembly, thereafter published Sep. 20, 2007 as U.S. Patent Application Publication No. 2007-0228071-A1 (Attorney Docket No. E70); No. 11 / 704,886, filed February 9, 2007 (Attorney Docket No. E71), subsequently published on September 20, 2007; U.S. Patent Application Publication No. 2007-0219481 (Attorney Docket No. E72), filed February 7, 2007 (Attorney Docket No. 11 / 704,897, filed February 7, 2007 (Attorney Docket No. 11 / 704,897), filed September 7, 2007 (Attorney Docket No. 11 / 704,897), ... subsequently published on September 20, 2007 (Attorney Docket No. 11 / 704,897), filed February 7, 2007 (Attorney Docket No. 11 / 704, No. 2007-0219597 (Attorney Docket No. E73), published on the 20th, U.S. Patent Application No. 12 / 347,985, filed December 31, 2008, entitled Infusion Pump Assembly, thereafter U.S. Patent Application No. 2009-0299277 (Attorney Docket No. G75), published on December 3, 2009, and U.S. Patent Application No. 12 / 347,982, filed December 31, 2008, entitled Wearable Pump Assembly, thereafter U.S. Patent Application Publication No. 2009-0281497 (Attorney Docket No. G76), published on November 12, 2009; U.S. Patent Application No. 12 / 347,981, filed on December 31, 2008, entitled Infusion Pump Assembly; U.S. Patent Application Publication No. 2009-0275896 (Attorney Docket No. G77), published on November 5, 2009; U.S. Patent Application No. 12 / 347,981, filed on December 31, 2008, entitled Infusion Pump Assembly With Switch;No. 12 / 249,882, filed October 10, 2008, entitled Infusion Pump Assembly, and thereafter published on April 15, 2010, as U.S. Patent Application Serial No. 2010-0094222 (Attorney Docket No. F51), ... No. 12 / 249,636, entitled SYSTEMS AND METHODS FOR ADMINISTRATION OF A BODY OF A BODY, which was subsequently published on April 15, 2010 as U.S. Patent Application Publication No. 2010-0094261 (Attorney Docket No. F52); U.S. Patent Application No. 12 / 249,621, entitled SYSTEMS AND METHODS FOR DETECTING AN OCCLUSION, which was filed on October 10, 2008 as U.S. Patent Application Publication No. 2010-0094261 (Attorney Docket No. F52); No. 12 / 249,600, filed October 10, 2008, entitled MULTI-LANGUAGE / MULTI-PROCESSOR INJECTION PUMP ASSEMBLY, and subsequently published on April 15, 2010, U.S. Patent Application Publication No. 2010-0094221, filed November 29, 2011, entitled INJECTION PUMP ASSEMBLY WITH BACKUP POWER SUPPLY. No. 8,066,672 (Attorney Docket No. F55), U.S. Patent No. 8,016,789 (Attorney Docket No. F56), issued on September 13, 2011, entitled PUMP ASSEMBLY WITH REMOVABLE COVER ASSEMBLY, and U.S. Patent No. 7,306,578 (Attorney Docket No. C54), issued on December 11, 2007, entitled LOADING MECHANISM FOR AN INJECTION PUMP, are all incorporated herein by reference in their entirety. The techniques can be used to enable seamless communication and fail-safe operation. Numerous other features, functions, and applications will be apparent in view of this disclosure.

[0123] General Overview As previously described, the process of providing comprehensive care to a patient, such as prescribing and delivering medical treatment, is associated with a number of significant problems: for example, there is a great potential for important information to be miscommunicated, for treatment decisions to be made without ready access to complete information, and / or for delays in implementing prescriptions due to unnecessary redundant and incomplete procedures.

[0124] More specifically, medication errors can be the cause of hundreds of deaths and injure thousands or even millions of people each year in the United States alone. Hospitals under financial pressure may experience many medication error incidents. Medications associated with many dangerous errors include insulin, narcotics, heparin, and chemotherapy. Causes of medication errors include administering the wrong medication, administering the wrong concentration of medication, delivering medication at the wrong rate, or delivering medication by the wrong route (medications can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, eye or ear, intrathecally, intraperitoneally, or even intravesically). Even with proper order and proper 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 has been a trend towards using electronic medical records (EMRs) and barcode systems for medications. EMR systems can facilitate computerized provider order entry (CPOE) and flag prescriptions that do not match a patient's diagnosis, allergies, weight, and / or age, for example. However, these systems have not been widely adopted, and their implementation can lead to significant delays and inefficiencies in ordering, preparing, and administering medications.

[0125] In addition, drug infusion devices, e.g., infusion pumps, are responsible for a significant number (e.g., up to one-third) of all medication errors that result in substantial injury. The wrong drug may be suspended, inaccurate parameters (e.g., drug concentration or infusion rate) may be entered, or existing infusion parameters may be inappropriately altered. Nearly half of all deaths associated with infusion pumps are due to user error, and many of these errors may be due to errors when programming the infusion pump.

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

[0127] Thus, according to an embodiment of the present disclosure, an electronic patient-care system is disclosed that includes a monitoring client configured to communicate at least one patient-care parameter, a patient-care device configured to communicate at least one patient-care parameter, and a communication interface configured to facilitate communication between the monitoring client and the at least one patient-care device by discovering the presence of the at least one patient-care device and translating communication signals from the device into a communication protocol associated with the monitoring client. In some embodiments, the monitoring client passively monitors the operation of the patient-care device. The communication interface may be implemented by a communication module described below. The communication interface may be further configured to discover the presence of other additional patient-care devices that are distinct from one another (e.g., of various manufacturers, capabilities, and / or communication protocols, etc.) and translate communication signals from these devices into a communication protocol associated with the monitoring client or a hub. Thus, the communication interface effectively enables the monitoring client, such as a tablet computer, to be used as a common, general user interface that can be used by health care providers when providing care to patients associated with the monitoring client. One or more databases accessible by the monitoring clients allow for central storage of patient information (in any format and database structure desired by the healthcare facility or database maintainer) and downloading of information that can be used by healthcare providers in treating patients associated with the monitoring clients. The communications interface can be implemented in a number of ways, using wired and / or wireless technologies, allowing seamless communication and fail-safe operation of multiple patient-care devices. Some patient-care devices, hubs, docks, and / or monitoring clients can communicate simultaneously over two or more communications links and / or simultaneously over two frequency channels (in some embodiments, data may be redundant).In some embodiments, the communications module allows the patient-care device to be used portable, for example by including a battery and sufficient circuitry for ambulatory operation of the patient-care device, such as an infusion pump. Additionally or alternatively, the patient wrist band can include a battery that can be plugged into the communications module (or, in some embodiments, directly into the patient-care device) to power the patient-care device. The communications module can be wirelessly rechargeable.

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

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

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

[0131] The pharmacy 6 may include one or more computers connected to a network, e.g., the Internet, to receive the prescription and queue the prescription in the one or more computers. The pharmacy may use the prescription to (1) compound the medication (e.g., using an automated compounding device coupled to the one or more computers that can compound fluids or generate pills, or manually by a pharmacist monitoring the queue of the one or more computers), (2) pre-fill a fluid reservoir of the syringe pump 126, (3) program the syringe pump 126 (e.g., 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 at the pharmacy according to the prescription. The automated compounding device may automatically fill fluid into one or more of the syringe pump 126, intravenous bag 170, or microinfusion pump 130, and / or may automatically fill pills into the pill dispenser 128. The automated compounding device may generate a bar code, an RFID tag, and / or data. The information in the bar code, RFID tag, and / or data may include a treatment plan, a prescription, and / or patient information.

[0132] The automated compounding device may (1) attach a bar code 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 an RFID tag or memory in 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 to a database (e.g., the patient's EHR 19 or the patient's personal EHR 19') that associates the prescription with the infusion pump 7, syringe pump 126, micro infusion pump 130, pill dispenser 128, or intravenous bag 170, for example, using a bar code, RFID tag, or serial number or other identifying information in memory.

[0133] Infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 may determine whether (1) syringe pump 126 or intravenous bag 170 has the correct fluid, (2) microinfusion pump 130 has the correct fluid, (3) pill dispenser 128 has the correct pill, (4) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to syringe pump 126, microinfusion pump 130, or intravenous bag 170, or (5) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to syringe pump 126, microinfusion pump 130, or intravenous bag 170, or (6) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to pill dispenser 128, or (7) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to pill dispenser 128, or (8) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to pill dispenser 128, or (9) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to pill dispenser 128, or (10) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being delivered to pill dispenser 128, or (11) whether the treatment programmed into infusion pump 7, or corresponds to the fluid in the intravenous bag 170, (5) whether the therapy programmed into the pill dispenser 128 corresponds to the pills in the pill dispenser 128, and / or (6) whether the infusion pump 7, the syringe pump 126, the microinfusion pump 130, or the therapy programmed into the pill dispenser 128 is correct for a particular patient (e.g., as determined from the patient's bar code, RFID, or other patient identification information). That is, in some particular embodiments, the infusion pump 7, syringe pump 126, microinfusion 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 matches the value as seen within internal memory (e.g., downloaded via an automated compounding device) or that the value matches the value as seen in the patient's electronic medical record (e.g., via the patient's serial number as determined by scanning the patient's RFID tag or scanning a barcode by the patient, as stored in the patient's EHR 19 or the patient's personal EHR 19').

[0134] For example, a scanner in the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 can scan a barcode on another patient-care device to obtain the patient-care device's serial number and a barcode on the patient to determine the patient's serial number, and can query electronic medical record data to determine whether the patient-care device's serial number corresponds to the patient's serial number as stored in the electronic medical record (e.g., as may be updated by the pharmacy 22 or the pharmacy's automated compounding device).

[0135] Additionally or alternatively, monitoring client 6 may be configured to determine whether (1) syringe pump 126 or intravenous bag 170 has the correct fluid, (2) microinfusion pump 130 has the correct fluid, (3) pill dispenser 128 has the correct pill, (4) whether a treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 corresponds to the fluid in syringe pump 126, microinfusion pump 130, or intravenous bag 170, (5) whether the pill dispenser 128 has the correct pill, (6) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 corresponds to the fluid in syringe pump 126, microinfusion pump 130, or intravenous bag 170, (7) whether the pill dispenser 128 has the correct pill, (8) whether the treatment programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 corresponds to the fluid in syringe pump 126, microinfusion pump 130, or intravenous bag 170, (9) whether the pill dispenser 128 has the correct pill, (10) whether the pill dispenser 128 has the correct pill, (11) whether the pill dispenser 128 has the correct pill, (12) whether the pill dispenser 128 has the correct pill, (13) whether the pill dispenser 128 has the correct pill, (14) whether the pill dispenser 128 has the correct pill, (15) whether the pill dispenser 128 has the correct pill, (16) whether the pill dispenser 128 has the correct pill, (17) whether the pill dispenser 128 has the correct pill, (18) whether the pill dispenser 128 has the correct pill, (19) whether the pill dispenser 128 has the correct In some embodiments, the infusion pump 7, syringe pump 126, pill dispenser 128, microinfusion pump 130, or intravenous bag 170 may be scanned to determine whether the therapy programmed into the pill dispenser 128 corresponds to the pill in the pill dispenser 128 and / or (6) whether the therapy programmed into the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 is correct for a particular patient (e.g., as determined from the patient's bar code, RFID, or other patient identification information). Additionally or alternatively, the monitoring client 1, infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 may contact the electronic medical record database 19 or 19' and / or pharmacy 22 to verify or download the prescription, for example, using a bar code serial number on the infusion pump 7, syringe pump 126, microinfusion pump 130, pill dispenser 128, or intravenous bag 170.

[0136] Optionally, the monitoring client 1, other monitoring clients 4, and / or 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, such as bolus amount, infusion rate, total fluid to deliver, start time of drug delivery, stop time of drug delivery, or delivery rate profile to the infusion pump 7, syringe pump 126, and / or microinfusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests to the pill dispenser 7, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, a particular medication may be taken on an as-needed basis (i.e., when needed), but the medication may be unsafe if taken in excess; a maximum pill dispensing criterion may prevent the medication from being taken by a patient at an unsafe level, for example, in a given amount during a given time interval.

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

[0138] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to generate an alarm and / or alert. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in downstream pressure of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 as one indication of excessive clotting, seepage, obstruction or kinking of the tubing to the patient, or an obstruction caused downstream by material such as contamination found in the intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly alert or warn the user. These alarms and / or alerts can also inform the nurse to take other appropriate action, such as suggesting to change the needle in response to an obstruction (e.g., caused by clotting) if the downstream pressure to the patient rises above a predetermined threshold, or suggesting to check for kinks in the line if the downstream pressure to the patient rises above a predetermined threshold.

[0139] Additionally or alternatively, a sudden drop in downstream pressure to the patient 2 is an indication that the tubing has come off the needle and / or that the needle is now off the patient, and in response, one or more of the monitoring clients 1, 4, 11 may visually or audibly warn or alert the user to reattach the tubing to the needle or to insert a new needle for continued infusion. An alarm may also indicate that the patient may be bleeding, such as when the tubing comes off the needle, and that action needs to be taken quickly because the patient is bleeding due to an unattached needle coupler.

[0140] In some embodiments, the upstream pressure to one or more infusion pumps 7 may additionally or alternatively be monitored for any upstream occlusions. For example, contamination in the intravenous bag 170 may 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 to the infusion pump 7 may drop below what would occur if there was no upstream occlusion. Thus, one or more of the monitoring clients 1, 4, 11 may issue an alarm or alert if the upstream pressure drops below a predetermined threshold and suggest or require a caregiver to alleviate the occlusion, for example, by replacing the tubing or the intravenous bag 170.

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

[0142] As shown in FIG. 1 and in accordance with some embodiments, the system 100 includes a monitoring-client dock 102 and a device dock 104. The monitoring-client dock 102 is configured to receive a monitoring client 1, and the device dock 104 is configured to receive one or more patient-care devices to facilitate bedside patient care (described in more detail below). Although the device dock 104 is shown as being 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 arbitrary number of patient-care devices. Additionally, although the monitoring-client dock 102 is shown as being 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 arbitrary number of monitoring clients 1.

[0143] In an exemplary embodiment, cable 110 is coupled to both docks 102, 104 to provide a communications link therebetween. Cable 110 may be permanently attached or attachable to one or both of docks 102, 104. Additionally or alternatively, cable 110 may include one or more connectors (not explicitly shown) for plugging the cable into one or both of docks 102, 104.

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

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

[0146] When the monitoring client 1 is docked in the monitoring-client dock 102, the monitoring client 1 has access to communications between the docks 102, 104. For example, in some embodiments of the present disclosure, the monitoring client 1 can communicate with electronic circuitry, e.g., memory, in the device dock 104 via a communications link provided by the cable 110. Additionally or alternatively, the monitoring client 1 can communicate with any devices docked in the device dock 104 through the communications link provided by the cable 110 and / or one or more wireless communications links (described in more detail below).

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

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

[0149] In some embodiments, the monitoring client 1 can electrically determine whether one or more electrical contacts of one or more connectors are electrically engaged with the monitoring client dock 102 to determine whether the cable 110 is available as a communication link, for example by measuring a voltage or impedance between two electrical contacts of a connector of the monitoring client 1 used for docking to the monitoring client dock 102 and for providing electrical communication between the monitoring client dock 102 and the monitoring client 1. The monitoring client 1 can also determine that the cable 110 is not available if the monitoring client 1 determines that it is not electrically coupled to the cable 110. Additionally or alternatively, in some embodiments, a magnet in the dock 102 engages a Hall effect sensor in the monitoring client 1, which is then used by the monitoring client 1 to determine whether it is docked such that the monitoring client 1 infers that the cable 110 is not available as a communication link if the monitoring client 1 is not docked. Additionally 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 may periodically "ping" the device dock 104 via the cable 110. If the monitoring client does not receive a response from the device dock 104 within a predetermined period of time, the monitoring client 1 may assume that the cable 110 is not available as a communications link.

[0150] If the monitoring client 1 determines that the cable 110 is not available as a communications link, the monitoring client 1 may sound an alarm or alert using a speaker and / or a vibration motor, may send an alarm or alert to the remote communicator 11 to alert or alert the remote communicator using a speaker and / or a vibration motor, and / or the monitoring client 1 may attempt to communicate with a patient-care device via another communications link. The term "alarm" as used herein is intended to include "soft" alarms, such as, for example, alarms that do not draw a person's attention until after a predetermined time has passed and the cause of the alarm remains.

[0151] In some embodiments of the present disclosure, the monitoring client dock 102 includes one or more wires or waveguides with minimal or no circuitry from the monitoring client 1 to the cable 110. For example, in some embodiments of the present disclosure, the monitoring client dock 102 is a cradle that provides a direct electrical coupling from the monitoring client 1 to the cable 110. Additionally or alternatively, in some embodiments of the present disclosure, the device dock 104 includes 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 with minimal or no circuitry. The device dock 104 may be a cradle in some embodiments.

[0152] In embodiments of the present disclosure, each monitoring client 1 is assigned to a particular 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 and may facilitate efficient data viewing and data entry, and the monitoring client 1 may be a notebook PC, netbook PC, tablet PC, "smart phone," with or without a touch screen. Additionally or alternatively, in some embodiments, the monitoring client 1 and / or remote communicator 11 may dock or couple to a cable connected to a much larger display, thereby making the much larger display (e.g., a 24-inch display) the display for the monitoring client 1 and / or remote communicator 11, and the much larger display may have input capabilities, such as touch screen capabilities, touch pen input capabilities, keyboard input capabilities, remote control input capabilities, etc., that are communicated to the monitoring client 1 and / or remote communicator 11. For example, viewing of x-ray or patient imaging files can be facilitated by docking the monitoring client 1 and / or remote communicator 11 to a monitoring dock coupled to a larger display, thereby allowing a 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.

[0153] The monitoring client 1 may 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. The assignment of a particular monitoring client 1 to a particular patient 2 may be done using any of a number of methods, including (but not limited to) a unique patient identifier encoded on a barcode 114 or RFID tag 116 embedded in, for example, a wrist band 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 interrogator, 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., face and / or voice recognition, retinal scan, blood type monitor, fingerprint scan, etc.) may be embedded within or associated with the monitoring client 1. The device dock 104 may communicate the unique patient identifier to the monitoring client dock 102, the monitoring client 1, the monitoring server 3, the remote communicator 11, other monitoring clients 4, another server, or an electronic computing device to facilitate treatment of the patient 2.

[0154] The monitoring client 1 may comprise one or more microprocessors, microcontrollers, logic devices, digital circuits, analog circuits, etc., for communicating (e.g., sending or receiving) information related to a patient's care, condition, disease, or treatment. For example, the monitoring client 1 may send or receive patient care parameters, such as patient status parameters and / or patient treatment parameters. Some exemplary patient status parameters include blood pressure, temperature, heart rate, pulse oximeter, CO2, and the like. 2These are measurements of blood pressure, blood oxygen levels, patient alertness, patient awareness, patient responsiveness, etc. Some exemplary patient treatment parameters include administered drugs, drug or fluid flow rates, drug administration schedules, or other bedside treatment parameters.

[0155] In some embodiments, for example, the monitoring client 1 can be physically associated with, permanently attached to, attachable and detachable therefrom, or attachably detachable from the infusion pump 7. This can be accomplished by a docking interface between the two devices, for example, the monitoring-client dock 102 and the device dock 104. In one such embodiment, the monitoring client 1 communicates with the pump 7 (or other patient-care device) in a number of ways, including, for example, through electrical contact with the docks 102, 104, by an electrical connector, or wirelessly by a transceiver on each device using the respective antennas 112, 122A. Additionally or alternatively, the infusion pump may include pre-programmed treatment data indicating a particular treatment for a particular patient that is uploaded to the monitoring client 1 when the infusion pump 7 is in operative communication with the monitoring client 1.

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

[0157] In an embodiment of the present disclosure, the equipment service 8 and / or the adverse drug event network 9 may also comprise a medication error reduction system (DERS). The DERS system may include a first set of predefined criteria for triggering a soft alarm and / or a second set of predefined criteria for triggering a hard alarm. A soft alarm can be overridden (e.g., turned off) by a caregiver using a user interface of the infusion pump 7 and / or the monitoring client 1 (and may be only an audible and / or vibration alarm), whereas a hard alarm causes treatment to be suspended until the cause is removed.

[0158] In yet additional embodiments of the present disclosure, the DERS system can include a first set of predefined criteria defining soft limits, and / or a second set of predefined criteria defining hard limits. The hard and soft limits define treatment limits, such as drug dosage limits, based on dimensions, weight, age, other patient parameters, or other criteria. The soft limits can be overridden by a caregiver using a user interface of the infusion pump 7 and / or monitoring client 1 to initiate treatment even though the treatment is outside of the first set of predefined criteria, while the hard limits prevent treatment from initiating until settings are changed to meet the second set of predefined criteria defining the hard limits.

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

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

[0161] In other embodiments, each patient-care device may have zero modules or may have three or more modules (e.g., communication modules). For example, each module may have a specific function, e.g., WiFi, and a user may select multiple modules, each with a specific function, and couple them together. The group of modules may then be applied to a patient-care device, e.g., an infusion pump. Consider yet another example. Each module may have a primary processor, a backup processor, and functional circuitry, all in operative communication with each other. The functional circuitry may be a wireless transceiver, a battery, an interface to a touch screen or display (the display may be mounted on the housing), a wired connection, Bluetooth, Bluetooth low energy, WiFi, 3G, 4G, a co-processor, a control system (e.g., for controlling the infusion pump), dosing with fluid measurement circuitry, etc. Selected modules may be connected to each other, e.g., in a daisy chain, and then connected to an infusion pump. Selected modules may operatively communicate with each other to coordinate their operations and / or functions, in this example, via, e.g., a CAN bus, wired communication, wireless, and / or other.

[0162] Each module may include a speaker and a microphone. When several modules are connected to each other, the modules may coordinate their operation, whereby one module audibly signals the speaker while another module uses the microphone to determine if the speaker is functioning properly. Several modules may each use their speaker on a different frequency, whereby any one of the modules may sense audio through its microphone and demodulate different frequencies to test several of the speakers at the same time. Testing may be requested by a first module to a second module, which may transmit the results of the test to the first module.

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

[0164] As can be appreciated in light of the present disclosure, communications modules 124A-124K can be operably coupled to various patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. For example, and with further reference to FIG. 1, communications module 124B is operably coupled to syringe pump 126 and communications module 124C is operably coupled to pill dispenser 128. Additionally or alternatively, communications module 124E is operably coupled to ECG monitor 12, communications module 124F is operably coupled to blood pressure monitor 15, communications module 124G is operably coupled to pulse oximeter / CO2 monitor 126, and communications module 124H is operably coupled to ECG monitor 128. 2 Communications module 124A-124K is operably coupled to capnometer 16, communications module 124H is operably coupled to other monitor 17, communications module 124I is operably coupled to the patient's intravenous access 35, and communications module 124K is operably coupled to drip flow meter 148. Each respective communications module 124A-124K may provide, for example, a suitable control system, control algorithms, battery power, or other functionality for the respective patient-care device 7, 14, 15, 16, 17, 35, 126, 128, or 148 coupled thereto.

[0165] Additionally or alternatively, in some embodiments, the communications module 124D is docked within the device dock 104 and operably coupled to the device dock 104 via a bus or backplane, for example, to communicate with any devices attached to the device dock 104, and to communicate with electronic circuitry within the device dock 104, electronic circuitry within the monitoring client dock 102, and / or the monitoring client 1. Optionally, the communications module 124D can communicate with and / or provide power to any devices docked within the device dock 104, for example, the infusion pump 7, the syringe pump 126, the pill dispenser 128, or the micro-infusion pump 130. It should be noted that the functionality of the communications module 124D can also be integrated within the circuitry of the device dock 104 itself.

[0166] Additionally or alternatively, in some embodiments, it is optional to configure each of the communications modules 124 to provide a sufficient power supply to each of the devices 7, 14, 15, 16, 17, 35, 126, 148 that can be supplemented by one or more wired power sources, such as power sources accessible through a bus or backplane within the device dock 104. As previously discussed, in some embodiments of the present disclosure, the communications module 124D provides sufficient power to the devices 7, 126, 128, 130 and 133.

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

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

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

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

[0171] Optionally, the system 100 may also include a wearable system monitor 131 for monitoring the operation of the various devices, docks, monitoring clients, and / or servers. The monitoring clients 1, remote communicators 11, and / or hubs 802 of FIG. 8 may be used to program, interact with, and / or pair with the wearable system monitor 131. The wearable system monitor 131 may be worn by the patient 2 or by the provider, and multiple wearable system monitors 131 may be used. The wearable system monitor 131 may interrogate the various devices to ensure proper operation. For example, in one exemplary embodiment, the wearable system monitor 131 communicates with the patient-care devices 14, 15, 16, 17, 35, 126, 128, 130, the monitoring client 1, the monitoring client dock 102, the device dock 104, and / or the hub 802 of FIG. 8 to determine whether any malfunctions, errors, fraud, data corruption, communication degradation, incomplete operation, slow operation, or other problems exist.

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

[0173] System monitor 131 may 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 in the device being queried and requesting the value of the counter from the device after it has been incremented, (3) challenge-response queries, and / or (4) other system monitoring techniques or methods.

[0174] As previously described, in some embodiments, the system monitor 131 may, after querying a patient-care device paired to the system monitor 131, predict a response to the query within a predetermined time. For example, the system monitor 131 may send a “System Monitor Query” text string message to the infusion pump 7. In this example, the infusion pump 7 receives a message labeled “System Monitor Query” from the system monitor 131 and processes the message using one or more processors therein. When the infusion pump 7 processes the message, a software routine therein executes code to send a response message back to the system monitor 131; for example, the response message may be a “System Monitor Response” text string message sent to the system monitor 131. In this embodiment, the system monitor 131 can expect to receive a response message within a predetermined time, such as two seconds, and if the system monitor 131 does not receive a response message within two seconds, the system monitor 131 can alert other devices and / or send an alert (e.g., the system monitor 131 can broadcast an alert or miss message or have an alarm or alert provided audibly or visually via the processor 11).

[0175] As previously described, in some embodiments, the system monitor 131 increments a counter in the device being queried and requests the value of the counter from the device after it has been incremented. For example, the system monitor 131 may send a request to a patient-care device, e.g., an infusion pump 7, by sending a message such as "increment counter" to the device. A processor in the device receives the "increment counter" message, reads the value from a memory location in the device, increments the value it finds in the memory location, and stores the new value in the same memory location by overwriting the previous value. The processor then, in this example, reads the new value from the memory location and transmits the new value to the system monitor 131, e.g., via a wireless transceiver on the device being queried. System monitor 131, in this embodiment, predicts a particular value from the device being queried (this predicted value may be stored in the system monitor's memory, such as in a table.) For example, system monitor 131 may store in its memory a value of 48 previously received from the device and predict to receive a value of 49 from the device after requesting that the value be updated in the queried device.

[0176] Also, as previously described, challenge-response queries can be used by the system monitor 131. For example, the system monitor 131 can send an encrypted message to the patient-care device. The patient-care device is then tasked to decrypt the message using, for example, an encryption key and send the message back to the system monitor 131. The system monitor 131 can expect the unencrypted message to return 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 can alert other devices and / or send an alert (e.g., the system monitor 131 can broadcast an alert or alarm message and / or communicate these to the monitoring client 1, the monitoring server 3, the hub 802 of FIG. 8, or the remote communicator 11, which then display or audibly indicate the alert or alarm).

[0177] In an embodiment 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 smart phone, tablet computer, PDA, laptop, or other portable computing device). This may be accomplished by wireless 12, thereby allowing communication to be maintained regardless of the patient's location within the facility, or the provider's location, either within the facility or outside of it. In one aspect, patient 2 specific information may be stored locally within the monitoring client 1, thereby allowing the patient's healthcare provider to directly access the information without having to access the monitoring server 3.

[0178] In some embodiments, optionally by incorporating appropriate safety and security checks, changes to settings or flow parameters of a connected infusion pump 7 or patient monitoring device 14-17, 35, 126, 128, 130, 148 can be accomplished directly between the provider's monitoring client 11 and the monitoring client 1 (via wired or wireless communication), and selected changes can also be communicated to the monitoring server 3 and thereby, optionally, to other suitable locations such as the nurse's station 5 and / or pharmacy 6. Additionally, any new instructions regarding the patient 2 can be entered into the instructing provider's remote communicator 11 (e.g., a smart phone) and communicated to the monitoring client 1, which can then be made known to the caregiver (e.g., a nurse, nurse practitioner, physician, internist, or other health care professional) via the caregiver's own portable communicator 11. Additionally 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 a control system therein or coupled thereto can change its operation, e.g., set points, in response to the new instructions. In some embodiments, any information acquired and stored within the monitoring client 1 is periodically uploaded to the monitoring server 3 and stored in a patient-specific database. Thus, if a patient's monitoring client 1 is out of operation, a new device can be assigned to the patient 2 and the patient's current information from the monitoring server 3 can be quickly added back in. Instructions, medications, progress notes, monitoring data, treatment data, patient treatment parameters, patient monitoring parameters, and / or operating parameters from the patient's attached devices can also be uploaded from the monitoring client 1 to the patient's EHR 19, any applicable remote communicator 11, the hub 802 of FIG. 8, and / or the monitoring server 3 for permanent, temporary or transient storage and / or for analysis to ensure compliance with predefined criteria, e.g., ranges, thresholds, etc.

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

[0180] The information thus obtained can then serve as a key database against which new prescriptions can be analyzed. Prescriptions entered into the monitoring client 1 can be checked for compatibility with patient-specific information obtained by the monitoring server 3. Optionally, for security redundancy, orders entered remotely from the communicator 11 can be intercepted by the monitoring server 3 and checked as well. The monitoring server 3 can also obtain information from a medication database located within the facility's pharmacy 22 or externally 9 to determine whether a new patient order may, for example, generate an incompatibility with the patient's existing medications. In an embodiment of the present disclosure, the monitoring server 3 can be programmed to access a publicly available internet site 25 to determine whether new information regarding the patient's prescribed medications can be downloaded and communicated 13 to the patient's healthcare provider(s) in an alert or alarm. The monitoring server 3 can also route information between the remote portable communicator 11 and the patient's monitoring client 1.

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

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

[0183] The monitoring server 3 may be deployed to manage various levels of external database information that aids in, for example, keeping the content of the monitoring clients 1 as up to date as possible. This may be accomplished, for example, by comparing safety and drug information relevant to the patient as it becomes available and prioritizing updates / downloads on a data transfer schedule. The monitoring clients 1, 4 may also communicate either directly or through the monitoring server 3 with portable communicators 11 used by healthcare providers such as nurses, physicians, and pharmacists. In some cases, these devices may have a wired connection to the monitoring server 3 (e.g., when used in a fixed location such as a hospital pharmacy or nurse's station). In other cases, the portable communicator 11 may communicate with the monitoring server 3 through 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 computers and devices 11. Alternatively, a handheld remote communicator 11 (such as a smart phone or tablet netbook) may communicate directly 12 with the facility's monitoring client 1 via a cellular network, and / or the facility may include a private cell network, which may include a WiFi network (e.g., the 2.4 GHz to 2.4835 GHz unlicensed ISM band).

[0184] In some embodiments, the communication link between the monitoring clients 1, 4 and the monitoring server 3 may be via an Ethernet network if widely available within the facility, or via wireless transmission using one of several standards to link all patient-specific monitoring clients 1, 4 to a central monitoring server 3. The server 3 may then act as a relay for communication with other facility servers 8, web-based servers 25, and internal and external portable communicators 11 carried by the healthcare provider. In some embodiments, a wireless network provides the added functionality of being able to communicate with the monitoring server 3 regardless of where the patient 2 is located within the facility.

[0185] One way to provide wireless coverage throughout the facility is to require the facility to obtain a license for a private cellular network. One or more micro-cellular frequencies can be acquired or rented to provide a local communications network throughout the facility. Such an arrangement can maintain communications as patients and monitoring clients 1, 4 are moved from one location to another within the facility, maintaining connectivity with the monitoring server 3, various in-hospital and out-hospital databases 8, 25, and users at fixed stations (e.g., in some embodiments, the nursing station 5 and pharmacy 6) or with monitoring clients 11 (e.g., mobile smart phones, laptops, or tablet type devices) either inside or outside the hospital. In some embodiments, this type of system provides additional security over the permitted cellular communications infrastructure. In addition, in some embodiments, the active wireless system can monitor the strength of use within an area and command additional channel frequencies for that area. However, in some embodiments, the bandwidth capacity of the network may not allow for the efficient transmission of large data files, such as those containing radiological images, such as those that are bandwidth intensive and may be communicated more efficiently via a wired connection.

[0186] Alternatively or additionally, the hospital may implement an Internet or intranet based communication system in which 802.11 WiFi type protocols are used for wireless communication between the individual monitoring clients 1, 4 and the monitoring server 3. To ensure adequate signal reception throughout the facility, broadband antennas may be mounted on the roofs of buildings to collect cellular signals from local wireless carriers. A fiber optic or cable network may then distribute the signal throughout the facility. Additionally or alternatively, the monitoring server 3 may use a private cellular network as described above. Such systems are typically capable of providing secure communications and are capable of efficiently communicating large files, such as radiology images stored in the radiology database 21. Home or office based users may connect to the hospital server, for example, through a VPN or another secure access using wired or fiber optic cable, or through DSL telephone lines. Data encryption may be used to provide patient data security. In some applications, it may be advantageous to implement an asymmetric bandwidth communication network to optimize infrastructure capacity. This example uses licensed cellular frequencies in the "upstream" direction from the monitoring client 1 to the monitoring server 3, and unlicensed 802.11 WiFi frequencies in the "downstream" direction from the monitoring server 3 to the monitoring client 1. In this example, the upstream bandwidth and data rate requirements are relatively small compared to the downstream requirements. The low priority upstream transmission allows the monitoring client 1 to transmit data over a more distributed and cost-effective network, such as a ZigBee network, Bluetooth network, mesh network, etc.

[0187] As previously described, communication between various monitoring devices, such as patient-care devices 14, 15, 16, 17, 35 and monitoring client 1, can be accomplished in a cost-effective manner using, for example, ZigBee wireless mesh networks and / or Bluetooth networks. Exemplary monitoring devices include ECG monitors 14, blood pressure monitors 15, pulse oximeters / capnometers 16, thermometers, and weight scales, among others. A common feature of most of these devices is that they provide periodic readings of a single or a small number of parameters. Intra-hospital device communication systems, such as wireless mesh networks, provide low-power digital wireless connectivity between devices and can utilize widely available license-free frequency bands (e.g., 2.4 GHz in some jurisdictions). High-level communication protocols can be utilized to ensure data fidelity and security, such as, for example, TCP, UDP, etc. For example, symmetric encryption keys may be used to secure communications between the monitoring client and the patient-care device, such as those generated against cryptographic algorithms such as Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES, IDEA, etc. Additionally or alternatively, various data integrity techniques may be used, such as, for example, CRC, odd parity bit checking, or even parity bit checking.

[0188] Mesh networks are highly scalable, allowing many devices to be used on a single self-forming, self-healing mesh network. Devices connected to the network can communicate with each other and act as repeaters to forward data. Mesh networks are relatively low cost, scalable, and mobile relative to the patients being monitored. In some embodiments, the wireless range for devices linked to the wireless mesh network can reach 70 meters from each node of the system within the facility. Similar networks can be used in providing wireless links within the facility between portable communicators 11 carried by healthcare providers and their assigned patients through patient monitoring clients 1, 4.

[0189] In many cases, the information being communicated to the monitoring client 1 may include a single parameter value (e.g., blood pressure) and a time stamp. The monitoring client 1 may be programmed to determine if the value is outside of a predetermined range, record the value in the patient's EHR 19, and notify the appropriate provider via its monitoring client 11. Additionally, the network allows for bidirectional communication, allowing the monitoring client 1 to query the patient monitoring device (e.g., BP monitor 15) and instruct it to take 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 may be programmed to request a repeat reading to verify the abnormal reading. In another embodiment, the monitoring client 1 may be programmed to interrupt or adjust the flow rate, operating parameters, and / or therapy parameters of the infusion pump 7 depending on the value of the reading received from the monitoring device 14-17. For example, if the BP monitor 15 indicates a blood pressure below a predetermined acceptable range, the monitoring client 1 may be programmed to command the infusion pump 7 to stop the infusion and communicate an emergency notification 12 to the monitoring client 11 of the healthcare provider(s). 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 being pumped during an interval), the processor in the monitoring client 1 can track the cumulative amount delivered and infer the amount of fluid remaining in the medication bag 170. (Alternatively, the processor in the monitoring client 1 or infusion pump 7 can calculate the amount delivered from the infusion rate and the elapsed time of the infusion.)

[0190] When the estimated residual volume reaches a predetermined amount, the monitoring client 1 can send a signal to the infusion pump 7 to reduce its flow rate to avoid drying out the patient's intravenous access 35. For example, the monitoring client 1 can determine if a nurse is scheduled to return at a particular time to change the bag, and rather than alerting and / or sending an alarm that the intravenous fluid will run out before the nurse's scheduled return, the monitoring client 1 can signal the infusion pump 7 to slow 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. A notification can also be sent to the nurse's monitoring client 11 to recommend refilling the intravenous bag 17.

[0191] In some embodiments, operation of the patient-care device progress is indicated by an outer border on the display of the monitoring client 1 to indicate the status and / or progress of the patient-care device. For example, the outer border is displayed on the monitoring client 1 whereby the percentage of the border that is illuminated (e.g., begins to form a fully filled perimeter when the border is filled) indicates the progress of a treatment being performed by the patient-care device, such as the infusion pump 7. The border can be communicated from the infusion pump 7 to the monitoring client 1 in an image format (e.g., JPEG, BMP, etc.) and / or as a percentage completed to the monitoring client 1, where the monitoring client 1 generates the border.

[0192] In some embodiments, a GPS and / or ranging module (e.g., an ultrasound ranging module using time-of-flight estimation) can be installed on the infusion pump 7, the monitoring client 1, the caregiver, and / or the patient. A predetermined setup may require that a predetermined group of infusion pumps 7, monitoring clients 1, the hub 802 of FIG. 8, the caregiver, and / or the patient be at a predetermined distance relative to one another before initiating treatment and / or configuring one of the infusion pumps 7 and / or the monitoring clients 1, in this particular embodiment.

[0193] In some embodiments, the patient-care device 7, 170, 126, 128, 130, 14, 15, 16, 17, 124, or 148, the dock 102 or 104, the monitoring client 1, the hub 802 of FIG. 8 may send soft, hard, and / or non-critical alarms to the remote communicator 11 without alerting on the alarming device and / or the monitoring client 1 until after a predetermined time has elapsed (e.g., 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 is removed before the predetermined time, the alarming device and / or the monitoring client 1 may not alert, thereby preventing additional disturbance of the patient.

[0194] In some embodiments, the AC cable of FIG. 1 includes a clip so that the IV line can be clipped thereto.

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

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

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

[0198] Additionally or alternatively, although certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of certain patient-care devices may be used. For example, in some embodiments, only the infusion pump 7 of the patient-care devices is used, and in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 100 of FIG. 1. Additionally or alternatively, in some particular embodiments, only the patient-care devices that are used may be docked in the device dock 104. For example, in this particular embodiment, the infusion pump 7 is the only device docked in the device dock 102, and only the device dock 102 receives one device, e.g., the infusion pump 7. Additionally, alternatively or optionally, in some particular embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be dockable, may operate undocked, and / or may not be dockable and may operate as standalone patient-care devices.

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

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

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

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

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

[0204] Operation 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 of operation 154 is available, the method 150 proceeds to operation 160, otherwise, the method 150 proceeds to operation 158. Operation 160 determines whether the device dock is available as a communication link between the device dock and the patient-care device, for example, through a wireless or wired communication link. If the communication link of operation 160 is available, the method 150 proceeds to operation 166, otherwise, the method 150 proceeds to operation 162. Operation 162 determines whether the patient-care device is available as a communication link between the monitoring client and the patient-care device dock through a direct wireless link. If the communication link of operation 162 is available, the method proceeds to operation 166, otherwise, the method 150 proceeds to operation 164.

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

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

[0207] 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 a schedule of communication links, but other schedules may be used, broadcast, anycast, multicast or unicast may be used, a routing algorithm may be used, a distance vector routing protocol may be used, a link state routing protocol may be used, an optimized link state routing protocol may be used, a path vector protocol may be used, static routing with predefined alternate communication paths may be used, and / or an adaptive network may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, Dijkstra's algorithm may be used to communicate between the monitoring client 1 and one or more patient-care devices, weight may be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, may be linear with respect to available data throughput or latency, and / or others.

[0208] Referring to the drawings, Figure 3 shows a block diagram of an electronic patient-care system 300 having two docks 102, 104 for wireless communication therebetween, according to another embodiment of the present disclosure. The system 300 is similar to the system 100 of Figure 1, except that the communication between the monitoring-client dock 102 and the device dock 104 is through a wireless link. For example, in some embodiments, the system 300 of Figure 3 is the system 100 of Figure 1 without the cable 110 of Figure 1 being present or inoperative, and in addition or alternatively, the system 300 of Figure 3 can have docks 102 and 104 that are not connectable together using a cable.

[0209] Optionally, the monitoring client 1, other monitoring clients 4, and / or 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, such as bolus amount, infusion rate, total fluid to deliver, start time of drug delivery, stop time of drug delivery, or delivery rate profile to the infusion pump 7, syringe pump 126, and / or microinfusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests to the pill dispenser 128, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, a particular medication may be taken on an as-needed basis (i.e., when needed), but the medication may be unsafe if taken in excess; a maximum pill dispensing criterion may prevent the medication from being taken by a patient at an unsafe level, for example, in a given amount during a given time interval.

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

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

[0212] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to generate an alarm and / or alert. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in downstream pressure of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 as one indication of excessive clotting, seepage, obstruction or kinking of the tubing to the patient, or obstruction by other material in the intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly alert or warn the user. Additionally or alternatively, a sudden drop in downstream pressure to the patient 2 is an indication that the tubing has come off the needle and / or that the needle is now off the patient, and in response, one or more of the monitoring clients 1, 4, 11 may visually or audibly warn or alert a user. One or more of the monitoring clients 1, 4, 11 may optionally send instructions to one or more of the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop delivery of fluid in response to the sudden increase and / or decrease in downstream pressure to the patient 2.

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

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

[0215] Additionally or alternatively, although certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of certain patient-care devices may be used. For example, in some embodiments, only the infusion pump 7 of the patient-care devices is used, and in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 300 of FIG. 3. Additionally or alternatively, in some embodiments, only the patient-care devices that are used may be docked in the device dock 104. For example, in one particular embodiment, the infusion pump 7 is the only device docked in the device dock 102, and only the device dock 102 receives one device, e.g., the infusion pump 7. Additionally, alternatively or optionally, in some particular embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be dockable, may operate undocked, and / or may not be dockable and may operate as standalone patient-care devices.

[0216] 3, the device dock 104 is shown as being capable of receiving several patient-care devices, however, in other embodiments, the device dock 104 can receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices. Also, a compartment of the dock may not be used, for example, as shown in FIG. 3, an empty compartment 170 is shown in the device dock 104. Additionally, while the monitoring-client dock 102 is shown as being 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 arbitrary number of monitoring clients 1.

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

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

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

[0220] Operation 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 of operation 210 is available, method 202 proceeds to operation 212; otherwise, method 202 proceeds to operation 214.

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

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

[0223] Operation 216 attempts a handshake between the monitoring client and the patient-care device using the available communication link(s). In alternative embodiments, a handshake is not attempted, e.g., some communication protocols do not utilize a handshake. Decision operation 220 determines if the handshake is successful and if communication between the monitoring client and the device is established. If operation 220 determines that the communication link is established, method 202 communicates data between the monitoring client and the device during operation 222 using the available communication link(s). If decision operation 220 determines that the handshake was not successful, method 202 determines that communication with the device is not available in operation 218, or method 202 attempts communication between the monitoring client over an unverified communication link (not explicitly shown).

[0224] Method 202 is an exemplary embodiment of the present disclosure that describes a method of maintaining communication between a monitoring client and one or more patient-care devices. In some embodiments, method 202 includes a schedule of communication links, but other schedules can be used, broadcast, anycast, multicast or unicast can be used, a routing algorithm can be used, a distance vector routing protocol can be used, a link state routing protocol can be used, an optimized link state routing protocol can be used, a path vector protocol can be used, static routing with predefined alternate communication paths can be used, and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, a weight can be assigned to each communication path, Dijkstra's algorithm can be used to communicate between the monitoring client 1 and one or more patient-care devices, weight can be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, which may be linear with respect to available data throughput or latency, and / or others.

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

[0226] Optionally, the monitoring client 1, other monitoring clients 4, and / or 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, such as bolus amount, infusion rate, total fluid to deliver, start time of drug delivery, stop time of drug delivery, or delivery rate profile to the infusion pump 7, syringe pump 126, and / or microinfusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests to the pill dispenser 128, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, a particular medication may be taken on an as-needed basis (i.e., when needed), but the medication may be unsafe if taken in excess; a maximum pill dispensing criterion may prevent the medication from being taken by a patient at an unsafe level, for example, in a given amount during a given time interval.

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

[0228] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to generate an alarm and / or alert. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in downstream pressure of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 as one indication of excessive clotting, seepage, obstruction or kinking of the tubing to the patient, or obstruction by other material in the intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly alert or warn the user. Additionally or alternatively, a sudden drop in downstream pressure to the patient 2 is an indication that the tubing has come off the needle and / or that the needle is now off the patient, and in response, one or more of the monitoring clients 1, 4, 11 may visually or audibly warn or alert a user. One or more of the monitoring clients 1, 4, 11 may optionally send instructions to one or more of the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop delivering fluid in response to a sudden increase and / or decrease in downstream pressure to the patient 2.

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

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

[0231] Additionally or alternatively, although certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of certain patient-care devices may be used. For example, in some embodiments, only the infusion pump 7 of the patient-care devices is used, and in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 500 of FIG. 5. Additionally or alternatively, in some particular embodiments, only the patient-care devices that are used may be docked in the dock 502. For example, in one particular embodiment, the infusion pump 7 is the only device docked in the device dock 102, and only the device dock 102 receives one device, e.g., the infusion pump 7. Additionally, alternatively or optionally, in some particular embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be dockable, may operate undocked, and / or may not be dockable and may operate as standalone patient-care devices.

[0232] 5, the dock 502 is shown as being capable of receiving several patient-care devices, however, in other embodiments, the dock 502 can receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices. Also, compartments of the dock may not be in use, e.g., as shown in FIG. 5, an empty compartment 170 is shown in the dock 502. Additionally, while the dock 502 is shown as being 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 arbitrary number of monitoring clients 1.

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

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

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

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

[0237] Operation 314 attempts a handshake between the monitoring client and the device using the available communication link(s). In alternative embodiments, a handshake is not utilized, e.g., some protocols do not utilize a handshake. Decision operation 318 determines whether the handshake was successful, and if so, method 304 proceeds to operation 320 to communicate data using the available communication link(s). If decision operation 318 determines that the handshake was not successful at operation 314, operation 316 determines that communication with the device is not available. In other embodiments, if decision operation 318 determines that the handshake was not successful at operation 314, method 304 attempts to communicate with the patient-care device over an unverified communication link (not explicitly shown).

[0238] Method 304 is an exemplary embodiment of the present disclosure that describes a method of maintaining communication between a monitoring client and one or more patient-care devices. In some embodiments, method 304 includes a schedule of communication links, but other schedules can be used, broadcast, anycast, multicast or unicast can be used, a routing algorithm can be used, a distance vector routing protocol can be used, a link state routing protocol can be used, an optimized link state routing protocol can be used, a path vector protocol can be used, static routing with predefined alternate communication paths can be used, and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, a weight can be assigned to each communication path, Dijkstra's algorithm can be used to communicate between the monitoring client 1 and one or more patient-care devices, weight can be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, which may be linear with respect to available data throughput or latency, and / or others.

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

[0240] Optionally, the monitoring client 1, other monitoring clients 4, and / or 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, such as bolus amount, infusion rate, total fluid to deliver, start time of drug delivery, stop time of drug delivery, or delivery rate profile to the infusion pump 7, syringe pump 126, and / or microinfusion pump 130. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests to the pill dispenser 128, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, a particular medication may be taken on an as-needed basis (i.e., when needed), but the medication may be unsafe if taken in excess; a maximum pill dispensing criterion may prevent the medication from being taken by a patient at an unsafe level, for example, in a given amount during a given time interval.

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

[0242] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any given condition to generate an alarm and / or alert. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in downstream pressure of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 as one indication of excessive clotting, seepage, obstruction or kinking of the tubing to the patient, or obstruction by other material in the intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly alert or warn the user. Additionally or alternatively, a sudden drop in downstream pressure to the patient 2 is an indication that the tubing has come off the needle and / or that the needle is now off the patient, and in response, one or more of the monitoring clients 1, 4, 11 may visually or audibly warn or alert a user. One or more of the monitoring clients 1, 4, 11 may optionally send instructions to one or more of the infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop delivery of fluid in response to the sudden increase and / or decrease in downstream pressure to the patient 2.

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

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

[0245] Additionally or alternatively, although certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of certain patient-care devices may be used. For example, in some embodiments, only the infusion pump 7 of the patient-care devices is used, and in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 700 of FIG. 7. Additionally or alternatively, in some particular embodiments, only the patient-care devices that are used may be docked to the integrated dock 702. For example, in one particular embodiment, the infusion pump 7 is the only device docked within the integrated dock 702, and the integrated dock 702 only receives one device, e.g., the infusion pump 7. Additionally, alternatively or optionally, in some particular embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 may be dockable, may operate undocked, and / or may not be dockable and may operate as standalone patient-care devices.

[0246] 7, the integrated dock 702 is shown as being capable of receiving several patient-care devices, however, in other embodiments, the integrated dock 702 can receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices. Also, a compartment of the dock may not be in use, e.g., as shown in FIG. 7, an empty compartment 170 is shown in the integrated dock 702. Additionally, while the integrated dock 702 is shown as being 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 arbitrary number of integrated monitoring clients 1.

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

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

[0249] In some embodiments, the hub 802 includes 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 can include secure data classes. In yet additional embodiments, the dock 102, 804, and / or 806 includes an API to display a GUI, windows, data, etc. on the monitoring client 1 or the remote communicator 11. In yet additional embodiments, the dock 102, 804, or 806 or the hub 802 includes an API to display a GUI, windows, data, etc. on the patient-care devices 830, 810, and / or 814.

[0250] 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 (the device paired therewith, the device plugged into or docked to the hub 802 and / or docks 102, 804, and / or 806).

[0251] 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.

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

[0253] Optionally, in some particular embodiments, the hub 802 includes all of the 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 the patient 2, independent of any safety checks performed, e.g., elsewhere on the monitoring client 1. In yet further particular embodiments, the system 800 is optionally fully fault-tolerant of the monitoring client 1, and may, for example, ignore instructions, requests, or parameters from the monitoring client 1 if an independent safety check performed therein does not meet a predetermined criteria, e.g., a predetermined safety range for drug delivery of the infusion pump 7.

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

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

[0256] Optionally, the 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, for example, bolus amount, infusion rate, total fluid to deliver, start time of drug delivery, stop time of drug delivery, or delivery rate profile to the patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148. In some embodiments, one or more of the monitoring clients 1, 4, 11 can be used to send instructions or requests to the pill dispenser 814, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, a particular medication may be taken on an as-needed basis (i.e., when needed), but the medication may be unsafe if taken in excess; a maximum pill dispensing criterion may prevent the medication from being taken by a patient at an unsafe level, for example, in a given amount during a given time interval.

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

[0258] Data received from the patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148 can be analyzed for any given condition to generate an alarm and / or alert. For example, one or more of the monitoring clients 1, 4, 11 can use an increase in downstream pressure of one or more of the infusion pumps 830, 810, 812 as an indication of excessive clotting, seepage, obstruction or kinking of the tubing to the patient, or obstruction by other material in the intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly warn or alert the user. Additionally or alternatively, a sudden drop in downstream pressure to the patient 2 is an indication that the tubing has come off the needle and / or that the needle is now off the patient, and in response, one or more of the monitoring clients 1, 4, 11 can visually or audibly warn or alert the user. One or more of the monitoring clients 1, 4, 11 may optionally send instructions to one or more of the infusion pumps 830, 810, 812 to stop delivering fluid in response to a sudden increase and / or decrease in downstream pressure to the patient 2.

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

[0260] Additionally, in some embodiments, although some items, components, devices, patient-care devices, docks, and computing devices, numbered or unnumbered, as shown in FIG. 8 or described herein are shown as only one item, component, device, patient-care device, dock, or computing device, multiple items, components, devices, patient-care devices, docks, and computing devices are contemplated. For example, while a single pill dispenser 814 is shown in FIG. 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. Additionally or alternatively, in some embodiments, multiple docks 804 or 806 and / or multiple monitoring client docks 102 may be used.

[0261] Additionally or alternatively, although certain patient-care devices 830, 810, 812 are shown, other combinations, subsets, multiples, or combinations of the specific patient-care devices may be used. For example, in some embodiments, only the infusion pump 830 of the patient-care devices is used, and in this particular example, the other patient-care devices 810, 812, 814 may be disabled, not present or available for system use, powered down, or not part of the system 800 of FIG. Additionally or alternatively, in some particular embodiments, only the patient-care device being used is dockable to dock 804 or 806. For example, in one particular embodiment, infusion pump 830 is the only device docked in dock 804, and dock 804 only receives one device, e.g., infusion pump 830.

[0262] 8, the dock 804 is shown as being capable of receiving several patient-care devices, in other embodiments, the device dock 804 may receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices, and compartments of the dock may not be in use (not shown in FIG. 8). Additionally, although the monitoring-client dock 102 is shown as being 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 arbitrary number of monitoring clients 1. Additionally, alternatively or optionally, in some particular embodiments the patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814 can be dockable, can operate undocked, and / or can be non-dockable and operate as stand-alone patient-care devices.

[0263] The system 800 of FIG. 8 may use any known communication method for maintaining communication therewith. For example, in some embodiments, any communication schedule may be used, broadcast, anycast, multicast or unicast may be used, a routing algorithm may be used, a distance vector routing protocol may be used, a link state routing protocol may be used, an optimized link state routing protocol may be used, a path vector protocol may be used, static routing with predefined alternate communication paths may be used, and / or an adaptive network may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, 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), and the weight may be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, may be linear with respect to available data throughput or latency, and / or the like.

[0264] In an embodiment of the present disclosure, the equipment service 8 and / or the adverse drug event network 9 may also comprise a medication error reduction system (DERS). The DERS system may include a first set of predefined criteria for triggering a soft alarm and / or a second set of predefined criteria for triggering a hard alarm. A soft alarm may be overridden (e.g., turned off) by a caregiver using the user interface of the infusion pump 830, the user interface 808 of the hub 802 and / or the user interface of the monitoring client 1 (or may be only an audible and / or vibration alarm), while a hard alarm suspends treatment until the cause of the hard alarm is removed.

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

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

[0267] 9 illustrates a block diagram of an electronic patient-care system 900 having a stackable monitoring client 902, a stackable infusion pump 904, a stackable syringe pump 906, and another stackable patient-care device 908 in accordance with yet another embodiment of the present disclosure. 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).

[0268] Optionally, the monitoring client 902, other monitoring clients 4, and / or remote communicator 11 can be used to send instructions or requests to the patient-care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148, such as to send a bolus amount, an infusion rate, a total fluid to be delivered, a start time for drug delivery, a stop time for drug delivery, or a delivery rate profile to the stackable infusion pump 904, the stackable syringe pump 906, and / or other stackable patient-care devices 908. In some embodiments, one or more of the monitoring clients 902, 4, 11 can be used to send instructions or requests to the pill dispenser 128, such as, for example, pill dispensing instructions for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, a particular medication may be taken on an as-needed basis (i.e., when needed), but the medication may be unsafe if taken in excess; a maximum pill dispensing criterion may prevent the medication from being taken by a patient at an unsafe level, for example, in a given amount during a given time interval.

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

[0270] Data received from the patient-care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 can be analyzed for any predetermined condition to generate an alarm and / or alert. For example, one or more of the monitoring clients 902, 4, 11 can use an increase in downstream pressure of the stackable infusion pump 904 and / or stackable syringe pump 906 as one indication of excessive clotting, seepage, obstruction or kinking of the tubing to the patient, or obstruction by other material in the intravenous bag 170. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 902, 4, 11 can visually or audibly alert or alert the user. Additionally or alternatively, a sudden drop in downstream pressure to patient 2 is an indication that the tubing has come off the needle and / or that the needle is now off the patient, and in response, one or more of the monitoring clients 902, 4, 11 can visually or audibly warn or alert a user. One or more of the monitoring clients 902, 4, 11 can optionally send instructions to one or more of the stackable infusion pump 904 and / or stackable syringe pump 906 to stop delivering fluid in response to a sudden increase and / or decrease in downstream pressure to patient 2.

[0271] 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, such that the bottom connector of the stackable syringe pump 906 is electrically coupled to the top connector of the monitoring client 902.

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

[0273] Additionally or alternatively, the stackable devices 902, 908, 904, 906 can optionally maintain wireless communication with one another. For example, the stackable monitoring client 902 can detect that the daisy-chained conductors are electrically unresponsive due to an internal short in one of the stackable devices 902, 908, 904, 906, and the stackable monitoring client 902 can query each stackable device 908, 904, 906 to determine which device has failed. After making the determination, the stackable monitoring client 902 can wirelessly communicate with an isolated disconnect circuit in the failed one of the stackable devices 902, 908, 904, 906 to electrically disengage the failed device from the daisy-chained conductors. Additionally or alternatively, one or more of the stackable devices 902, 908, 904, 906 may send an alert, and / or display a message to warn that one of the stackable devices 902, 908, 904, 906 has failed and / or that one of the stackable devices 902, 908, 904, 906 communicates wirelessly rather than via a daisy-chained wired communication link.

[0274] Additionally or alternatively, the stackable monitoring client 902, stackable device 908, stackable infusion pump 904, and stackable syringe pump 906 may each relay or re-communicate information to the respective device below or above it in the daisy chain. For example, the stackable infusion pump 904 may communicate all of the data received from the stackable syringe pump 906 by buffering the data in an internal memory and communicating the information when the stackable patient-care device 908 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 numbered or unnumbered item, component, device, patient-care device, dock, and computing device as shown in FIG. 8 or described herein is optional. For example, in some embodiments, the monitoring client 1 is optional, the monitoring server 3 is optional, the facility service 8 is optional, each of the services 19, 20, 21, 22, 23, 24 is optional, the cloud server 25 is optional, each of the other monitoring clients 4 is optional, the online drug database 9 is optional, the adverse drug events network is optional, the patient's personal EHR 19' is optional, and / or the treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each of the patient-care devices 830, 810, 812 is optional. Similarly, each of the system monitor 131, wrist band 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power are optional in some embodiments of the present disclosure.

[0275] Additionally, in some embodiments, some items, components, devices, patient-care devices, and computing devices, numbered or unnumbered, as shown in Figure 9 or described herein are shown as sole items, components, devices, patient-care devices, or computing devices, although multiple items, components, devices, patient-care devices, and computing devices are contemplated. For example, while a single pill dispenser 128 is shown in Figure 9, in some embodiments, two pill dispensers 128 may be used, multiple pill dispensers 128 may be used, or any arbitrary number of pill dispensers 128 may be used.

[0276] Additionally or alternatively, although certain patient-care devices 904, 906, 908 are shown, other combinations, subsets, multiples, or combinations of certain patient-care devices may be used. For example, in some embodiments, only the stackable infusion pump 904 of the patient-care devices is used, and in this particular example, the other patient-care devices 906, 908 may be disabled, not present or available for system use, powered down, or not part of the system 900 of FIG. 9. Additionally or alternatively, in some particular embodiments, only the patient-care devices that are used are stacked. For example, in one particular embodiment, the infusion pump 904 is the only device that is stacked. Additionally or alternatively, the patient-care devices that are not stacked, such as patient-care devices 904, 906, and / or 908, may continue to operate if they are operating as stand-alone devices. Additionally, alternatively or optionally, in some particular embodiments, patient-care devices 14, 15, 16, 17, 35, 904, 906, 908, 128, 148 may be dockable, may operate undocked, and / or may not be dockable and may operate as standalone patient-care devices.

[0277] 9, the stack is shown as being capable of stacking several patient-care devices, in other embodiments the stack can receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices. Additionally, while the stack is shown as being capable of receiving one monitoring client 902, in other embodiments two stackable monitoring clients 902, three or more stackable monitoring clients 902, or any arbitrary number of stackable monitoring clients 902 are stacked in the system 900.

[0278] The system 900 of FIG. 9 may use any known communication method for maintaining communication therewith. For example, in some embodiments, any communication schedule may be used, broadcast, anycast, multicast or unicast may be used, a routing algorithm may be used, a distance vector routing protocol may be used, a link state routing protocol may be used, an optimized link state routing protocol may be used, a path vector protocol may be used, static routing with predefined alternate communication paths may be used, and / or an adaptive network may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, Dijkstra's algorithm may be used to communicate between the monitoring client 902 and one or more patient-care devices (e.g., patient-care devices 904, 906, 908), and weight may be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, may be linear with respect to available data throughput or latency, and / or the like.

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

[0280] In some embodiments, the hub, dock, device, insulin pump, infusion pump, and / or patient-care device may be or may have web-connected remote interface capabilities, which may include, but are not limited to, the ability to download applications, download software updates, upload information, and / or transmit information to various machines through a web-based secure portal, and / or through 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. Additionally, in some embodiments, the remote interface may be Bluetooth enabled or otherwise enabled to communicate, e.g., using radio frequency (RF) communications, with one or more devices, which may include, but are not limited to, one or more of the hub, dock, device, insulin pump, infusion pump, patient-care device, Bluetooth or other communication device, patient-care device, and / or any other device.

[0281] In some embodiments, the charging station can include a charging area for the hub, dock, device, insulin pump, infusion pump, and / or patient-care device to a remote interface that can include a USB plug. In some embodiments, the charging station can include a USB port, and in some embodiments, a mini-USB port, which can enable the charging station to receive power to charge the hub, dock, device, insulin pump, infusion pump, patient-care device, and / or remote interface through USB. Additionally and / or alternatively, the USB port can be configured for data transfer to / from the remote interface and / or hub, dock, device, insulin pump, infusion pump, and / or patient-care device by connection to a computer or other device and / or computer-type equipment. In embodiments that include a USB port, while the remote interface is charging, the system can call a personal computer and / or web portal to check for updated software and, if there is updated software available, can download the software update via the USB connection, for example. These updates can then be transferred to the hub, dock, device, insulin pump, infusion pump, and / or patient-care device upon pairing.

[0282] Thus, a user may connect a remote interface of a hub, dock, device, insulin pump, infusion pump, and / or patient-care device to a personal computer and / or in some embodiments may upload data from the remote interface to a web portal or the like. In some embodiments, this may be accomplished during "recharging" of the remote interface, which may be done in some embodiments using a USB connection to a personal computer, which may sync and / or upload / download data from the personal computer, 1908, and / or web portal in addition to charging / recharging the remote interface. At this time, the system may determine if software updates are available for one or more of the devices and / or remote interfaces. A user may select "update downloads" and these may be downloaded to the remote interface of a hub, dock, device, insulin pump, infusion pump, and / or patient-care device when charging and / or any time the remote interface is connected, either directly or indirectly, to a personal computer and / or a web portal specifically designated for the system. As discussed above, the remote interface is capable of communicating with a variety of devices. Thus, software updates can be communicated to any one or more of the devices of the remote interface. This has many advantages including, but not limited to, simply having the remote interface connected to a personal computer / web portal to both upload data / information from all of the devices and / or download updates and / or applications from the personal computer and / or from the internet / web portal to any of the devices. This may be desirable for a number of reasons, including, but not limited to, the ability to efficiently and easily update all devices from one connection, and / or the ability to view all of the data from all devices in one location, and / or the ability to download information and / or settings from a personal computer / web portal to any of the devices via a remote interface.

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

[0284] This also allows the remote interface to download any application from the internet to any device in the system. Thus, in various embodiments of the system, a user can turn any device (including several parameters such as the ability to wirelessly communicate and connect to a personal computer and / or web portal) into a device that can control various devices, such as an infusion pump, and / or receive data from and / or control a CGM sensor / transmitter, and / or other analyte 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 password or otherwise protected and paired with one or more devices, such as an infusion pump and / or a CGM sensor and / or one or more other devices.

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

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

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

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

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

[0290] Act 705 communicates a plurality of patient-care parameters from a plurality of patient-care devices to a monitoring server. Act 707 de-identifies the patient-care parameters, and act 709 stores the patient-care parameters in a database in the monitoring server, such as an SQL database, a relational database, an associative database, or the like. Act 707 can be performed automatically and / or electronically. Act 711 treats a subset of the patients of the plurality of patients. For example, patients with high blood pressure can be treated with a drug designated to lower blood pressure. Act 713 analyzes a subset of the plurality of patient-care parameters associated with the plurality of patients to determine the effectiveness of the treatment. For example, all patients who received the blood pressure drug of act 711 can have their blood pressure compared to a blood pressure reading after a predetermined time, such as six months, to determine if the treatment is effective for the patient or patients.

[0291] 12 is a flow chart diagram of a method 801 of patient-care device recovery when operation of the patient-care device is interrupted, according to an embodiment of the present disclosure. For example, the patient-care device may be undocked, lose power, a hardware or software failure may temporarily disable one or more processors or other circuitry within the patient-care device, etc. Additionally or alternatively, one or more processors on the patient-care device may implement method 801 such that the patient-care device is hot-swappable.

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

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

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

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

[0296] Act 815 determines that operation of the patient-care device has been interrupted, e.g., power to the patient-care device has been lost, a fault has occurred in the patient-care device, a brownout CPU reset has occurred, etc. Act 817 determines that operation of the patient-care device can be resumed.

[0297] An act 819 loads the one or more received or calculated operating parameters into the operating memory of the patient-care device, and an act 821 loads the one or more patient-care parameters into the operating memory of the patient-care device. An act 823 resumes operation of the patient-care device.

[0298] 13, a flow chart diagram of a method 900 for pairing a monitoring client having a user interface to a patient-care device is shown according to an embodiment of the present disclosure. Method 900 includes operations 902-912. The monitoring client of method 900 may be the monitoring client 1 or remote communicator 11 of FIG. 1, 3, 5, 7, or 8, the monitoring client 902 of FIG. 9, the remote communicator 11 of FIG. 1, 3, 5, 7, 8, or 9, a mobile phone, a handheld computer, a tablet computer, a laptop computer, a personal computer, a personal digital assistant, or the like. Although method 900 describes pairing between a monitoring client and a patient-care device, in some embodiments, method 900 may be used to pair a hub (e.g., hub 802 of FIG. 8) to a patient-care device (e.g., patient-care devices 830, 810, 812, and 814), pair a first patient-care device (e.g., patient-care device 830 of FIG. 8) to a second patient-care device (e.g., patient-care device 814 of FIG. 8), thereby allowing a user interface of the first patient-care device to control the second patient-care device. 8, and / or patient-care devices 904, 906, 908, 14, 15, 16, 17, or 148 of FIG. 9).

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

[0300] Act 908 pairs the patient-care device to the monitoring client. For example, pairing the patient-care device to the monitoring client can utilize Bluetooth, Bluetooth Low Energy (IEEE 802.15.1), WiFi, infrared communication, near field communication (NFC ISO 13157), IR communication, or optical. A custom pairing protocol can be utilized that may or may not utilize a handshake sequence, as will be apparent in view of this disclosure. Act 910 communicates patient-care parameters between the patient-care device and the monitoring client, for example, such that the patient-care device can be controlled or monitored by the monitoring client.

[0301] OPERATION 912 optionally operatively communicates additional patient-care parameters with, through, another patient-care device. In OPERATION 912, if the patient-care device is operatively coupled to, or in operative communication with, another patient-care device, the patient-care device may act as a relay or router, thereby allowing the monitoring client to communicate with the other patient-care device. Additionally or alternatively, the patient-care device may use information from another patient-care device for its operation, e.g., an infusion pump may use a flow rate determined by a flow meter, or a temperature from a temperature probe, and / or the infusion pump may relay information from the flow meter to the monitoring client. Additionally, the monitoring client may optionally communicate with multiple patient-care devices coupled to the paired patient-care device, either in parallel or in series. Additionally or alternatively, in some embodiments of the present disclosure, in method 900, the monitoring client communicates with the patient-care device using an intravenous line. Communication may occur via electrical conductors embedded or attached to the venous line, via electrical communication using the fluid in the venous line as a conductive medium, using sound waves traveling through the venous line, or optically using the fluid in the line as an optical waveguide. Communication through the venous line may be used to set up pairing (e.g., between the monitoring client, hub, dock, patient-care device and / or system monitor with one or more of the monitoring client, hub, dock, patient-care device and / or system monitor) using another communication link, e.g., Bluetooth, Bluetooth low energy, WiFi, etc.

[0302] In yet additional embodiments of the present disclosure, pairing of a first device (e.g., a monitoring client, hub, patient-care device, or system monitor) with a second device (e.g., a monitoring client, hub, patient-care device, or system monitor) can be configured and / or initialized using a first communication link, whereby the devices are paired using a second communication link. For example, near-field or IR communication can set up pairing between the devices, e.g., using Bluetooth, Bluetooth low energy, or WiFi. Setting up the pairing (e.g., via near-field or IR communication) can dictate a request on the monitoring client, hub, patient-care device, and / or system monitoring to request user confirmation of the pairing devices, e.g., pairing via Bluetooth. In some embodiments, when a patient-care device is paired to a hub, monitoring client, and / or dock, an ID and software version number are sent to the hub, monitoring client, and / or dock which checks with 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, and if the software is not up to date, the hub, monitoring client, dock, or the patient-care device itself (e.g., directly) downloads the update software to program the patient-care device. The patient-care device can communicate to the user if the software is up to date and / or can give the user an option on a touch screen to optionally update the patient-care device if the software is not up to date. The communication link that sets up the pairing (e.g., NFC) and / or the communication link that uses the pairing (e.g., Bluetooth or Bluetooth low energy) can communicate the update software, ID, software version number, provide notifications, etc.For example, one pairing that may be used in a pump patient care device or insulin pump is disclosed in (1) a patent application entitled "INFUSION PUMP METHODS AND SYSTEMS" by Mandro et al., filed March 25, 2010, Attorney Docket No. I06, Ser. No. 12 / 731,843; (2) a patent application entitled "METHODS AND SYSTEMS FOR CONTROLLING AN INFUSION PUMP" by Bryant et al., filed April 4, 2009, Attorney Docket No. G98, Ser. No. 12 / 416,662; and / or (3) a patent application entitled "INFUSION PUMP ASSEMBLY" by Kamen et al., filed December 31, 2009, Attorney Docket No. G75, Ser. No. 12 / 347,985. No. 6,399,363, and entitled "Method and Implement of a Novel Fluorescent Lamp Array," all of which are incorporated herein by reference.

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

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

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

[0306] The system monitor of method 1000 may be used in system 100 of FIG. 1, system 300 of FIG. 3, system 500 of FIG. 5, system 700 of FIG. 7, system 800 of FIG. 8, system 900 of FIG. 9, may be used in a stand-alone system, and / or may be used in any other sufficient system or group of devices disclosed herein.

[0307] Act 1014 identifies the caregiver (e.g., provider) using one or more of a voice recognition algorithm, a facial recognition algorithm, a bar code, an RFID tag, near field communication, a simple login, a secure signature, and the like. For example, the caregiver identification in act 1040 can be performed by a monitoring client, a monitoring client docking station, a device docking station, a communication module, another dock, or a hub using an on-board camera and / or microphone. Also, as a safety check, the monitoring client, hub, dock, or patient-care device can request that the user type in a font as displayed to prevent font corruption errors. Additionally or alternatively, in some embodiments, after one or more failed logins or authentications, the device can take a picture and, if possible, store the picture, the picture can be communicated to a middleware server for storage. Act 1016 records the presence of the caregiver on one or more of the devices 1002-1012. The log entry may be stored in any one of the devices 1002-1012, a patient-care device described herein, a monitoring client described herein, a wearable system monitor described herein, a remote communicator described herein, and / or a hub described herein. The log of operation 1016 may be for caregiver compliance, diagnostic purposes, etc. For example, if a caregiver is scheduled to show up but does not show up, operation 1016 may record that the caregiver did not show up at the scheduled time.

[0308] The facial recognition algorithm of act 1014 may relay any caregiver's facial features, such as analyzing the relative size, shape, eye position, nose, chin, cheekbones, or other facial features. The facial recognition algorithm of act 1014 may use three-dimensional facial recognition, skin texture analysis, or other facial recognition algorithms. Additionally or alternatively, in some embodiments, the speech recognition algorithm of act 1014 may use hidden Markov models, dynamic time warping based speech recognition, or other speech recognition algorithm(s).

[0309] Act 1018 removes the wearable system monitor from the wearable dock. For example, system monitor 131 of FIG. 1 may be worn on a patient's arm, and thereby attached to the patient with a wrist band similar to that of a watch, and a portion of the wearable system monitor may be removed from the wrist band and a dock (also referred to herein as a "wearable dock") with a snap-fit ​​base member into which the wearable system monitor snaps. When the wearable system monitor is removed from its dock, act 1020 starts a timer. The timer and associated acts are each optional in method 1000 of FIG. 14.

[0310] A timer in act 1020 keeps track of the time the wearable system monitor is out of its dock. Act 1022 stops the therapy if a predetermined amount of time has elapsed after undocking the wearable system monitor from the wearable dock. For example, the wearable system monitor of method 1000 can send a signal to the infusion pump to stop pumping. When the wearable system monitor is docked again, act 1024 resumes therapy if it was interrupted, for example, by undocking the wearable system monitor from its wearable dock after a predetermined amount of time has elapsed.

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

[0312] Act 1028 determines whether the caregiver is authorized to pair the wearable system monitor, e.g., pair the wearable system monitor to a patient-care device. If the caregiver is not authorized, then method 1000 prevents additional pairing of the wearable system monitor (or editing of the pairing settings). If the caregiver is authorized to pair the wearable system monitor, act 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 a particular treatment is being administered to the correct patient and / or to provide compliance with a given regulation.

[0313] 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 act 1030, the caregiver selects a wearable system monitor (e.g., the patient wearable system monitor of act 1018) and a patient-care device to pair with each other. Act 1032 pairs the wearable system monitor with the patient-care device, and act 1034 records the pairing of act 1032 in the wearable system monitor, including 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 in parallel or serial pairing of the patient-care device with another device (e.g., a monitoring client, a hub, another patient-care device, etc.). As will be appreciated in view of this disclosure, any suitable pairing protocol (e.g., Bluetooth or IEEE 802.11) may be used. Additionally or alternatively, operation 1034 may record the pairing within one or more of the devices 1002-1012.

[0314] Act 1036 reattaches the wearable system monitor to the wearable dock. Act 1038 identifies and authenticates the wearable dock using the wearable system monitor, e.g., to determine if 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 mistake and (in some embodiments) prevent the associated therapy from proceeding by signaling the patient-care device associated with the patient-care device to stop operation and send an alert to a monitoring client, e.g., monitoring clients 1, 4, or 11 of FIG. 1, 3, 5, 7, 8, monitoring clients 9, 4, or 11 of FIG. 9, or other monitoring clients disclosed herein. Act 1024 can resume treatment if it was interrupted, or act 1040 can treat the patient according to any updated settings 1040 .

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

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

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

[0318] Although method 1100 describes using a user interface template in a monitoring client, the monitoring client may be replaced with a hub, a communication module, another patient-care device, or any other sufficient device having a user interface. The user interface template of the user interface of method 1100 provides a particular area on a given display for displaying a patient-care parameter. For example, a user interface template for an infusion pump may define a particular area for displaying on the GUI, such as a current fluid flow rate. The user interface template may also define an area on the display of the monitoring client for displaying a current fluid flow rate, as received from an infusion pump. The user interface template may include layout information, such as instructions on how to display information, descriptions of various widgets, various widgets, graphs, labels for the graph axes, labels for the display, buttons, and / or labels for providing control or visual information to a user of 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.

[0319] Act 1102 identifies or selects a patient-care device for communication with a monitoring client having a user interface. For example, in act 1102, the monitoring client may automatically identify a pre-defined infusion pump previously designated by a provider for the patient's treatment. Additionally or alternatively, in act 1102, the provider may be provided with a list of patient-care devices from which to select for displaying information regarding the operation of the selected patient-care device(s) on the user interface of the monitoring client.

[0320] Act 1104 determines whether the patient-care device has a stored user interface template. For example, an infusion pump may include a flash memory in which a user interface template is stored. If the patient-care device has a stored user interface template, act 1106 communicates the stored user interface template from the patient-care device to a monitoring client having a user interface. Act 1108 displays the user interface template on a user interface of the monitoring client. Act 1110 communicates patient-care parameters between the patient-care device and the monitoring client. Act 1112 displays the patient-care parameters on the displayed user interface template according to the user interface template. For example, a user interface template for an infusion pump may include a space for a current infusion rate, and act 1112 displays the current infusion rate (a patient-care parameter) on the display using the user interface template, in this example.

[0321] If act 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 to use to display the patient-care parameters of the patient-care device, and act 11004 may additionally or alternatively generate an alarm via the monitoring client and / or the patient-care device. act 1114 determines the type of the patient-care device. If the type is determined, act 1116 determines whether a user interface template is stored in the monitoring client according to the type of the patient-care device. If there is a user interface template, act 1118 displays the user interface template on the user interface of the monitoring client. act 1120 communicates the patient-care parameters between the patient-care device and the monitoring client. act 1122 displays the patient-care parameters on the displayed user interface template according to the user interface template. For example, the patient-care parameters, such as an infusion rate, may be displayed within a predefined area of ​​the user interface as specified by the user interface template.

[0322] If no type is determined in act 1114 or a user interface template is not located in the monitoring client based on the determined type, then act 1124 displays a selectable list of a plurality of user interface templates on a user interface of the monitoring client, and additionally or alternatively act 1114 may raise an alarm or alert via the monitoring client and / or the patient-care device. Act 1126 allows a user to select a user interface template from the plurality of user interface templates using the user interface of the monitoring client. Act 1128 displays the user interface template on the user interface of the monitoring client. Act 1130 communicates the patient-care parameters between the patient-care device and the monitoring client. Act 1132 displays the patient-care parameters on the displayed user interface template according to the user interface template.

[0323] In some embodiments of the present disclosure, the patient-care device of method 1100 can also store one or more fonts for display on the monitoring client, for example, using the user interface templates described above. The fonts can be stored in any format, such as JPEG, BMP, image formats, prestored fonts, etc., and communicated for use within a field to provide a display of the operational parameter (e.g., rather than communicating a value, an image is communicated showing a number or value that is then displayed on the monitoring client). In some embodiments, a font stored within the monitoring client can be used, whereby a value of the operational parameter is sent to the monitoring client for display within the template using a font stored within the monitoring client.

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

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

[0326] Act 1136 docks the patient-care device into the dock. For example, infusion device 7 of Figures 1, 3, 5, or 7, infusion device 830, 810, or 812 of Figure 8, or infusion device 904 of Figure 9 may be docked into the respective dock. Act 1138 identifies the patient-care device to the monitoring client. For example, the patient-care device may communicate, for example, an ID number, serial number, description, prescription, treatment plan, patient treatment parameters, etc., to the monitoring client, for example, via a discovery protocol. The docked patient-care devices may store therein treatment information (e.g., drug amount, infusion rate, total fluid amount, or other patient treatment parameters) that may be associated with or correspond to a patient, respectively.

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

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

[0329] The request may optionally originate from any authorized, authenticated, and / or identified monitoring client, such as, for example, monitoring client 1 or 4 of FIG. 1, 3, 5, 7, or 8, remote communicator 11 of FIG. 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.

[0330] Act 1202 submits a request for a patient-care device using a user interface of the monitoring client. For example, using a touch screen of the monitoring client 1 of FIG. 1, a user submits an infusion rate to the infusion pump 7. In some embodiments, the request may optionally include parameters related to the patient-care device, such as a bolus amount, an infusion rate, a total fluid to deliver, a start time for drug delivery, a stop time for drug delivery, a delivery rate profile, pill dispensing instructions for dispensing pills, a pill type, a pill dispensing schedule, and / or a maximum pill dispensing criterion.

[0331] Act 1204 is optional and may display a "pending request" on a user interface of the monitoring client. Act 1206 formats the request for the patient-care device. For example, act 1206 may prepare the request to match the communication requirements of the patient-care device.

[0332] Operation 1208 determines a check value for the request, for example using a cyclic redundancy check algorithm to determine a check value corresponding to the request, where the check value calculated by the cyclic redundancy check algorithm is request dependent. A change in one bit in the request also changes the check value calculated by the cyclic redundancy check algorithm. Similarly, a change in several bits also changes the check value. Additionally or alternatively, other embodiments may use a parity bit (even or odd) or other data integrity check.

[0333] Act 1210 appends a check value to the request. Act 1212 is optional and acts 1212 requests confirmation from the user to communicate the request using a user interface. The request for confirmation may be a pop-up dialog box on a touch screen displaying "Did you confirm the 90 ml / hr infusion rate?" with a box for selecting "Confirm". The text and format shown in act 1212 may be in a different font, a different font size, and / or a different display location than other display information, such as that displayed during input of the request, to provide additional safeguards against bad display pixels, corrupted font tables, user misinterpretation, and the like. Act 1214 confirms the request for communication of the request using a user interface. The user may touch the "Confirm" box to confirm the request for communication of the request according to some embodiments of the present disclosure.

[0334] Act 1216 communicates the request to a patient-care device. The communication can be via wired, wireless, inductive, or fiber optic communication, etc. During act 1216, the patient-care device receives the request. During the passage of the request, one or more bits in the request may be corrupted, e.g., the value of the bit may change, a bit may be lost, a bit may be added, etc., and such or other data corruption may be undesirable.

[0335] Operation 1218 of method 1200 facilitates detection of corrupted data. During operation 1218, the patient-care device authenticates the check value according to the request. In operation 1218, the patient-care device can use the same cyclic redundancy check algorithm as operation 1208 on the request to calculate an additional check value. The check value of operation 1216 as calculated by the patient-care device is identical to the check value calculated in operation 1208 only if the data in the request is identical. That is, the check value of operation 1216 and the check value of operation 1208 differ only if the data of the request is corrupted, has fewer or more bits, or is not identical to the digital data used to determine the check value of operation 1208.

[0336] If the check value of the request is not authenticated, then in act 1222, the patient-care device requests retransmission of the request from the monitoring client. Although FIG. 17 shows act 1222 as proceeding to act 1204 of method 1200, in other embodiments, method 1200 may proceed to any of acts 1202-2116. If the retransmission of the request is unsuccessful, method 1200 may communicate an error, alarm, or warning (not shown) to the monitoring client. Alternatively, if the check value is authenticated as not indicating data corruption, then in act 1220, the patient-care device makes the request.

[0337] In an alternative embodiment, the request of operation 1218 may additionally be sent back to the monitoring client after authentication from the patient-care device and may include an additional CRC check during transmission. The authenticating patient-care device may check in this alternative embodiment to determine if the request is within a predefined range (e.g., is the infusion rate safe for a particular drug, etc.). The monitoring client may compare the request received from the patient-care device to the original request stored in memory (so the requests can be correlated with each other) and / or the monitoring client may display the request to the user for confirmation in this alternative embodiment. The request for confirmation may be a pop-up dialog box on a touch screen that displays "Did you confirm the infusion rate of 90 ml / hr?" with a box to select "Confirm". The text and format shown in this alternative embodiment for the confirmation may be in a different font, a different font size, and / or a different display location than other display information, such as displayed during entry of the request, to provide additional safeguards against bad display pixels, corrupted font tables, user misinterpretation, etc. In this alternative embodiment, the user may confirm the request for communication of the request using a user interface. The user may touch a "confirm" box to confirm the request for communication of the request, according to some embodiments of the present disclosure.

[0338] In this alternative embodiment, the request is then resent to the patient-care device to be made; in addition, or as an alternative, in this alternative embodiment, an action message is sent to the patient-care device, the action message including information linking it to the original request (e.g., "This is an 'action' for the 90 milliliters / hour request that was just sent").

[0339] 18 is a block diagram of an electronic patient-care system 1300 according to yet another embodiment of the present disclosure. The system 1300 includes a monitoring client 1302, a dock 1304, and a wireless dock 1306. Optionally, in some embodiments, the dock 1304 can act as a hub as described herein.

[0340] The patient-care device may be any patient-care device disclosed herein, such as patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of Figures 1, 3, 5, or 7, patient-care device 14, 15, 16, 17, 830, 810, 812, 814 of Figure 8, or one of patient-care devices 14, 15, 16, 17, 904, 906, 908 of Figure 9. The monitoring client 1302 may be replaced by any monitoring client described herein, such as monitoring client 1, 4, or 11 of Figures 1, 3, 5, 7, 8, monitoring client 9, 4, or 11 of Figure 9, a tablet, a smart phone, a PDA, etc.

[0341] The dock 1304 may include a receiving portion configured to receive the monitoring client 1302 to connect electrical contacts of the monitoring client 1302 to the dock 1304 through a cable 1308. The cable 1308 may be integrated with the dock 1304 and / or the monitoring client 1302. The cable 1308 may provide, for example, USB or other standard communications between the dock 1304 and the monitoring client 1302.

[0342] The dock 1304 optionally includes a processor 1301, a sensor 1309, a watchdog 1310, a charger 1312, a battery 1314, and an alternating current (AC) power cord 1316. The processor 1301 controls the operation of the dock 1304. A patient-care device 1318 is dockable to the dock 1304. The system 1300 also includes a wireless dock 1306 having a patient-care device 1320 docked thereto. The wireless dock 1306 may be the same or similar to the dock 1304, however, the wireless dock 1306 in some embodiments communicates wirelessly with the monitoring client 1302.

[0343] The battery 1314 can power the dock 1304 and the patient-care device 1318 when the AC power cord 1316 is unplugged from an AC outlet (not shown). In some embodiments, the dock 1304 can be the only power source for the monitoring client 1302 or the patient-care device 1318. Additionally or alternatively, the monitoring client 1302 and / or the patient-care device 1318 can include on-board batteries or a separate AC power cord (not shown).

[0344] In some exemplary embodiments, the dock 1304 can provide IEC-60601 compliant power to the patient-care device 1318. Additionally or alternatively, the dock 1304 can provide a variable DC voltage as required by the patient-care device 1318. For example, the dock 1304 can include a programmable buck-boost power supply (not shown) that can provide a DC voltage from 1 volt to 24 volts as required by the patient-care device 1318 to a particular connector pin of the connector 1322.

[0345] The battery 1314 can be charged by the charger 1312 when the power cord 1316 is plugged into an AC outlet (not shown). The battery 1314 provides uninterrupted power to the patient-care device 1318 when the AC power cord 1316 is unplugged from the AC outlet (not shown). For example, the patient-care device 1318 may be an infusion pump that continues to operate after the AC power cord 1316 is unplugged because the battery 1314 automatically provides replacement power to the patient-care device 1318 after the AC power cord 1316 is unplugged.

[0346] The sensors 1308 may optionally include one or more of an ambient temperature sensor, an ambient pressure sensor, an ambient humidity sensor, etc. The sensors 1308 may optionally include redundant sensors, such as two temperature sensors, which the dock 1304 may use to determine if one or both are faulty, for example, by comparing the readings of the two sensors to one another. The dock 1304 may communicate with the sensors 1308 and / or other peripherals to ensure its proper operation, to perform data integrity checks, and to provide its measurements, e.g., ambient temperature, to the patient-care device 1318.

[0347] The watchdog 1310 can optionally make the above inquiries and have feedback that the patient-care device 1318 is operating properly by monitoring the output of the patient-care device 1318 to determine if it is within a predetermined range (e.g., a range that is physically possible or likely) or is operating properly. Additionally or alternatively, the system monitor 13010 can optionally monitor the operation of the monitoring client 1302 through the cable 1308. Although one watchdog 1310 is described herein, one or more watchdogs 1310, e.g., multiple watchdogs 1310, can also be used. In some exemplary embodiments, the patient-care device 1318 communicates with the watchdog 1310 at fixed intervals. The fixed intervals are optionally configurable using a user interface of the monitoring client 1302 or using a computer attached to the cable 1308. If the patient-care device 1318 fails to communicate with the watchdog 1310 within the fixed interval, the watchdog 1310 determines that an error has occurred within the patient-care device 1318 and issues an alert or alarm, such as an audible sound using the speaker 1324 or flashes red an LED 1326. The reaction actions to not receiving communication within the interval can be configurable and / or programmed, for example, using a user interface of the monitoring client 1302 or using a computer attached to the cable 1308. For example, in a non-critical patient-care device, failure to respond to the watchdog 1310 may cause the LED 1326 to flash red, while action on a critical patient-care device may additionally alert and send audible and visual notifications to the dock 1304 and / or monitoring client 1302, a nurse's station, and / or a remote communicator, such as the remote communicator 11 of Figures 1, 3, 5, 7, 8, or 9, a smart phone, a laptop computer, another patient-care device, etc.Additionally or alternatively, the LED 1326 may optionally flash green if the patient-care device 1326 is operating properly or is currently treating a patient. Additionally or alternatively, a speaker in the monitoring client 1302 may sound an audible warning or alarm. If appropriate, the patient-care device may be disabled or replaced until the error condition is resolved.

[0348] Additionally or alternatively, the Watchdog 1310 can ensure that the monitoring client 1302 is operating properly by requiring communication with the Watchdog 1310 at fixed, predetermined, or preprogrammed intervals. If the monitoring client 1302 is unable to communicate with the watchdog 1310 within a fixed interval, the watchdog 1310 determines that an error has occurred within the monitoring client 1302 and issues an alert or alarm similar to that described above with respect to the patient-care device 1318, such as an audible sound using the speaker 1324 or flashing an LED 1326 red. In some embodiments, a speaker in the monitoring client 1302 can emit an audible alarm. In some embodiments, a speaker in the monitoring client 1302 can act as a backup speaker for the dock 1304, and a speaker 1324 of the dock 1304 can act as a backup speaker for the monitoring client 1302.

[0349] The charger 1312 can charge the battery 1314 using AC power supplied through an AC power cord 1316. Additionally or alternatively, the charger 1312 can charge the battery 1328 within the patient-care device 1318.

[0350] In some embodiments, the wireless dock 1306 can include the same hardware as the dock 1304, with or without the AC power cord 1316. For example, the wireless dock 1306 can include a number of contacts for positioning the wireless dock in a recharging cradle that includes a number of contacts that engage with contacts of the wireless dock 1306 to charge the battery therein.

[0351] 19 is a block diagram of an electronic patient care system 1400 according to another embodiment of the present disclosure. The system 1400 includes a monitoring client 1402, a dock 1404, a large volume pump 1406, a syringe pump 1408, and a sensor 1410. The system 1400 also includes a USB sensor 1412 coupled to the dock 1404 through a USB cable, a wireless sensor 1414 in wireless communication with the dock 1404, a server 1416, and a hospital information server 1418. The monitoring client 1402 may be any monitoring client, such as one of the monitoring clients 1, 4, or 11 of FIGS. 1, 3, 5, 7, 8, the monitoring clients 9, 4, or 11 of FIG. 9, a tablet, a smart phone, a PDA, a laptop, etc. The dock 1404 can communicate with one or more high volume pumps 1406, 1408, and / or sensors 1410 via electrical conductors as shown in FIG. 19 and / or wirelessly to receive parameters and / or control the devices.

[0352] The dock 1404 receives AC power 1420 from an AC outlet 1422. The dock 1404 operatively communicates with the monitoring client 1402 using a monitoring client adapter 1424. The monitoring client adapter 1424 is coupled to the dock 1404 through UI connectors 1426, 1428. The UI connectors 1426, 1428 provide power to the monitoring client adapter 1424 and data through a USB link. The monitoring client adapter 1424 is coupled to the monitoring client 1402 through several connectors 1430, 1432, 1434, 1436. Two of the connectors 1430, 1434 provide power from the monitoring client adapter 1424 to the monitoring client 1402, while the other two connectors 1434, 1436 provide USB connections therebetween to facilitate digital communication between the dock 1404 and the monitoring client 1402. It should be noted that other embodiments may utilize connections other than USB type connections.

[0353] Connectors 1438-1450 enable dock 1404 to operably provide power to high volume pump 1406, syringe pump 1408, and sensor 1410. Additionally or alternatively, connectors 1438 and 1440 provide serial communication between dock 1404 and high volume pump 1406, connectors 1442 and 1444 provide serial communication between high volume pump 1406 and syringe pump 1408, and connectors 1446 and 1448 provide serial communication between syringe pump 1408 and sensor 1410. Connector 1450 provides optional expansion for additional devices (not shown).

[0354] System 1400 illustrates a daisy chain system that couples several devices together, where each device digitally routes data intended for another device to the subsequent device, or where each device includes electrical conductors such that both of its connectors include electrical connections for respective pins.

[0355] The dock 1404 can communicate with wireless sensors 1414 using, for example, Bluetooth, Bluetooth Low Energy, Zigbee, Xbee, ANT, ANT Plus, etc. The sensors 1412, 1414, and / or 1410 may be patient monitoring devices or one or more environmental sensors, such as a temperature sensor, a humidity sensor, a camera, a microphone, an ambient light sensor, a vibration sensor, etc.

[0356] The server 1416 can communicate with a hospital information system 1418. The server 1416 provides a WiFi router by which the dock 1404 can operatively communicate with the hospital information system 1418. Information can be transferred to and from the hospital information system 1418 through the server 1416, which can translate the protocol of the dock 1404 to and from the hospital information system 1418 or Health Level 7 (HL7). The server 1416 (and / or the hospital information system 1418) can include a Medication Error Reduction System (DERS) that checks to determine that any treatment being administered to a patient using the system 1400 is safe for the patient. The server 1416 can be the monitoring server 3 and the hospital information system 1418 can be the facility services 8 of Figures 1, 3, 5, 7, 8, and / or 9.

[0357] Figure 20 is a block diagram of the dock 1404 of the electronic patient-care system 1400 of Figure 19 according to an embodiment of the present disclosure. In some embodiments, each component shown in Figure 20 is optional.

[0358] The dock 1404 includes an AC / DC converter 1452 (see FIG. 19) that receives the AC power 1420. The AC / DC converter 1452 may include a rectifier circuit, a smoothing circuit, a switch mode power supply, a linear regulator, etc., to convert the AC power to DC power 1454. In some embodiments of the present disclosure, the AC / DC converter 1452 may be external to the dock. In other embodiments, the AC / DC converter 1452 is located within the dock 1404.

[0359] DC power 1454 is received at a DC power input 1456, which may be a connector for connecting the positive and negative leads of the DC power input 1454 to power and ground planes, respectively, of a PCB board. The DC power input 1456 provides power to the circuitry of the dock 1404. The DC power input 1456 may also receive wireless power 1458.

[0360] Power received via DC power input 1456 is sent to a charging circuit 1460. The charging circuit 1460 charges a primary battery 1462 and a backup battery or supercapacitor 1464. The charging circuit 1460 can utilize a variety of charging techniques, for example, a constant current / constant voltage charging algorithm.

[0361] The dock 1404 includes a primary processor 1466 and a safety processor 1468. The primary processor 1466 is powered by a primary battery 1462. The safety processor 1468 is also powered by the primary battery 1462, as well as being able to receive power from a backup battery or supercapacitor 1464.

[0362] In this exemplary embodiment, primary processor 1466 interfaces with a barcode reader 1470, a camera 1472, a dock sensor 1474, a speaker 1476, a WiFi transceiver 1478, a Bluetooth transceiver 1480, a USB controller 1482, an LED status light 1484, and three internal expansion slots 1486, 1488, and 1490 (each of which is optional).

[0363] Internal expansion slots 1486, 1488, and 1490 can receive additional circuitry. For example, as shown in Figure 20, internal expansion slot 1486 has a communications / ranging module 1492, and internal expansion slot 1488 has an RFID reader 1494 and a near-field communicator 1488 (each optional) inserted therein.

[0364] The safety processor 1468 provides a watchdog function to the primary processor 1466. For example, the safety processor 1468 may communicate with the primary processor at predetermined intervals or anticipate a communication from the primary processor 1466 at predetermined intervals. If the safety processor 1468 does not receive the anticipated response or communication, it may determine that an error has occurred. In response to the error, the safety processor 1468 may indicate a fault using an LED fault status light 1401, generate an audible sound using a backup speaker 1403, or vibrate the dock 1404 using a vibration motor 1405. As will be appreciated in light of the present disclosure, multiple fault notifications (e.g., phone calls, emails, text messages, etc.) may be issued to multiple personnel (e.g., nurses and / or physicians, facility maintenance, etc.).

[0365] The safety processor 1468 can monitor the power provided through the device connector using the current sense circuit 1407. If the safety processor 1468 determines that the current provided to the device connector 1438 exceeds a predetermined threshold or is out of specification, the safety processor 1468 sends a signal to the power enable circuit 1409 to release the power provided from the primary battery 1462 to the device connector 1438. The power enable circuit 1409 may include a relay, a switch, a solid state switch, a contactor, etc., to connect and disconnect the primary battery 1462 to and from the device connector 1438 .

[0366] The primary processor 1466 is also electrically coupled to an optional charge status display 1411 and an optional display 1413. The charge status display 1411 can display the charge status of the primary battery 1462. The display 1413 can be a touch screen and / or can display the operational status of the dock 1404. The dock 1404 receives user input via an optional button 1415.

[0367] The communications / ranging module 1492 can communicate with other communications / ranging modules 1492, e.g., on patient-care devices, other docks, or monitoring clients, to determine the distance therebetween. For example, two communications / ranging modules (e.g., the communications / ranging module 1492 and another communications / ranging module) can communicate wirelessly, e.g., by ultrasound, RF, UHF, electromagnetic energy, optical, etc., to determine the distance therebetween. According to an embodiment, one or more of the patient-care devices, monitoring clients, patient watchdogs, remote communicators, etc., may not operate unless each having a communications / ranging module 1492 determines that they are within a predetermined distance of each other.

[0368] 21 shows an example arrangement of a system 2100 with an infusion pump 2106 connected to and delivering from a smaller fluid bag 2118, an infusion pump 2108 connected to and delivering from a larger fluid bag 2116, a drip detection device 2112 connected to tubing from the smaller bag 2118, a pill dispenser 2114, and a micro-infusion pump 2110, where the monitoring client 2102 is linked to several patient-care devices via a dock 2120. The monitoring client 2102 can communicate with these patient-care devices via wires as shown for the infusion pumps 2106, 2108, the micro-infusion pump 2110 (via the docks 2120, 2104), and the pill dispenser 2114. Alternatively, the monitoring client may communicate wirelessly with the patient-care device, as suggested by the absence of a wired connection between the drip detection device 2112 and the monitoring client 2102. In an embodiment, the wired connection between the monitoring client 2102 and the patient-care device also provides the opportunity for power to be provided from the monitoring client 2102 to the patient-care device. In this case, the monitoring client 2102 may include the necessary electronic circuitry to convert voltage to power the patient-care device, either from a battery installed in the monitoring client 2102 or from a line voltage provided to the monitoring client 2102 from a power outlet (not shown) in the patient's room. Additionally or alternatively, the dock 2104 provides power to the infusion pumps 2106, 2108 and the microinfusion pump 2110.

[0369] In an embodiment, the monitoring client 2102 is capable of receiving information about each patient-care device to which it is linked, either directly from the device itself or via a docking station, such as, for example, a dock 2104 onto which the patient-care devices can be mounted. The dock 2104 can be configured to receive one or more patient-care devices via a standard connection mount or, in some cases, via a connection mount personalized to the particular device. For example, in FIG. 21 , the infusion pumps 2106 and 2108 can be mounted to the dock 2104 via similar connection mounts, and the micro-infusion pump 2110 can be mounted to the dock 2104 via a connection mount configured to the particular dimensions of the housing of the micro-infusion pump 2110, for example.

[0370] The dock 2104 can be configured to electronically identify the particular patient-care device attached to the docking station and communicate this identification information to the monitoring client 2102 either wirelessly or via a wired connection. In addition, the particular patient-care device can be pre-programmed with therapy information (e.g., patient therapy parameters such as infusion rates for a given infusion fluid) that is communicated to the monitoring client 2102. In some embodiments of the present disclosure, the monitoring client 2102 communicates with the EMR record to authenticate that the pre-programmed therapy information is safe for the identified patient and / or that the pre-programmed therapy information matches a prescribed therapy stored in the EMR record.

[0371] In some embodiments, the drip detection device 2112 can communicate with the monitoring client 2102 either wirelessly or by a wired connection. If an abnormal fluid flow condition (e.g., due to a blockage in the tubing to the patient) is detected, a signal can be communicated to the monitoring client 2102 that can (1) display the flow rate of fluid from the fluid container 2118 in a user interface, either locally on the monitoring client 2102 or remotely through a user interface at a nurse's station or handheld communication device, (2) trigger an audible or visual alarm, (3) change the infusion rate of the pump 2108 connected to the bag 2118, either by terminating the infusion or by changing the pump speed, or (4) generate an audible alarm (and / or a vibration alarm) on the infusion pump 2106. The alarms can be generated simultaneously on several devices or can be generated consecutively on a predefined schedule. For example, if an occlusion occurs in a line connected to the infusion pump 2106, (1) the drip detection device 2112 will alert using its internal speaker and internal vibration motor, (2) the infusion pump 2106 will then alert using its internal speaker and internal vibration motor, (3) the monitoring client 2102 will then alert using its internal speaker and internal vibration motor, and (4) finally, the remote communicator 11 (see, e.g., Figures 1, 3, 5, 7, 8, 9) will alert using its internal speaker and internal vibration motor.

[0372] In some embodiments, individual pumps can be programmed to allow continued operation at a predetermined pump speed if communication fails between the monitoring client 2102 and the pump due to a failure either within the monitoring client 2102, within the communication channel between the monitoring client 2102 and the pump, or within the pump itself. In some embodiments, such an independent functionality option is enabled if the medication being infused is pre-specified not to be interrupted or continued in the event of a failure in another part of the system. In some embodiments, pumps programmed to operate independently in a fail-safe mode can also be configured to receive information directly from the drip detection device 2112 rather than through the monitoring client 2102. With this option, the pump can be programmed to stop the infusion if the drip detection device 2112 detects an abnormal flow condition (e.g., a free flow condition or air bubbles present in the infusion line, etc.), in some embodiments. In some embodiments, one or more of the pumps 2106, 2108, and 2110 can have an internal fluid flow meter and can operate independently as a stand-alone device.

[0373] 22 illustrates an electronic patient-care system 2200 having a tablet 2102 docked in a dock for wireless communication with the patient-care devices 2106, 2108, 2110, 2112, 2114 in accordance with an embodiment of the present disclosure. The monitoring client 2102 can communicate with the patient-care devices 2106, 2108, 2110, 2112 wirelessly or through a wireless transceiver on the dock 2120. For example, the monitoring client 2102 can communicate with a transceiver in the dock 2104. Additionally or alternatively, the dock 2120 includes a transceiver for use directly by the monitoring client 2102 to communicate with the dock 2104 and / or via a wireless connection to the patient-care devices 2106, 2108, 2110, 2112, 2114.

[0374] 23 illustrates an electronic patient care system 2300 having modular infusion pumps 2302, 2304, 2306, 2308 that dock into a dock 2310 having a monitoring client 2312 with a retractable user interface, according to an embodiment of the present disclosure. The modular infusion pumps 2302, 2304, 2306, 2308 have standard connectors that allow them to snap into the dock 2310. Each of the modular infusion pumps 2302, 2304, 2306, 2308 includes a user interface. For example, the modular infusion pump 2302 includes a touch screen 2314, a start button 2316, a stop button 2316, an increase infusion rate button 2320, and a decrease infusion rate button 2322. FIG. 24 is a side view of the electronic patient-care system 2300 of FIG. 23 and shows the outline of a cavity 2400 in which the monitoring client 2312 can be stored as the mounting post 2402 is movable, thereby allowing the monitoring client 2312 to be rotated along a pivot 2404 and lowered into the cavity 2400.

[0375] FIGURE 25 illustrates an electronic patient-care system 2500 having modular infusion pumps 2502, 2504, 2506, 2508 in a staggered arrangement that docks into a dock 2510 having a monitoring client 2512 with a retractable user interface according to another embodiment of the present disclosure. The system 2500 of FIGURE 25 may be similar to the system 2300 of FIGURE 23, except that the system 2500 of FIGURE 25 has modular infusion pumps 2502, 2504, 2506, 2508 in a staggered arrangement. The staggered arrangement of the modular infusion pumps 2502, 2504, 2506, 2508 allows for more leeway in tubing routing.

[0376] 26 illustrates an electronic patient-care system 2600 having modular infusion pumps 2602, 2604, 2606 that dock into a dock 2608 along a common horizontal plane. The dock 2608 includes a monitoring client 2610 that is storeable within the dock 2608. The monitoring client 2610 may be stored entirely within the dock 2608 and / or some of the monitoring client 2610 circuitry may be stored within the dock 2608. As can be readily seen from FIG. 27, which illustrates a side view of the electronic patient-care system 2600 of FIG. 26, the monitoring client 2610 pivots along a pivot 2700 to store the monitoring client 2610 within a cavity 2702 inside the dock 2608.

[0377] Figure 28 shows another embodiment of an electronic patient-care system 2900 with a hub 2902 coupled to a device dock 2904. Figure 29 shows a side view of the electronic patient-care system 2900 of Figure 28. The monitoring client 2901 is integrated with the hub 2902. In an alternative embodiment, the hub 2902 is a cradle for the monitoring client 2901 and only provides an electrical connection to the dock 2904 and scanner 2912. The modular infusion pumps 2906, 2908, 2910 are shown docked within a device dock 2904. The system 2900 also includes a scanner 2912 coupled to the hub 2902. The dock 2904 includes quick release handles 2914 and 2916 on the left and right sides of the dock 2904, respectively. Also shown in the upper left corner of each modular infusion pump 2906, 2908, 2910 are respective buttons 2918, 2920, and 2922 that are illuminated when the patient-care device is the focus of interaction on the monitoring client 2901 (a type of monitoring client, shown as a tablet) or is selected for control by a user. The tablet can select a particular modular infus...

Claims

1. 1. A system for electronic patient care, comprising: A first module; a second module configured to receive and transmit treatment instructions to the first module via a user interface; said first module comprising: receiving and storing a first parameter related to a current condition of a patient; receiving information regarding a second parameter related to an existing condition of the patient from a first database; comparing the first parameter and the second parameter to a known normal range and, if found to be outside the normal range, 11. The system for electronic patient care, configured to: define a parameter related to the patient's condition found to be outside of the normal range based on the first parameter and the second parameter that are outside of the normal range; obtain drug information related to the treatment prescription and / or existing drugs from a second database and define a drug parameter based on the drug information; compare the parameter related to the patient's condition found to be outside of the normal range with the drug parameter, and if a match is found between the parameter related to the patient's condition found to be outside of the normal range and the drug parameter, retrieve a message to be sent to the second module.

2. The system of claim 1 , wherein the message is selected from warnings appropriate to the medical treatment indication, existing medications of the patient, current and existing medical conditions of the patient, and combinations thereof.

3. The system of claim 2 , wherein the message acknowledgment enables one or both of processing the treatment instructions and avoiding repetition of the message.

4. The system of claim 1 , wherein the first parameter is selected from blood pressure, heart rate, heart rhythm, temperature, oxygenation, respiratory rate, ventilation, and combinations thereof.

5. 2. The system of claim 1, wherein the second parameter is selected from drug allergies, drug hypersensitivity, other currently administered drugs present in the patient's tissues, age, weight, height, renal function, liver function, and combinations thereof.

6. The system of claim 1 , wherein the medication information is selected from drug interactions, effects of the medication or existing medications on blood pressure, pulse, heart rhythm, or respiration, and combinations thereof.

7. The system of claim 1 , wherein the user interface is configured to provide editable default values ​​for the treatment instructions derived from standard dosing and administration guidelines obtained from a drug information database.

8. The system of claim 7 , wherein the user interface is configured to provide a user with information regarding changes that can be made to the default values ​​based on the first parameter and / or the second parameter.

9. The system of claim 1 , wherein one of the first module or the third module is configured to verify whether the delivered medication is consistent with the treatment instructions.

10. The system of claim 9, wherein the identification is by a bar code and reader, an RFID tag and scanner, or a combination thereof.

11. The system of claim 1 , wherein one of the first module or the third module is configured to interact with a dispenser that dispenses the treatment instructions.

12. The system of claim 11 , wherein the dispenser is an infusion pump, a pill dispenser, or a combination thereof.

13. 13. The system of claim 12, wherein one of the first module or the third module provides to the infusion pump a third parameter related to patient treatment selected from an infusion rate, an infusion pressure, and a combination thereof, and receives from the infusion pump an operating parameter selected from a presence of air in the infusion line, an amount of solution remaining in a connected intravenous bag, a pressure of fluid in the infusion line, and a combination thereof.

14. 14. The system of claim 13, wherein if the third parameter is abnormal, one of the first module or the third module is configured to: signal the infusion pump to interrupt infusion, signal a mechanical occlusion to occlude an venous line, signal the infusion pump to modify the infusion rate, alert a healthcare provider of the abnormality, and combinations thereof.

15. The system of claim 1 , wherein the first module is configured to communicate with a device that monitors a patient's condition and determines the first parameter.

16. 16. The system of claim 15, wherein the device is a blood pressure monitor, an ECG monitor, a pulse oximetry monitor, a temperature monitor, and combinations thereof.

17. The system of claim 1 , wherein the first parameter is recorded by a portable device and / or in an EMR.

18. The system of claim 1 , wherein the first module is configured to issue an alert and recommend corrective action if the first parameter is outside a predetermined range.

19. The system of claim 15 , wherein the first module is configured to send a signal to the device to make an unscheduled measurement.

20. a monitoring client configured to communicate a prescription order via the user interface; a pharmacy computer in communication with the monitoring client to receive the prescription order; a complex robot configured to prepare at least one liquid corresponding to said prescription; a data download device configured to download the prescription instructions into a memory of the infusion pump; 13. The system of claim 12, further comprising: the infusion pump configured to receive at least one liquid.

21. 21. The system of claim 20, wherein the complex robot is configured to instruct the data download device to download the prescription instructions into a memory of the infusion pump.

22. 21. The system of claim 20, wherein the data download device is configured to receive the prescription order from the complex robot and / or the pharmacy computer.

23. 21. The system of claim 20, wherein the composite robot is configured to receive the prescription order from the pharmacy computer.

Images