System, method and device for electronic patient care

Abstract

To provide a system for electronic patient care having a hub configured so as to monitor a patient care device.SOLUTION: An electronic patient care system 100 includes one or more monitoring clients 1, 4 who can be assigned to respectively individual patients 2 by physically coming into contact with them, and a remote monitoring server 3 for uploading information some various monitoring clients 1, 4 and downloading information and instructions to the monitoring clients 1, 4 from various sources. In the case of a patient's room, a health care provider can perform a direction interaction with the monitoring client 1 to acquire information on the patients 2 or input an instruction about the patients 2. Many monitoring clients 1 can perform an interaction with a single monitoring server 3. The monitoring server 3 can be provided with middleware.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation-in-part of U.S. Patent Application No. 13 / 011,543 (Attorney Docket No. I52), filed January 21, 2011, entitled Electronic Patient Monitoring System, which claims priority to U.S. Provisional Patent Application No. 61 / 297,544 (Attorney Docket No. H53), filed January 22, 2010, entitled Electronic Instruction Intermediary System for Medical Equipment, 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 prescribing 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 prescribing and administration, an electronic patient care system may include a first data collection module (e.g., a monitoring client) and a second instruction input module (e.g., a fixed or portable monitoring client) having a user interface for transmitting instructions or receiving patient-related information. The first module may be configured to receive and store 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 patient status parameters such as drug allergies or hypersensitivities, other currently administered medications present in the patient's tissues, age, weight, height, renal, or liver function. The first module may also be configured to obtain medication information about the prescribed medication and / or existing medications from a second database (e.g., a drug information database), such as known drug interactions, drug effects, or existing medications on blood pressure, pulse, cardiac rhythm, or respiration. The first module can be configured to compare the patient's currently measured and received existing patient condition parameters with known normal ranges and create a table of patient condition parameters found to be outside of the normal range. The first module can then compare the table of patient condition parameters with a table of corresponding parameters obtained from a drug information database. If a match is found between the table of patient condition parameters and the table of corresponding parameters, the first module can then retrieve one or more pre-entered and stored messages for communication to the second (instruction input) module. These messages can 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 a 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. Preferably, the electronic patient care system minimizes the amount of typed input from the user.

[0007] In other embodiments, the first module or another module of the electronic patient-care system may be used to identify the prescribed medication to be delivered to the patient's bedside (e.g., via a barcode and reader or RFID tag and scanner) and verify that the appropriate medication and dosage are 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 the infusion rate or pressure, and may receive various operating parameters therefrom, such as 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 an operating parameter is found to be abnormal, the first module may be configured to respond by signaling the infusion pump to interrupt the infusion, signaling a mechanical occlusion to occlude the venous line, modify the infusion rate, and / or alert a healthcare provider or the like of the abnormality, either directly via an alarm built into the first module or by transmitting an alarm to a 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 status parameters, such as, for example, a blood pressure monitor, an ECG monitor, a pulse oximetry monitor, a temperature monitor, etc. The various measured parameters can be monitored and / or recorded by the mobile device and / or within the EMR. In some cases, the first module can be programmed to alert the patient or others if a monitored patient status parameter is outside a predetermined range. In some embodiments, the first module can communicate a signal to a monitoring client to perform a measurement not scheduled by the patient-care device to obtain another patient status parameter.The first module may communicate with various healthcare providers in various locations, and in embodiments, the first module may notify an assigned patient of an abnormality and recommend corrective action, for example, by 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 multirobot, 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 multirobot 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 instruct the data download device to download prescription instructions into the memory of the microinfusion pump. The data download device can receive the prescription instructions from the multirobot and / or a 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 also 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 a patient-care device, which may be one or more of an infusion pump, a pill dispenser, a microinfusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter, a CO2 capnometer, an intravenous bag, and / or 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, 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. A sandbox can be configured to control access to at least one of hardware resources and software resources. The hub is further configured to identify the patient-care device and execute an application to monitor the patient-care device. The hub executes the application within a sandbox component, whereby the application accesses at least one of the hardware resources and software resources through the sandbox component. The hub may be further configured to control the patient-care device. The hub may be further configured to receive identification information from the patient-care device and download the application from a server associated with the identification information. The hub may be further configured to receive identification information from the patient-care device and update the application from the server associated with the identification information.

[0016] The hardware resource may be a disk drive, memory, buzzer, microphone, speaker, and 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 hardware resources of the monitoring client and software resources of the monitoring client. The sandbox component is configured to control access to the 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 the 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] The patient care device may be an infusion pump, a pill dispenser, a microinfusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter and / or a CO2 capnometer, an intravenous bag, and an IV flow meter.

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

[0020] The hardware resource may be a disk drive, memory, buzzer, microphone, speaker, and 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 resources and software resources. The monitoring client may be further configured to identify the patient-care device and execute an application to monitor the patient-care device. The monitoring client executes the application within the sandbox component, whereby the application accesses at least one of the hardware resources and software resources through the sandbox component. The monitoring client may be further configured to control the patient-care device.

[0022] The patient care device may be an infusion pump, a pill dispenser, a microinfusion pump, an ECG monitor, a blood pressure monitor, a pulse oximeter and / or a CO2 capnometer, an intravenous bag, and an IV flow meter.

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

[0024] The hardware resource may be a disk drive, memory, buzzer, microphone, speaker, and 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 medication and / or an infusion rate or rate profile, etc.) from the electronic medical record and program the patient-care device with the at least one treatment parameter. The hub identifies the patient 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 facial recognition software coupled with a camera, biometric parameters of a biometric read, identification information, or barcode reading with a barcode reader. In a specific embodiment, the hub can download the 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 therapy 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 therapy 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 a 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 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 communication 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 docked wirelessly with the device dock.

[0033] In another embodiment, the monitoring client operatively communicates at least one patient-care parameter using wireless communication with the device dock when the monitoring client determines at least one of: communication over a cable is unavailable; communication between the monitoring client and the monitoring-client dock is unavailable; 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, and the monitoring client wirelessly communicates 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 communicate at least one patient parameter wirelessly. The system further includes a cable operably coupled to the monitoring-client dock and the device dock, the monitoring-client dock and the dock configured to communicate wirelessly when at least one of the device dock, the monitoring-client dock, and the monitoring client determines 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 multiple communication links, and the monitoring client communicates over operable ones of the multiple communication links.

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

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

[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 the monitoring client is configured to communicate at least one patient-care parameter with the patient-care device through the cable when the patient-care device is docked to the device dock and the monitoring client is docked to the monitoring client dock.

[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 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, wherein 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 before 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 hardware and 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] The at least one patient monitor can include at least one of an electrocardiogram monitor, a blood pressure monitor, a pulse oximeter monitor, and a CO2 capnometer. The monitoring client can be configured to download patient information according to a designated unique patient identifier. The unique patient identifier can be encoded in a barcode disposed on a wristband. The unique patient identifier can be encoded on an RFID tag (e.g., an RFID interrogator) coupled to the wristband. The patient information includes a patient condition or a patient care parameter. The unique patient identifier can be operatively transmitted to the monitoring server to obtain electronic authorization to communicate the patient-specific data. A subset of the patient-specific data can be stored in a memory of the monitoring client. The monitoring client is configured to determine whether a new indication meets predetermined criteria based on the subset of patient-specific data stored in 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 configured 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 can communicate with a database to determine whether the new order meets another predetermined criterion. The monitoring server can 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, wherein at least one of the plurality of databases includes 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 plurality of databases for downloading 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 be one or more of and / or comprise at least one of an infusion pump therapy progress, an electrocardiogram signal, a blood pressure signal, a pulse oximeter signal, a CO2 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 query 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 server to communicate patient information directly, 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 can be configured to query an electronic health record database to receive patient information therefrom. The monitoring server can 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 is adapted to communicate with the monitoring client via the monitoring server. The remote portable monitoring client may be one of a tablet PC, a netbook, and a PC. The remote portable monitoring client may include a touch screen.

[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 an 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 at least one patient-care parameter, and a communication interface configured to facilitate communication between the monitoring client and the at least one patient-care device by discovering the presence of the at least one patient-care device and converting communication signals from the device to a communication protocol associated with the monitoring client.

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

[0077] 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 monitoring clients that enable at least one of central storage of patient information and / or downloaded information that can be used in treating patients associated with the monitoring clients.

[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, assess whether the monitoring client is functioning properly, assess whether the patient-care device is functioning properly, and / or assess 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 communication interface configured to facilitate communication 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 communication protocol associated with the hub.

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

[0081] 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 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, assess whether the monitoring client is functioning properly, assess whether the patient-care device is functioning properly, and / or assess 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 communication interface configured to facilitate communication 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 communication protocol associated with the dock.

[0084] In certain embodiments, the communication interface is further configured to discover the presence of additional, different patient-care devices and convert communication signals from the devices to a communication 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 to treat patients 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, assess whether the monitoring client is functioning properly, assess whether the patient-care device is functioning properly, and / or assess 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 supply coupled to the patient-care device interface and configured to power the patient-care device, a processor, and a transceiver coupled to the patient-care device interface configured to enable communication between the processor and the patient-care device. The processor, in some particular 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 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.

[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 power the patient-care device, a processor, and a transceiver coupled to the patient-care device interface configured to enable communication between the patient-care device and another device. The processor, in some particular 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, wherein 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 about the patient; and a second module configured to receive medication orders from a user via a user interface associated with the second module and further configured to communicate the medication orders to the first module, the first module being further configured to: a) retrieve medication information regarding the medication or other substance from the second database, the medication information including data providing limits within which such medication is typically 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 from the first module to the second module for display on the user interface confirming the acceptability of or warning about the medication order.

[0093] The medication 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, the warning including measured 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 of the dock, the patient-care device and the dock are paired using the first communication link and remain in communication using the second communication link after pairing. 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 near-field 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 of 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. 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 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, the user interface template being capable of being 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 (e.g., 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 communication 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 communication 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 watchdog functions 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, a 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, 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, e.g., 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 operating memory, and resuming operation of the patient-care device. In an additional embodiment, the method 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, e.g., 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. In an additional embodiment, the method may include determining that operation of the patient-care device can be resumed.

[0107] In yet another embodiment, the pairing method 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 identification information of the patient-care device on the user interface, selecting the patient-care device for pairing using the user interface, pairing the patient-care device 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 may include operatively communicating additional patient-care parameters with or through another patient-care device, for example, to the monitoring client and / or hub.

[0108] In yet another embodiment, a method includes the 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, wherein 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, wherein 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, wherein the monitoring client can identify the patient-care device, can query a server for an application for controlling the patient-care device, can download the application to the monitoring client, can execute the application, and can control 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 before sending.

[0113] In yet another embodiment, the hub includes a dock for receiving the patient-care device and at least one connector coupled to the open 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 the 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 includes 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 embodiments, the patient-care device includes a screen and an accelerometer, the patient-care device 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 a support 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. The patient-care device and / or communications module are fault-tolerant to the monitoring client. For example, 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 explanation 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. [Figure 2]2 is a flowchart 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. [Figure 3] FIG. 10 is a block diagram of an electronic patient-care system having two docks for wireless communication therebetween according to another embodiment of the present disclosure. [Figure 4] 4 is a flowchart 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. [Figure 5] FIG. 10 is a block diagram of an electronic patient-care system having a dock for docking both a monitoring client and a patient-care device according to yet another embodiment of the present disclosure. [Figure 6] 6 is a flowchart 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. 10 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 according to yet another embodiment of the present disclosure. [Figure 8] FIG. 10 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. 10 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] FIG. 10 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 flowchart 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] FIG. 10 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. 10 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. 10 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] FIG. 10 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. 10 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] FIG. 10 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. 10 is a block diagram of an electronic patient-care system according to yet another embodiment of the present disclosure. [Figure 19] FIG. 10 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 with a cable electrically coupled to the patient-care device according to 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 docking into a dock having a monitoring client with a retractable user interface, according to an embodiment of the present disclosure. [Figure 24] FIG. 24 is a side view of the electronic patient-care system of FIG. 23 in accordance with an embodiment of the present disclosure. [Figure 25] A diagram showing an electronic patient care system having staggered modular infusion pumps docking into a dock having a monitoring client with a retractable user interface according to another embodiment of the present disclosure. [Figure 26] A diagram showing an electronic patient care system having modular infusion pumps docked in docks 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] FIG. 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. 10 illustrates an electronic patient care system having modular infusion pumps docked in a dock along a common horizontal plane, including a monitoring client with a retractable user interface, and having a hub coupled to the scanner and dock, according to 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] 10A-10C 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. [Figure 33] 1 illustrates an infusion pump and a dock coupled to a support pole, according to an embodiment of the present disclosure. [Figure 34] 10A-10C illustrate another infusion pump coupled to an open connector and an infusion pump with an open connector according to an embodiment of the present disclosure. [Figure 35] FIG. 34 illustrates the infusion pump of FIG. 33 with two additional infusion pumps each coupled to an open connector, according to an embodiment of the present disclosure. [Figure 36] FIG. 36 is a top view of one of the infusion pumps and hub of FIGS. 33-35 according to an embodiment of the present disclosure. [Figure 37] FIG. 1 illustrates a square hub with several connectors according to an embodiment of the present disclosure. [Figure 38]FIG. 10 illustrates an electronic patient-care system having a hub coupled to a post according to another embodiment of the present disclosure. [Figure 39] FIG. 10 illustrates an electronic patient-care system having a hub coupled to a support 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. [Figure 40] FIG. 10 illustrates an electronic patient-care system having a hub coupled to a pole and a dock coupled to the hub according to another embodiment of the present disclosure. [Figure 41] FIG. 10 illustrates an electronic patient-care system having a hub coupled to a post according to another embodiment of the present disclosure. [Figure 42] FIG. 10 illustrates an electronic patient-care system having a monitoring client coupled to a hub having notches for receiving patient-care devices according to another embodiment of the present disclosure. [Figure 43] FIG. 43 is a close-up view of a T-shaped connector mating with a notch in a hub as shown in FIG. 42 according to another embodiment of the present disclosure. [Figure 44] FIG. 10 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. [Figure 45] FIG. 10 illustrates an electronic patient-care system having a stackable patient-care device that is stackable next to another stack of patient-care devices according to yet another embodiment of the present disclosure. [Figure 46] FIG. 10 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. 10 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. 10 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] FIG. 49 is an enlarged view of the 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] 10 illustrates another embodiment of an electronic patient-care system showing removal of stackable patient-care devices according to another embodiment of the present disclosure. [Figure 52] FIG. 10 illustrates an electronic patient-care system prepared for transport according to another embodiment of the present disclosure. [Figure 53] FIG. 10 illustrates an electronic patient-care system having stackable patient-care devices according to another embodiment of the present disclosure. [Figure 54] FIG. 10 illustrates an electronic patient-care system having stackable patient-care devices that are stackable bottom-up according to another embodiment of the present disclosure. [Figure 55] FIG. 10 illustrates an electronic patient-care system having stackable patient-care devices coupled to a support column and stackable from the top down according to another embodiment of the present disclosure. [Figure 56] FIG. 10 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]1 is a block diagram of an electronic patient-care system having a hub for communicating with several electronic patient-care devices according to an embodiment of the present disclosure. [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. [Figure 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] 10A-10C illustrate additional configurations of an electronic patient-care system according to embodiments 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. [Figure 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. 10 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. 10 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. [Figure 77-78] 1A-1D illustrate several configurations of an electronic patient-care system according to embodiments of the present disclosure. [Figure 79]FIG. 10 is another timing diagram of an electronic patient care therapy using an infusion pump according to another embodiment of the present disclosure. [Figure 80A-80B] FIG. 80 is a flowchart diagram of a method illustrating the timing diagram of FIG. 79 according to an embodiment of the present disclosure. [Figure 81] FIG. 10 is another timing diagram of an electronic patient care therapy using an infusion pump according to another embodiment of the present disclosure. [Figure 82A-82B] FIG. 82 is a flowchart diagram of a method illustrating the timing diagram of FIG. 81 according to an embodiment of the present disclosure. [Fig. 83-89] 10A-10D 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. 1 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. 10 illustrates another embodiment of an electronic patient-care system having vertically arranged patient-care devices docked within a dock in accordance with embodiments 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-1C illustrate some embodiments of an electronic patient-care system having an infusion pump coupled to a communications module, according to some embodiments of the present disclosure. [Figure 99-101] 3A-3C are block diagrams 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. [Figure 103-104] 10A-10C illustrate additional embodiments of the electronic circuitry of the dock according to additional embodiments of the present disclosure. [Figures 105-116]10A-10D illustrate some embodiments of an attachable pump attached to a monitoring client according to additional embodiments of the present disclosure. [Figure 117] FIG. 1 illustrates a backplane for use in an infusion pump, according to an embodiment of the present disclosure. [Figure 118] FIG. 118 is a cross-sectional view of the backplane panel of FIG. 117 according to an embodiment of the present disclosure. [Figure 119-120] 10A-10D illustrate some embodiments of an attachable pump attached to a monitoring client according to additional embodiments of the present disclosure. [Figure 121] FIG. 1 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. 1 is a diagram of an electronic circuit for converting short-range wireless communication to UHF, according to an embodiment of the present disclosure. [Figures 125-127] 10A-10C illustrate 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. [Figure 130] FIG. 1 illustrates a near-field antenna according to an embodiment of the present disclosure. [Figure 131] FIG. 131 illustrates an equivalent circuit of the split-ring resonant circuit of FIG. 130 in accordance with an embodiment of the present disclosure. [Figure 132] FIG. 1 illustrates a 5R checklist that can be displayed on a monitoring client in accordance with an embodiment of the present disclosure. [Figure 133] FIG. 10 illustrates an occlusion checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. [Figure 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. [Figure 135] FIG. 10 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, according to an embodiment of the present disclosure. [Figure 136] FIG. 10 illustrates a display on a healthcare provider's portable monitoring client showing devices associated with a particular patient, with current data from the devices and one-touch access to some of the patient's clinical information, in accordance with an embodiment of the present disclosure. [Figure 137] FIG. 10 illustrates a display on a healthcare provider's portable monitoring client showing a data entry area for a medication prescription for use with an intravenous infusion pump, according to an embodiment of the present disclosure. [Figure 138] FIG. 10 illustrates a display on a healthcare provider's portable monitoring client showing a risk profile associated with a prescribed medication and a suggested course of action, as generated by the monitoring client, in accordance with an embodiment of the present disclosure. [Figure 139] FIG. 10 illustrates a display on a healthcare provider's portable monitoring client showing a drug prescription ready for submission by an ordering provider, according to an embodiment of the present disclosure. [Figure 140] FIG. 10 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, according to an embodiment of the present disclosure. [Figure 141] FIG. 1 is a perspective view of a micro-infusion pump coupled to an adapter, according to an embodiment of the present disclosure. [Figure 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. [Figure 143]FIG. 1 is 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 according to an embodiment of the present disclosure. [Figure 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. [Figure 145] FIG. 144 is an enlarged perspective view of one interface of the patient-care device shown in FIG. 143 according to an embodiment of the present disclosure. [Figure 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. [Figure 147] 1 illustrates a system for an electronic patient care system according to an embodiment of the present disclosure. [Figure 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 the bedside portion of the electronic patient-care system of FIG. 147 and / or FIG. 148 in accordance with an embodiment of the present disclosure. [Figure 150] FIG. 147, 148, and / or 149 is a block diagram of the dock / hub according to an embodiment of the present disclosure. [Figure 151] FIG. 149 is a block diagram illustrating the infusion pump circuit of FIGS. 148 and / or 149 in accordance with an embodiment of the present disclosure. [Figure 152] FIG. 10 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 INVENTION

[0122] Techniques for facilitating patient care are disclosed. The techniques can be implemented, for example, in a system having one or more patient-care devices communicatively coupled to a monitoring client, according to one exemplary embodiment. The patient-care devices can include any number of diverse functions and / or be manufactured by different manufacturers. In one such case, a communication interface between the client monitoring station and the various diverse patient-care devices enables discovery and protocol conversion, as well as various other functions, such as power provision, compliance with various standards, and user interfaces. The patient-care devices may be infusion pumps, microinfusion pumps, insulin pumps, syringe pumps, pill dispensers, dialysis machines, ventilators, ultrasound machines, ECG monitors, blood pressure monitors, pulse oximeters, CO2 capnometers, drip counters, drip flow meters, optical Doppler devices, heart rate monitors, intravenous bags, hemodialyzers, peritoneal dialysis machines, enteral dialysis machines, patient thermometers, and / or other bedside patient-care devices. U.S. Patent Application No. 11 / 704,899, filed February 9, 2007, entitled "FLUID DELIVERY SYSTEM AND METHODS," subsequently published on October 4, 2007, as U.S. Patent Application Publication No. 2007-0228071-A1 (Attorney Docket No. E70); U.S. Patent Application No. 11 / 704,896, filed February 9, 2007, entitled "PUMP FLUID DELIVERY SYSTEM AND METHODS USING FORCE APPLYING ASSEMBLY," subsequently published on September 20, 2007, as U.S. Patent Application No. U.S. Patent Application Publication No. 2007-0219496 (Attorney Docket No. E71), filed February 9, 2007, entitled "Patch-Sized Fluid Delivery System and Method," and subsequently published U.S. Patent Application Publication No. 2007-0219481 (Attorney Docket No. E72), filed February 7, 2007, entitled "Adhesive and Peripheral Systems and Methods for Medical Devices," and subsequently published U.S. Patent Application Publication No. 11 / 704,886, filed February 9, 2007, entitled "Adhesive and Peripheral Systems and Methods for Medical Devices."No. 897, subsequently published on September 20, 2007 as U.S. Patent Application Publication No. 2007-0219597 (Attorney Docket No. E73), subsequently published on December 31, 2008 as U.S. Patent Application Publication No. 12 / 347,985, filed on December 31, 2008, entitled Infusion Pump Assembly, subsequently published on December 3, 2009 as U.S. Patent Application Publication No. 2009-0299277 (Attorney Docket No. G75), subsequently published on December 31, 2008 as U.S. Patent Application Publication No. 12 / 347,982, filed on December 31, 2008, entitled Wearable Pump Assembly. 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,984, filed on December 31, 2008, entitled "Pump Assembly With Switch"; Thereafter, U.S. Patent Application Publication No. 2009-0299289 (Attorney Docket No. G79), published on December 3, 2009; U.S. Patent Application No. 12 / 249,882, filed on October 10, 2008, entitled "Infusion Pump Assembly"; thereafter, U.S. Patent Application Publication No. 2010-0094222 (Attorney Docket No. F51), published on April 15, 2010; and U.S. Patent Application No. 12 / 249,636, filed on October 10, 2008, entitled "System and Method for Administering Infusible Fluids." U.S. Patent Application Publication No. 2010-0094261 (Attorney Docket No. F52), published April 15, 2010; U.S. Patent Application Publication No. 12 / 249,621, filed October 10, 2008, entitled "Occlusion Detection System and Method," which was subsequently published April 15, 2010, U.S. Patent Application Publication No. 2010-0090843 (Attorney Docket No. F53); U.S. Patent Application Publication No. 12 / 249,621, filed October 10, 2008, entitled "Multi-Language / Multi-Processor Infusion Pump Assembly," which was subsequently published October 10, 2008, U.S. Patent Application Publication No.No. 600, subsequently published on April 15, 2010, U.S. Patent Application Publication No. 2010-0094221 (Attorney Docket No. F54); U.S. Patent No. 8,066,672 (Attorney Docket No. F55), issued on November 29, 2011, entitled "Infusion Pump Assembly with Backup Power Supply"; U.S. Patent No. 8,016,789 (Attorney Docket No. F56), issued on September 13, 2011, entitled "Pump Assembly with Removable Cover Assembly"; and U.S. Patent No. 7,306,578 (Attorney Docket No. C54), issued on December 11, 2007, entitled "Loading Mechanism for Infusion Pump," all of which are 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 light of this disclosure.

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

[0124] More specifically, medication errors can cause hundreds of deaths and injure thousands or even millions of people each year in the United States alone. Financially stressed hospitals may experience numerous medication error incidents. Medication errors associated with many dangerous errors include insulin, narcotics, heparin, and chemotherapy. Medication errors can include administering the wrong medication, administering the wrong concentration, delivering the medication at the wrong rate, or delivering the 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 similarly named medications. To reduce medication error incidents, there has been a trend toward using electronic medical records (EMRs) and drug barcode systems. 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] Additionally, 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 medication may be suspended, inaccurate parameters (e.g., drug concentration or infusion rate) may be entered, or existing infusion parameters may be inappropriately changed. Nearly half of infusion pump-related deaths are due to user error, and many of these errors may be due to errors in 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: prescription, medication preparation, and medication administration. 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 embodiments 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 can be implemented by a communication module described below. The communication interface can 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) and translate communication signals from these devices into a communication protocol associated with the monitoring client or 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 healthcare providers can use 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 download of information that can be used by healthcare providers in treating patients associated with the monitoring clients. The communications interface can be implemented in several 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 on two frequency channels (in some embodiments, data may be redundant).In some embodiments, the communications module enables the patient-care device to be portable 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 several different monitoring clients 1, 4 and downloads information and instructions to the monitoring clients 1, 4 from various sources. In the case of a patient's room, a healthcare provider can interact directly with a 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 include middleware (e.g., middleware on the monitoring server 3 in FIG. 1). Additionally or alternatively, providers at remote locations (e.g., doctor's offices, nurses' stations 5, hospital pharmacy 6) can interact with individual monitoring clients 1 directly through a communications link with the monitoring server 3 or via a hospital local area network that has each monitoring client 1, 4 as a node.

[0130] A prescription may be filled by the remote communicator 11, other monitoring clients 4, nurses' stations 5, or doctor's offices to update the patient's personal EHR 19 or 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] Pharmacy 6 may include one or more computers connected to a network, e.g., the Internet, for receiving and queuing prescriptions within 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 produce pills, or manually by a pharmacist monitoring the queue of the one or more computers), (2) pre-fill the fluid reservoir of syringe pump 126, (3) program syringe pump 126 (e.g., a treatment plan is programmed into syringe pump 126), (4) pre-fill microinfusion pump 130, (5) program microinfusion pump 130, (6) pre-fill intravenous bag 170, (7) program infusion pump 7, (8) pre-fill pill dispenser 128, or (9) program 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, microinfusion 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 programmed therapy in infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is being dispensed by syringe pump 126, microinfusion pump 130, or or corresponds to the fluid in the intravenous bag 170, (5) 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). 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 in its internal memory (e.g., downloaded via an automated compounding device) or 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 on the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 can scan the barcode of another patient-care device to obtain the patient-care device's serial number and the patient's barcode 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., which may have been updated by the pharmacy 22 or a pharmacy's automated compounding device).

[0135] Additionally or alternatively, monitoring client 6 may determine (1) whether syringe pump 126 or intravenous bag 170 has the correct fluid, (2) whether microinfusion pump 130 has the correct fluid, (3) whether pill dispenser 128 has the correct pill, (4) whether the therapy programmed in 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, and (5) whether the pill dispenser 128 has the correct pill. 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 the 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 query 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, e.g., 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 infusion pump 7, the syringe pump 126, and / or the 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, e.g., pill dispensing instructions, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria for dispensing pills. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, if a particular medication is taken as needed (i.e., when needed), but the medication may be unsafe if taken in excess, the maximum pill dispensing criterion can prevent the medication from being taken by the patient at an unsafe level, for example, in a given amount within 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, 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 100 is operating properly or within predetermined boundaries, and / or display the data on a display of the monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may optionally communicate, if applicable, the upstream pressure, the change in upstream pressure, the downstream pressure relative to patient 2, the change in downstream pressure relative to patient 2, the presence or absence of air in the infusion line, the actual bolus volume 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 monitoring client 1, other monitoring clients 4, and / or remote communicator 11. In another embodiment, pill dispenser 128 may optionally communicate data, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether a maximum pill dispensing standard was exceeded, back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11.

[0138] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined 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 an 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 alert the user. These alarms and / or alerts may also notify 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 detached from 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 insert a new needle for continued infusion. The 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 the unattached needle coupler.

[0140] In some embodiments, the upstream pressure to one or more infusion pumps 7 can additionally or alternatively be monitored for any upstream occlusions. For example, contamination in the intravenous bag 170 can block the tubing upstream of the infusion pump 7. Each time the infusion pump 7 attempts to pump fluid from the intravenous bag 170, the upstream pressure to the infusion pump 7 can drop below what would occur if there was no upstream occlusion. Thus, one or more of the monitoring clients 1, 4, 11 can 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 changing 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 fluid delivery in response to a sudden increase and / or decrease in downstream pressure to the patient 2.

[0142] As shown in FIG. 1 and in some embodiments, system 100 includes a monitoring-client dock 102 and a device dock 104. The monitoring-client dock 102 is configured to receive a monitoring client 1, and the device dock 104 is configured to receive one or more patient-care devices to facilitate bedside patient care (described in more detail below). While device dock 104 is shown as being capable of receiving several patient-care devices, in other embodiments, device dock 104 can receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices. Additionally, while monitoring-client dock 102 is shown as being capable of receiving one monitoring client 1, in other embodiments, 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 the exemplary embodiment, cable 110 is coupled to both docks 102, 104 to provide a communication 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 comprises a fiber optic waveguide to provide an optical communication link between the docks 102, 104. In other embodiments, as will be appreciated in light 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, 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] 1 , 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, monitoring client dock 102 can include various accessories, such as a camera 140 and a microphone 142, each of which is optional. Monitoring client 1 can include various accessories, such as a camera 144 and a microphone 146, each of which is optional. Cameras 136, 140, and 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 may 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 light of this disclosure, cameras 136, 140, 144 and microphones 138, 142, 146 may 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.) before treatment begins, for example, to ensure the correct patient receives the correct treatment.

[0148] 1 , in some embodiments, the monitoring client 1, the monitoring-client dock 102, and the device dock 104 each have antennas 112, 106, and 108 for wireless communication (each 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. Additionally, 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 wirelessly communicating 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 the voltage or impedance between two electrical contacts of a connector of the monitoring client 1 used for docking to the monitoring client dock 102 and for providing electrical communication between the monitoring client dock 102 and the monitoring client 1. The monitoring client 1 can also determine that the cable 110 is not available if it determines that the monitoring client 1 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 the monitoring client 1 then uses 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 signal the monitoring client 1 if the cable is not available as a communication link. In some embodiments, the monitoring client 1 can periodically "ping" the device dock 104 through the cable 110. If the monitoring client does not receive a response from the device dock 104 within a predetermined time, the monitoring client 1 presumes that the cable 110 is not available as a communications link.

[0150] If the monitoring client 1 determines that the cable 110 is not available as a communications link, the monitoring client 1 can sound an alarm or alert using a speaker and / or a vibration motor, can 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 can 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, with minimal or no circuitry, that facilitate communication between various docked devices and / or the monitoring client 1 via the monitoring client dock 102. The device dock 104 may be a cradle in some embodiments.

[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, facilitating efficient data viewing and data entry. The monitoring client 1 may be a notebook PC, netbook PC, tablet PC, or "smart phone," with or without a touchscreen. Additionally or alternatively, in some embodiments, the monitoring client 1 and / or remote communicator 11 may be docked or coupled to a cable connected to a much larger display, thereby making the much larger display (e.g., a 24-inch display) the display for the monitoring client 1 and / or remote communicator 11. The much larger display may have input capabilities, such as touchscreen capabilities, stylus input capabilities, keyboard input capabilities, remote control input capabilities, etc., 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. Assignment of a particular monitoring client 1 to a particular patient 2 may be accomplished using any of several methods, including (but not limited to) a unique patient identifier encoded on a barcode 114 or RFID tag 116 embedded in a wristband 118. The device dock 104 includes a scanner 120 to determine the unique patient identifier of the barcode 114 or RFID tag 116. The scanner 120 may be a laser barcode scanner, a CCD-based barcode scanner, a near-field communicator or 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., facial 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, illness, 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 are measurements of blood pressure, temperature, heart rate, pulse oximetry, CO2 level, blood oxygen level, patient alertness, patient consciousness, patient responsiveness, etc. Some exemplary patient treatment parameters include administered medications, 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 the infusion pump 7, can be permanently attached, can be attachable and detachable therefrom, or can be attachably detachable. 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 several 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 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 can also communicate with one or more databases within the facility 8, databases external to the facilities 9, 10, and / or with healthcare providers (including, e.g., physicians, nurses, and pharmacists) using a portable communicator 11. This can 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 intra- and extra-facility databases is mediated 13 (e.g., using middleware) through the monitoring server 3, which can then centralize software and application programming interfaces for communicating with databases having heterogeneous organizations, formatting, and communication protocols. Thus, in embodiments of the present disclosure, any software updates can be largely limited to the monitoring server 3, reducing maintenance requirements on the individual monitoring clients 1, 4, 11. Optionally, the monitoring client 1 can communicate with patient treatment devices, such as an infusion pump 7, to receive information regarding the progress of treatment (such as operating parameters) and provide operating instructions to the patient treatment devices. In another embodiment, the monitoring client 1 can also communicate with patient care devices for diagnostic or monitoring purposes to receive patient status parameters (e.g., an electrocardiogram (ECG) monitor 14, a blood pressure (BP) monitor 15, a pulse oximeter or CO2 capnometer 16, or other devices such as a temperature monitor) to receive readings from the devices and potentially instruct the devices 14, 15, 16, 17 to take readings as desired by a provider or by an algorithm.

[0157] In embodiments of the present disclosure, the equipment service 8 and / or the adverse drug event network 9 may also include a medication error reduction system (DERS). The DERS system may include a first set of predetermined criteria for triggering a soft alarm and / or a second set of predetermined criteria for triggering a hard alarm. Soft alarms can be overridden (e.g., silenced) by a caregiver using the user interface of the infusion pump 7 and / or monitoring client 1 (and may be only an audible and / or vibration alarm), while hard alarms suspend treatment until the cause is resolved.

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

[0159] As further seen in the exemplary embodiment of FIG. 1 , system 100 also includes communication modules 124A-124K, each having a respective one of antennas 122A-122K. In some embodiments, each communication module 124A-124K is optional and / or each device may have integrated communication capabilities. Each communication module 124A-124K includes a connector for coupling to a respective device. In other embodiments, each communication 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, the device dock 104, the monitoring client dock 102, the monitoring client 1, the remote communicator 11, 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 various medical devices associated with monitoring clients 1, 4, 11 and / or dock 104).

[0161] In other embodiments, each patient-care device may include zero 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 touchscreen or display (the display may be attached to the housing), a wired connection, Bluetooth, Bluetooth low energy, WiFi, 3G, 4G, a coprocessor, a control system (e.g., for controlling the infusion pump), medication delivery using a fluid measurement circuit, etc. Selected modules may be connected to each other, e.g., in a daisy chain, and then connected to the infusion pump. Selected modules, in this example, may operatively communicate with each other to coordinate their operation and / or function, e.g., via a CAN bus, wired communication, wirelessly, and / or other means.

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

[0163] With continued reference to FIG. 1 , one or more of the communications modules 124A-124K may also optionally include one or more batteries to power devices coupled thereto. For example, communications module 124A may be coupled to infusion pump 7 to power it. Other structures and functions of communications 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; therefore, in some embodiments of the present disclosure, communications module 124A implements a control algorithm, e.g., a proportional-integral-derivative (PID) control loop, to control infusion pump 7. In such a case, monitoring client 1 may, for example, communicate a fluid flow rate signal to communications module 124A (e.g., via a wireless link), which then applies a signal corresponding to the fluid flow rate signal through electrical contacts coupled to a motor (not explicitly shown) of 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 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, communication modules 124A-124K can be operably coupled to various patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, and 148. For example, and with further reference to FIG. 1 , communication module 124B is operably coupled to syringe pump 126, and communication module 124C is operably coupled to pill dispenser 128. Additionally or alternatively, communication module 124E is operably coupled to ECG monitor 12, communication module 124F is operably coupled to blood pressure monitor 15, communication module 124G is operably coupled to pulse oximeter / CO2 capnometer 16, communication module 124H is operably coupled to other monitor 17, communication module 1241 is operably coupled to the patient's intravenous access 35, and communication module 124K is operably coupled to drip flow meter 148. Each respective communications module 124A-124K may provide, for example, an appropriate control system, control algorithm, battery power, or other functionality for the respective patient-care device 7, 14, 15, 16, 17, 35, 126, 128, or 148 coupled thereto.

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

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

[0167] As previously discussed, in some embodiments, the communications modules 124 each comprise a power circuit (e.g., a voltage converter, a regulation circuit, a rectification and filtering circuit, a buck circuit, a boost circuit, a buck-boost circuit, a switch-mode power supply, etc.) that provides sufficient power to the corresponding devices 7, 126, 128, and 130. In some such cases, the power circuit can be configured to enable provision of various power supply characteristics (e.g., voltage levels, maximum load / current requirements, and A / C frequencies) associated with the various different patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. Any number of power supply and management schemes are apparent in light 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, when available, to power the devices in the dock 104 and to charge the batteries contained within the power module 132 (which may occur simultaneously). If outlet power is lost or otherwise unavailable, the batteries in the power module 132 and / or the communications 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 within the device dock 104 shown in FIG. 1 or, in other embodiments, may be remote from 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 other protocols, thereby enabling the new protocol devices to communicate with the patient-care devices 7, 14, 15, 17, 35, 126, 128, 130, the device dock 104, the communications module 124D, the monitoring-client dock 102, the monitoring client 1, the hub 802 of FIG. 8, and / or other devices. Dongle 133 can retransmit data received from the new communication link using wireless protocols, technologies, standards, or techniques used by any one or more of 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 monitoring server 3 or monitoring client 1. Dongle 133 can also provide a communications bridge to cellular-based communication links, such as EVDO or CDMA-based cellular systems.

[0170] In some embodiments, dongle 133 can communicate patient-care parameters, e.g., patient treatment parameters or patient status parameters, from one or more patient-care devices and retransmit them to monitoring client 1, hub 802 of FIG. 8, and / or monitoring server 3, or vice versa. Optionally, in some embodiments, 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, such as monitoring client 1, hub 802 of FIG. 8, and / or monitoring server 3. The legacy device can be, for example, a legacy patient-care device, a legacy computing device, or other device using a legacy wired communication protocol.

[0171] Optionally, system 100 may also include a wearable system monitor 131 for monitoring the operation of various devices, docks, monitoring clients, and / or servers. The monitoring client 1, remote communicator 11, and / or hub 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 a 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, irregularities, 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 error to one or more devices, such as the monitoring server 3, the monitoring client 1, or the hub 802 of FIG. 8, to alert a provider, initiate shutdown procedures, and / or initiate other appropriate therapeutic actions directed at the malfunctioning device. For example, the system monitor 131 may signal an alert and / or alarm due to an abnormal or lack of an interrogation response using the transceiver of the communications module 124J, which communicates with the monitoring server 3, other monitoring clients 4, other devices configured in the communications 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 sound an audible or visual 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., to visually and / or audibly indicate the request to the user owning the device, which is then routed to the monitoring client 1 or remote communicator 11.

[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 within 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 queries a patient-care device paired to the system monitor 131 and then predicts a response to the query within a predetermined time. For example, the system monitor 131 may send a "System Monitor Query" text string message to the infusion pump 7. In this example, the infusion pump 7 receives the message labeled "System Monitor Query" from the system monitor 131 and processes the message using one or more processors therein. When the infusion pump 7 processes the message, a software routine therein executes code that sends 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 the processor provide an alarm or alert audibly or visually via the remote communicator 11).

[0175] As previously described, in some embodiments, the system monitor 131 increments a counter within the device being queried and then requests the value of the counter from the device after it has been incremented. For example, the system monitor 131 can 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 found in the memory location, and stores the new value in the same memory location by overwriting the previous value. In this example, the processor then 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 example, 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, after requesting that the value be updated in the queried device, predict to receive a value of 49 from the 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 can then be tasked with decrypting the message using, for example, an encryption key and sending the message back to the system monitor 131. The system monitor 131 can expect the unencrypted message to return within a predetermined time. In this example, 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 it to the monitoring client 1, the monitoring server 3, the hub 802 in FIG. 8, or the remote communicator 11, which can 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 wirelessly 12, thereby maintaining communication regardless of the patient's location within the facility or the provider's location, either within or outside the facility. 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, optionally, to other appropriate 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 smartphone) and communicated to the monitoring client 1, which can then be made known to the caregiver (e.g., a nurse, nurse practitioner, doctor, physician, or other healthcare professional) via the caregiver's own portable communicator 11. Additionally or alternatively, in some embodiments, new instructions can be communicated to the infusion pump 7 or patient monitoring devices 14-17, 35, 126, 128, 130, 148, thereby allowing a control system therein or coupled thereto to change its operation, e.g., setpoints, in response to the new instructions. In some embodiments, any information captured 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 deactivated, a new device can be assigned to the patient 2 and the patient's current information from the monitoring server 3 can be quickly re-added. Instructions, medications, progress notes, monitoring data, therapy data, patient therapy 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 analysis to verify compliance with predetermined 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 about a patient 2 and then populate that patient's monitoring client 1 with a predetermined set of information (e.g., the patient's age, height, weight, disease category, current medications and medication categories, drug allergies and sensitivities, etc.). According to one such embodiment, the monitoring server 3 can establish communication links to EHR 19, laboratory 20, radiology 21, pharmacy 22, and / or other systems (e.g., cardiology 23 or scheduling database 24) within a facility when, for example, the monitoring client 1 is assigned to patient 2. With a unique patient identifier, the monitoring server 3 can gain electronic access (permissions) to receive and transmit patient-specific data from and to these systems. A predetermined (selectable) subset of the data can 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, instructions entered remotely from communicator 11 can be intercepted and similarly checked by monitoring server 3. Monitoring server 3 can also obtain information from a medication database located within facility's pharmacy 22 or externally 9 to determine whether a new patient instruction may, for example, create an incompatibility with the patient's existing medications. In an embodiment of the present disclosure, monitoring server 3 can be programmed to access publicly available internet sites 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. Monitoring server 3 can also route information between 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 can 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 can then record the new orders and relay the request to the pharmacist 6 and the patient's nurse via the nurse's portable communicator 11 and / or via a fixed terminal at the nurse's station 5. A "smart phone" (e.g., Google's Nexus One phone, Apple's iPhone, or RIM's BlackBerry OS, among others) with a customized communication application in the monitoring client 1 can serve as a convenient portable communicator 11 for providers not in a fixed location (such as an office or remote nurse's station). A tablet PC, netbook, or laptop computer can also serve as a convenient portable communicator 11 for both portable and fixed locations. A PC can serve as a convenient communication device 11 for 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 attachable or dockable to 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 may be, for example, a handheld device approximately the size of a wireless phone or tablet netbook. It may conveniently have a touchscreen interface for use by the patient's provider. It may also provide output, through either a wired or wireless connection, to a larger fixed display in the patient's room, 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 from various other facility departments. In some cases, the monitoring client 1 can upload information it receives 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, including various drug information databases and alert networks that handle adverse drug-related events, are therefore accessible.

[0183] The monitoring server 3 can be deployed to manage various levels of external database information, for example, to help keep the content of the monitoring clients 1 as up-to-date as possible. This can be achieved, for example, by comparing patient-related safety and medication information as it becomes available and prioritizing updates / downloads on a data transfer schedule. The monitoring clients 1, 4 can also communicate with portable communicators 11 used by healthcare providers such as nurses, physicians, and pharmacists, either directly or through the monitoring server 3. 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 computers and devices 11. Alternatively, a handheld remote communicator 11 (such as a smart phone or tablet netbook) can communicate directly 12 with the facility's monitoring client 1 via a cellular network, and / or the facility can include a private cell network, which can 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 the 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, the wireless network provides the added capability of being able to communicate with the monitoring server 3 regardless of the patient's location within the facility.

[0185] One way to provide wireless coverage throughout a facility is to require the facility to obtain a license for a private cellular network. One or more microcellular frequencies can be acquired or rented to provide a local communications network throughout the facility. Such an arrangement allows patients and monitoring clients 1, 4 to maintain communications as they are moved from one location within the facility to another, maintaining connectivity with the monitoring server 3, various in-hospital and out-of-hospital databases 8, 25, and users at fixed stations (e.g., in some embodiments, the nurse's 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 licensed cellular communications infrastructure. Additionally, 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 a network may not allow for the efficient transmission of large data files, such as those containing radiological images. Such bandwidth-intensive data files may be communicated more efficiently via a wired connection.

[0186] Alternatively or additionally, a hospital can implement an internet- or intranet-based communication system in which 802.11 WiFi-type protocols are used for wireless communication between individual monitoring clients 1, 4 and the monitoring server 3. To ensure adequate signal reception throughout the facility, broadband antennas can be mounted on building roofs to collect cellular signals from local wireless carriers. A fiber optic or cable network can then distribute the signal throughout the facility. Additionally or alternatively, the monitoring server 3 can use the private cellular network described above. Such systems typically provide 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 can 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 can be used to provide patient data security. In some applications, it may be advantageous to implement an asymmetric bandwidth communication network to optimize infrastructure 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, or mesh network.

[0187] As previously described, communication between various monitoring devices, such as patient-care devices 14, 15, 16, 17, and 35 and monitoring client 1, can be cost-effectively achieved 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, such as TCP and UDP, can be utilized to ensure data fidelity and security. 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 CRC, odd parity bit check, or even parity bit check.

[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 in the system within a facility. Similar networks can be used to provide wireless links within a facility between a healthcare provider's portable communicator 11 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 a patient monitoring device (e.g., BP monitor 15) and instruct it to take an unscheduled reading. This may be useful, for example, if 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 one or more healthcare providers. In another embodiment, if the infusion pump 7 is capable of determining the amount of fluid being delivered to the patient 2 (e.g., the flow rate or cumulative amount of fluid pumped 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 signal the infusion pump 7 to reduce its flow rate to prevent drying out of the patient's intravenous access 35. For example, the monitoring client 1 can determine if a nurse is scheduled to return at a specific time to change the bag, and rather than warning 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, the 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 lit (e.g., begins to form a fully filled outer perimeter when the border is filled) indicates the progress of a therapy 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 complete to the monitoring client 1, in which case 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 setting 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 from each other before initiating treatment and / or configuring one of the infusion pumps 7 and / or the monitoring client 1, in this particular embodiment.

[0193] In some embodiments, a patient-care device 7, 170, 126, 128, 130, 14, 15, 16, 17, 124, or 148, a dock 102 or 104, a monitoring client 1, or 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 a 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 further disturbance to the patient.

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

[0195] In some embodiments, infusion pump 7 includes status LED lights that indicate one or more of: passing a safety check; the pump is flowing; there is an occlusion; and / or the pump is disconnected. A user can use monitoring client 1 to read a barcode on 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 intravenous bag 170 should be inserted therein.

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

[0197] Additionally, in some embodiments, some numbered or unnumbered items, components, devices, patient-care devices, docks, and computing devices 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, while certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, and 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 is used among the patient-care devices; in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered down, or not part of the system 100 of FIG. 1 . Additionally or alternatively, in some particular embodiments, only the patient-care devices 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 the device dock 102 only accepts 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 shows a flowchart diagram illustrating a method 150 for maintaining communication between a monitoring client, e.g., monitoring client 1 of FIG. 1, and one or more patient-care devices, e.g., one or more of patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 of FIG. 1, according to an embodiment of the present disclosure. Method 150 in this example includes operations 152-169. 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 communication link between the monitoring client and the monitoring-client dock through the dock connector. If the communication 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 communication 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, method 150 proceeds to operation 160; otherwise, 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, method 150 proceeds to operation 166; otherwise, 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, method 150 proceeds to operation 164.

[0205] Operation 158 determines whether the device dock is available as a communication link between the monitoring client and the device dock via a wireless link. If the communication link 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; for example, not all protocols use a handshake between communication endpoints. Decision operation 168 determines whether the handshake of operation 166 was successful. If decision operation 168 determines that the handshake of operation 166 was not successful, operation 164 determines that communication with the patient-care device is not available, and / or method 150 attempts to establish communication using 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 scheduling of communication links, although other schedules may be used, such as broadcast, anycast, multicast, or unicast, using a routing algorithm, a distance vector routing protocol, a link-state routing protocol, an optimized link-state routing protocol, a path vector protocol, static routing with predetermined alternate communication paths, and / or adaptive networking. For example, in some embodiments of the present disclosure, 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, and weight may be determined by any known method, including as a function of bandwidth, signal quality, bit error rate, which may be linear with available data throughput or latency, and / or other factors.

[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. System 300 is similar to system 100 of Figure 1, except that communication between the monitoring-client dock 102 and the device dock 104 is through a wireless link. For example, in some embodiments, system 300 of Figure 3 is system 100 of Figure 1 without cable 110 of Figure 1 present or inoperative; additionally, or alternatively, 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, e.g., 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 infusion pump 7, the syringe pump 126, and / or the 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, e.g., pill dispensing instructions, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, if a particular medication is taken as needed (i.e., when needed), but the medication may be unsafe if taken in excess, the maximum pill dispensing criterion can prevent the medication from being taken by the patient at an unsafe level, for example, in a given amount within 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, 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 300 is operating properly or within predetermined boundaries, and / or display the data on a display of the monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may optionally communicate, if applicable, the upstream pressure, the change in upstream pressure, the downstream pressure relative to patient 2, the change in downstream pressure relative to patient 2, the presence or absence of air in the infusion line, the actual bolus volume 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 monitoring client 1, other monitoring clients 4, and / or remote communicator 11. In another embodiment, pill dispenser 128 may optionally communicate data, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether a maximum pill dispensing standard was exceeded, back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11.

[0212] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined 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 an indication of excessive clotting, seepage, obstruction, or kinking of the tubing to the patient, or an 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 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 monitoring clients 1, 4, 11 can visually or audibly warn or alert a user. One or more of monitoring clients 1, 4, 11 can optionally send instructions to one or more of infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

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

[0214] Additionally, in some embodiments, some numbered or unnumbered items, components, devices, patient-care devices, docks, and computing devices, 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, while certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, and 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 is used among the patient-care devices; in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered down, or not part of the system 300 of FIG. 3 . Additionally or alternatively, in some embodiments, only the patient-care devices 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 the device dock 102 only accepts 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, compartments of the dock may be unused, e.g., as shown in FIG. 3, 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, according to 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, method 202 proceeds to operation 206; otherwise, 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, method 202 proceeds to operation 206; otherwise, 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 via 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] Act 212 determines whether the device dock is available as a communication link between the device dock and the patient-care device. If the communication link of act 212 is available, method 202 proceeds to act 216; otherwise, method 202 proceeds to act 214.

[0222] Act 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 act 214 is available, method 202 proceeds to act 216; otherwise, act 218 determines that communication with the patient-care device is not available.

[0223] Act 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 act 220 determines if the handshake was successful and if communication between the monitoring client and the device was established. If act 220 determines that a communication link was established, method 202 communicates data between the monitoring client and the device during act 222 using the available communication link(s). If decision act 220 determines that the handshake was not successful, method 202 determines that communication with the device is not available in act 218, or method 202 attempts communication between the monitoring client and the device over an unverified communication link (not explicitly shown).

[0224] Method 202 is an exemplary embodiment of the present disclosure that describes a method for maintaining communication between a monitoring client and one or more patient-care devices. In some embodiments, method 202 includes scheduling of communication links, although other schedules may be used, such as broadcast, anycast, multicast, or unicast, using a routing algorithm, a distance vector routing protocol, a link-state routing protocol, an optimized link-state routing protocol, a path vector protocol, static routing with predetermined alternate communication paths, and / or adaptive networking. For example, in some embodiments of the present disclosure, 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, and weight may be determined by any known method, including as a function of bandwidth, signal quality, bit error rate, which may be linear with available data throughput or latency, and / or other factors.

[0225] 5, there is shown an electronic patient-care system 500 in block diagram form having a dock 502, a communications 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, communications module 124D, and dongle 133 are all dockable to the dock 502. As will be appreciated in light of the present disclosure, the dock 502 can include one or more buses, backplanes, communications 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, e.g., 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 infusion pump 7, the syringe pump 126, and / or the 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, e.g., pill dispensing instructions, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, if a particular medication is taken as needed (i.e., when needed), but the medication may be unsafe if taken in excess, the maximum pill dispensing criterion can prevent the medication from being taken by the patient at an unsafe level, for example, in a given amount within 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, 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 500 is operating properly or within predetermined boundaries, and / or display the data on a display of the monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may optionally communicate, if applicable, the upstream pressure, the change in upstream pressure, the downstream pressure relative to patient 2, the change in downstream pressure relative to patient 2, the presence or absence of air in the infusion line, the actual bolus volume 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 monitoring client 1, other monitoring clients 4, and / or remote communicator 11. In another embodiment, pill dispenser 128 may optionally communicate data, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether a maximum pill dispensing standard was exceeded, back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11.

[0228] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined 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 an indication of excessive clotting, seepage, obstruction, or kinking of the tubing to the patient, or an 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 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 monitoring clients 1, 4, 11 can visually or audibly warn or alert a user. One or more of monitoring clients 1, 4, 11 can optionally send instructions to one or more of infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

[0229] 5 or described herein is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, equipment service 8 is optional, each of services 19, 20, 21, 22, 23, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online drug database 9 is optional, adverse drug events network is optional, patient's personal EHR 19' is optional, and / or treatment outcomes database 10 is optional. Additionally or alternatively, in some embodiments, each of patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 is optional. Similarly, the system monitor 131, wrist band 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply 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, while certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, and 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 is used among the patient-care devices; in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered down, or not part of the system 500 of FIG. 5 . Additionally or alternatively, in some particular embodiments, only the patient-care devices 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 the device dock 102 only accepts 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 be unused, 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, e.g., monitoring client 1 of FIG. 5, and one or more patient-care devices, e.g., one or more of patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 of FIG. 5, according to an embodiment of the present disclosure.

[0234] During operation 306, the method determines whether the dock is available as a communication link between the monitoring client and the dock through the dock connector. If the communication link in 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 in 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 via a wireless link. If the communication link of operation 308 is not available, method 304 proceeds to operation 310; otherwise, method 304 proceeds to operation 312.

[0236] Act 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 act 312 is not available, act 316 determines that communication between the monitoring client and the patient-care device is not available.

[0237] Act 314 attempts a handshake between the monitoring client and the device using the available communication link(s). In an alternative embodiment, 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 act 320 to communicate data using the available communication link(s). If decision operation 318 determines that the handshake was not successful at act 314, act 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 act 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 for maintaining communication between a monitoring client and one or more patient-care devices. In some embodiments, method 304 includes scheduling of communication links, although other schedules may be used, such as broadcast, anycast, multicast, or unicast, using a routing algorithm, a distance vector routing protocol, a link-state routing protocol, an optimized link-state routing protocol, a path vector protocol, static routing with predetermined alternate communication paths, and / or adaptive networking. For example, in some embodiments of the present disclosure, 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, and weight may be determined by any known method, including as a function of bandwidth, signal quality, bit error rate, which may be linear with available data throughput or latency, and / or other factors.

[0239] 7, a block diagram of an electronic patient-care system 700 having a monitoring client 1 with an integrated dock 702 for docking patient-care devices 7, 126, 128, 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 the integrated dock 702. In some embodiments, the monitoring client 1 communicates with the patient-care devices when docked via the dock; however, 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, e.g., 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 infusion pump 7, the syringe pump 126, and / or the 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, e.g., pill dispensing instructions, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, if a particular medication is taken as needed (i.e., when needed), but the medication may be unsafe if taken in excess, the maximum pill dispensing criterion can prevent the medication from being taken by the patient at an unsafe level, for example, in a given amount within 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, other monitoring clients 4, and / or 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, other monitoring clients 4, and / or remote communicator 11. For example, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may optionally communicate, if applicable, the upstream pressure, the change in upstream pressure, the downstream pressure relative to patient 2, the change in downstream pressure relative to patient 2, the presence or absence of air in the infusion line, the actual bolus volume 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 monitoring client 1, other monitoring clients 4, and / or remote communicator 11. In another embodiment, pill dispenser 128 may optionally communicate data, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether a maximum pill dispensing standard was exceeded, back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11.

[0242] Data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 can be analyzed for any predetermined 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 an indication of excessive clotting, seepage, obstruction, or kinking of the tubing to the patient, or an 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 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 monitoring clients 1, 4, 11 can visually or audibly warn or alert a user. One or more of monitoring clients 1, 4, 11 can optionally send instructions to one or more of infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery in response to a sudden increase and / or decrease in downstream pressure to patient 2.

[0243] 7 or described herein is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, equipment service 8 is optional, each of services 19, 20, 21, 22, 23, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online drug database 9 is optional, adverse drug events network is optional, patient's personal EHR 19' is optional, and / or treatment outcomes database 10 is optional. Additionally or alternatively, in some embodiments, each of patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, and 148 is optional. Similarly, the system monitor 131, wrist band 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply 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, although 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 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, an integrated dock 702 may be used.

[0245] Additionally or alternatively, while certain patient-care devices 7, 14, 15, 16, 17, 126, 128, 130, and 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 is used among the patient-care devices; in this particular example, the other patient-care devices 14, 15, 16, 17, 126, 128, 130, and 148 may be disabled, not present or available for system use, powered down, or not part of the system 700 of FIG. 7 . Additionally or alternatively, in some particular embodiments, only the patient-care devices 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 accepts 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, compartments of the dock may be unused, for example, 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 communications 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 communicators 11. For example, the hub 802 can communicate with the monitoring server 3, facility services 8, nurses' stations 5, pharmacies 6, cloud servers 25, online drug databases or adverse drug events networks 9, patients' personal EHRs 19, and / or treatment outcomes databases 10. The hub 802 can provide a clock so that all devices connected thereto (e.g., patient-care devices, monitoring clients, remote communicators, etc.) use the hub 802's clock, real-time devices use the hub 802's clock, or time-critical devices use the hub 802's clock.

[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 predetermined group of infusion pumps 830, monitoring clients 1, the hub 802, the caregiver, and / or the patient must be at a predetermined distance from each other before initiating treatment and / or configuring one of the infusion pumps 830, the hub 802, and / or the monitoring client 1, in this particular embodiment.

[0249] In some embodiments, the hub 802 includes an application programming interface (API) for displaying GUIs, windows, data, etc. on the monitoring client 1 and / or remote communicator 11. The API may include secure data classes. In yet additional embodiments, the dock 102, 804, and / or 806 includes an API for displaying GUIs, windows, data, etc. on the monitoring client 1 or remote communicator 11. In yet additional embodiments, the dock 102, 804, or 806 or the hub 802 includes an API for displaying GUIs, 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 the Request Action Framework.

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

[0254] Optionally, in yet further particular embodiments, a barcode attached to intravenous bag 170 can be scanned by scanner 120 to download a predetermined prescription (e.g., from the patient's personal EHR 19′) and / or include a predetermined prescription that is uploaded to hub 802 when infusion pump 830 is docked to dock 804. In this particular embodiment, and optionally, hub 802 then begins the infusion of intravenous bag 170 into patient 2 and monitors the progress of the treatment to ensure patient 2's safety. Additionally, alternatively, or optionally, in this particular embodiment, a caregiver can interact with system 800 as shown in FIG. 8 solely through hub 802. Optionally, in some embodiments, hub 802 uploads treatment, condition, or patient information to 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, device dock 804 receives infusion pumps 830, 810, and 812. In some embodiments, device dock 804 receives one, two or more, or multiple patient-care devices. Device dock 806 receives pill dispenser 814. In some embodiments, device dock 806 receives one, two or more, or multiple patient-care devices, such as pill dispenser 806. Device dock 804 includes antenna 816 for wireless communication, and device dock 806 includes antenna 818 for wireless communication. Similarly, hub 802 includes antenna 820 for wireless communication. Additionally or alternatively, device dock 804, hub 802, and / or monitoring client 1 communicate with each other using wired connections. Hub 802 and docks 804 and 806, respectively, can communicate with each other using, for example, a USB cable, 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 detachable 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 to send instructions or requests to the patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830, 148, such as 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. 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, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria for dispensing pills. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, if a particular medication is taken as needed (i.e., when needed), but the medication may be unsafe if taken in excess, the maximum pill dispensing criterion can prevent the medication from being taken by the patient at an unsafe level, for example, in a given amount within 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, 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 800 is operating properly or within predetermined boundaries, and / or display the data on a display of the monitoring client 1, other monitoring clients 4, and / or remote communicator 11. For example, one or more of infusion pumps 830, 810, 812 can optionally communicate the upstream pressure, the change in upstream pressure, the downstream pressure relative to patient 2, the change in downstream pressure relative to 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 monitoring client 1, other monitoring clients 4, and / or remote communicator 11. In another embodiment, pill dispenser 814 can optionally transmit data back to monitoring client 1, other monitoring clients 4, and / or remote communicator 11, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether a maximum pill dispensing standard 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 predetermined condition to generate an alarm and / or warning. 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 out of 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 shown in FIG. 8 or described herein is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, equipment service 8 is optional, each of services 19, 20, 21, 22, 23, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online drug database 9 is optional, adverse drug events network is optional, patient's personal EHR 19' is optional, and / or treatment outcomes database 10 is optional. Additionally or alternatively, in some embodiments, each of patient-care devices 830, 810, and 812 is optional. Similarly, system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power are each optional in some embodiments of the present disclosure.

[0260] Additionally, in some embodiments, although some numbered or unnumbered items, components, devices, patient-care devices, docks, and computing devices 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 arbitrary 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, while specific patient-care devices 830, 810, 812 are shown, other combinations, subsets, multiples, or combinations of 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. 8. 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 can receive one patient-care device, multiple patient-care devices, or any arbitrary number of patient-care devices. Also, compartments of the dock may be unused (not shown in FIG. 8). 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. 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] 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 predetermined alternate communication paths may be used, and / or adaptive networking may be used. For example, in some embodiments of the present disclosure, a weight may be assigned to each communication path, 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 weight may 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 other factors.

[0264] In an embodiment of the present disclosure, the equipment service 8 and / or the adverse drug event network 9 may also include a medication error reduction system (DERS). The DERS system may include a first set of predetermined criteria for triggering a soft alarm and / or a second set of predetermined criteria for triggering a hard alarm. A soft alarm can be overridden (e.g., silenced) 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, while a hard alarm suspends treatment until the cause of the hard alarm is removed (and may be an audible and / or vibration alarm only).

[0265] In yet additional embodiments of the present disclosure, the DERS system can include a first set of predetermined criteria defining soft limits and / or a second set of predetermined criteria defining hard limits. The hard and soft limits define treatment limits, such as drug dosage, based on dimensions, weight, age, other patient parameters, or other criteria. The soft limits can be overridden by a caregiver using the user interface of the infusion pump 830, the user interface of the monitoring client 1, and / or the user interface 808 of the hub 802 to initiate treatment even though the treatment is outside the first set of predetermined criteria, while the hard limits prevent treatment from initiating until settings are changed to meet the second set of predetermined 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] Referring again to the drawings, Figure 9 shows a block diagram of an electronic patient-care system 900 having a stackable monitoring client 902, a stackable infusion pump 904, a stackable syringe pump 906, and another stackable patient-care device 908 in accordance with yet another embodiment of the present disclosure. The stackable devices 902-908 can communicate using a backplane and / or bus (in some embodiments, the stackable devices 902-908 communicate via a communication module).

[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 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, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria for dispensing pills. A maximum pill dispensing criterion is the maximum amount of medication that can be delivered within a given time interval; for example, if a particular medication is taken as needed (i.e., when needed), but the medication may be unsafe if taken in excess, the maximum pill dispensing criterion can prevent the medication from being taken by the patient at an unsafe level, for example, in a given amount within 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, stackable infusion pump 904, stackable syringe pump 906, and / or other stackable patient-care devices 908 can communicate, if applicable, the upstream pressure, the change in upstream pressure, the downstream pressure relative to patient 2, the change in downstream pressure relative to 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 monitoring client 902, other monitoring clients 4, and / or remote communicator 11. In another embodiment, pill dispenser 128 can optionally communicate data, such as the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether a maximum pill dispensing standard was exceeded, back to stackable monitoring client 902, other monitoring clients 4, and / or remote communicator 11.

[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 an indication of excessive clotting, seepage, obstruction, or kinking of the tubing to the patient, or an obstruction by other material within 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 fluid delivery 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 alternatively be stacked on top of the monitoring client 902, whereby the bottom connector of the stackable syringe pump 906 is electrically coupled to the connector on the top of the monitoring client 902.

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

[0273] Additionally or alternatively, stackable devices 902, 908, 904, 906 can optionally maintain wireless communication with one another. For example, stackable monitoring client 902 can detect that the daisy-chained conductors are electrically unresponsive due to an internal short within one of stackable devices 902, 908, 904, 906, and can query each stackable device 908, 904, 906 to determine which device has failed. After making the determination, stackable monitoring client 902 can wirelessly communicate with an isolated disconnect circuit within the failed one of stackable devices 902, 908, 904, 906 to electrically disconnect 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 warning that one of the stackable devices 902, 908, 904, 906 has failed and / or that one of the stackable devices 902, 908, 904, 906 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 can each relay or retransmit information to the respective device below or above it in the daisy chain. For example, the stackable infusion pump 904 can communicate all of the data received from the stackable syringe pump 906 by buffering the data in internal memory and communicating the information when it receives a signal from the stackable patient-care device 908 indicating that the stackable patient-care device 908 is ready to receive additional data. In some embodiments, each numbered or unnumbered item, component, device, patient-care device, dock, and computing device shown in FIG. 8 or described herein is optional. For example, in some embodiments, monitoring client 1 is optional, monitoring server 3 is optional, facility service 8 is optional, each of services 19, 20, 21, 22, 23, and 24 is optional, cloud server 25 is optional, each of other monitoring clients 4 is optional, online drug database 9 is optional, adverse drug events network is optional, patient's personal EHR 19' is optional, and / or treatment outcomes database 10 is optional. Additionally or alternatively, in some embodiments, each of patient-care devices 830, 810, and 812 is optional. Similarly, system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power are each optional in some embodiments of the present disclosure.

[0275] Additionally, in some embodiments, some numbered or unnumbered items, components, devices, patient-care devices, and computing devices, as shown in Figure 9 or described herein, are shown as only one item, component, device, patient-care device, or computing device, 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, while specific patient-care devices 904, 906, and 908 are shown, other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. For example, in some embodiments, only the stackable infusion pump 904 of the patient-care devices is used; in this particular example, the other patient-care devices 906 and 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 used are stacked. For example, in one particular embodiment, the infusion pump 904 is the only stacked device. Additionally or alternatively, patient-care devices that are not stacked, such as patient-care devices 904, 906, and / or 908, may continue to operate if operating as standalone devices. Additionally, alternatively or optionally, in some particular embodiments, the 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, but 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] 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 predetermined alternate communication paths may be used, and / or adaptive networking may be used. For example, in some embodiments of the present disclosure, 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, which may be linear with available data throughput or latency, and / or other factors.

[0279] With reference to Figures 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 within 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 orchestrate the downloading of software into flash memory by a supervisor processor and / or command processor. In some embodiments, the computing device can orchestrate the downloading of software into flash memory of the hub, dock, device, insulin pump, infusion pump, and / or patient-care device. Software updates obtained by the computing device can be sent to flash memory (not shown) accessible by the supervisor processor and / or command processor. The software updater 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 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, through email, and / or by wireless communication protocol. Thus, in various embodiments, the remote interface application may run on any functional device and is not limited to so-called dedicated devices. Furthermore, in some embodiments, the remote interface may be Bluetooth-enabled or otherwise enabled to communicate, e.g., using radio frequency (RF) communications, with one or more devices, including, but 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, for 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 via 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 via connection to a computer or other device and / or computer-type appliance. 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 available, 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 can connect the 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, upload data from the remote interface to a web portal or the like. In some embodiments, this can be accomplished while the remote interface is "recharging," which in some embodiments can be done using a USB connection to a personal computer, which can synchronize 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 can determine if software updates are available for one or more of the devices and / or the remote interface. The user can select "download updates," and these can be downloaded to the remote interface of the hub, dock, device, insulin pump, infusion pump, and / or patient-care device when charging and / or 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 devices of the remote interface. This has many advantages, including, but not limited to, simply connecting the remote interface to a personal computer / web portal to both upload data / information from all of the devices and / or download updates and / or applications from a personal computer and / or from the internet / web portal to any of the devices. This may be desirable for many reasons, including, but not limited to, the ability to efficiently and easily update all devices from one connection, and / or the ability to view all of the data from all devices in one location, and / or the ability to download information and / or settings from a personal computer / web portal to any of the devices via a remote interface.

[0283] Thus, in some embodiments, since the personal computer / web portal contains all information from all devices, including, but not limited to, remote interfaces, a new "remote interface" can be introduced to the system at any time. This can be accomplished by connecting the new remote interface to the personal computer / web portal and downloading all information 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 can communicate 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 certain parameters, such as the ability to wirelessly communicate and connect to a personal computer and / or web portal) into a device that can control various devices, e.g., infusion pumps, and / or receive data from and / or control CGM sensors / transceivers, 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, e.g., infusion pumps and / or CGM sensors 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 may 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 flowchart diagram of a method 600 for communicating patient-care parameters of a patient-care device to a monitoring server according to an embodiment of the present disclosure. Method 600 includes operations 602-608. The patient-care device of method 600 may optionally be any patient-care device disclosed herein, 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, for example, over a local area network and / or the Internet, via WiFi, through a monitoring client, one or more hubs, or docks. Operation 606 de-identifies the patient-care parameters. Operation 606 can be performed automatically and electronically, for example, within the monitoring server 3 of FIGS. 1, 3, 5, 7, 8, and / or 9. For example, the patient's name can be removed and replaced with a random serial number or other indicia that cannot be used to determine the patient's identity within the monitoring server. Operation 608 stores the de-identified patient-care parameters within the monitoring server in a database, for example, an SQL database, a relational database, an associative database, a cloud server, or the like.

[0288] 11 is a flowchart diagram of a method 701 for collecting patient-care parameters from multiple patients as determined from 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 multiple patient-care devices associated with multiple patients. Optionally, multiple patient-care devices can be associated with a single patient and / or multiple patient-care devices can 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 plurality of patients. For example, patients with high blood pressure can be treated with a medication designated to lower their 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 medication in 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 one or more patients.

[0291] 12 is a flowchart diagram of a method 801 for recovering a patient-care device 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 unplugged, power may be interrupted, 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 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 wireless communication wattage limit, a battery discharge rate or rate limit, an update frequency, etc. Act 809 stores the one or more operating parameters in 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 non-volatile memory of the patient-care device.

[0296] Act 815 determines that operation of the patient-care device has been interrupted, for example, 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 resume.

[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 flowchart 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 FIGS. 1, 3, 5, 7, or 8, the monitoring client 902 of FIG. 9, the remote communicator 11 of FIGS. 1, 3, 5, 7, 8, or 9, a mobile phone, a handheld computer, a tablet computer, a laptop computer, a personal computer, a personal digital assistant, or the like. Although method 900 describes pairing between a monitoring client and a patient-care device, in some embodiments, method 900 is used to pair a hub (e.g., hub 802 in 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 in FIG. 8) to a second patient-care device (e.g., patient-care device 814 in FIG. 8), thereby allowing the 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, touchscreen, display, buttons, an 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 can be identified, for example, by a serial number, a device type, or a visual indication on the patient-care device's 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 can touch the touchscreen 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. Custom pairing protocols, which may or may not utilize a handshake sequence, can also be utilized, as will be apparent in light of this disclosure. Act 910 communicates patient-care parameters between the patient-care device and the monitoring client, for example, thereby allowing the patient-care device to be controlled or monitored by the monitoring client.

[0301] OPERATION 912 optionally operatively communicates additional patient-care parameters with or through another patient-care device. In OPERATION 912, if the patient-care device is operatively coupled to or operatively communicating with another patient-care device, the patient-care device can act as a relay or router, allowing the monitoring client to communicate with the other patient-care device. Additionally or alternatively, the patient-care device can use information from the other patient-care device for its operation; for example, an infusion pump can use a flow rate determined by a flow meter or a temperature from a temperature probe, and / or the infusion pump can relay information from the flow meter to the monitoring client. Additionally, the monitoring client can 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 in or attached to the intravenous line, via electrical communication using the fluid in the intravenous line as a conductive medium, using sound waves traveling through the intravenous line, or optically using the fluid in the line as an optical waveguide. Communication via the intravenous line may be used to establish pairing (e.g., between a monitoring client, a hub, a dock, a patient-care device, and / or a 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 communication or IR communication can establish pairing between the devices using, for example, Bluetooth, Bluetooth low energy, or WiFi. Establishing the pairing (e.g., via near-field communication or IR communication) can instruct the monitoring client, hub, patient-care device, and / or system monitoring to request user confirmation of the pairing devices, such as pairing via Bluetooth. In some embodiments, when a patient-care device is paired with a hub, monitoring client, and / or dock, an ID and software version number are sent to the hub, monitoring client, and / or dock, which checks with a server, e.g., monitoring server 3, middleware, cloud server, or other server, to determine whether the software on the patient-care device is up to date. If the software is not up to date, the hub, monitoring client, dock, or patient-care device itself (e.g., directly) downloads updated software and programs the patient-care device. The patient-care device can communicate to the user if the software is up to date and / or provide the user with an option on a touchscreen to optionally update the patient-care device if the software is not up to date. The communication link that establishes the pairing (e.g., NFC) and / or the communication link that uses the pairing (e.g., Bluetooth or Bluetooth low energy) can communicate the updated software, ID, software version number, provide notifications, etc.For example, one pairing that may be used with a pump patient care device or insulin pump is described in (1) a patent application entitled "INFUSION PUMP METHODS AND SYSTEMS" by Mandro et al., filed March 25, 2010, attorney docket number I06, application serial number 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 number G98, application serial number 12 / 416,662; and / or (3) a patent application entitled "INFUSION PUMP ASSEMBLY" by Kamen et al., filed December 31, 2009, attorney docket number G75, application serial number 12 / 347,985. No. 6,299,333, and entitled "Method and Assembly," all three of which are incorporated herein by reference.

[0303] 14 is a flowchart diagram of a method 1000 of monitoring the 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 can utilize various devices 1002, 1004, 1006, 1008, 1100, 1112 to facilitate the pairing of the wearable system monitor to the patient-care device of method 1000. 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 Figures 1, 3, 5, 7, 8, and 9. Pairing of the system monitor of method 1000 to monitor one or more patient-care devices can be performed using any one or more of devices 1002-1012, or any sufficient device disclosed herein. For example, the wearable system monitor of method 1000 can 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 any 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 barcode, an RFID tag, near-field communication, a simple login, a secure signature, etc. 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 communications module, another dock, or a hub using an onboard 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 displayed font 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 capable of storing the picture, the picture can be transmitted to a middleware server for storage. Act 1016 records the presence of the caregiver on one or more of 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 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, thereby attached to the patient with a wristband similar to that of a watch, and portions of the wearable system monitor may be removed from the wristband and a dock (also referred to herein as a "wearable dock") that includes 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 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 one or more of, for example, a voice recognition algorithm, a facial recognition algorithm, a barcode, an RFID tag, near-field communication, simple login, caregiver input, etc. Operation 1026 may be similar to operation 1014, may utilize the same software utilized in operation 1014, and / or may utilize one of devices 1002-1020. However, 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 administered to the correct patient and / or to provide compliance with certain regulations. 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 administered to the correct patient and / or to provide compliance with given regulations.

[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 within 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 the present 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 whether the wearable system monitor and the wearable dock are authorized to dock with each other. For example, act 1038 can ensure that the wearable system monitor is docked to the correct patient's wearable dock. For example, if the wearable system monitor is docked to the wrong patient's wearable dock, the wearable system monitor can recognize the error and (in some embodiments) prevent 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 client 1, 4, or 11 of FIGS. 1, 3, 5, 7, and 8, monitoring client 9, 4, or 11 of FIG. 9, or any other monitoring client 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 specific embodiments, if a caregiver is identified in operation 1016 and / or a patient is identified in operation 1026, the caregiver may update treatment settings, for example, on a monitoring client, hub, remote communicator, or patient-care device.

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

[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 can be replaced by a hub, a communications module, another patient-care device, or any other sufficient device having a user interface. The user interface template of method 1100 provides specific areas on a given display for displaying patient-care parameters. For example, a user interface template for an infusion pump can define a specific area for displaying on the GUI, such as the current fluid flow rate. The user interface template can also define an area on the monitoring client's display for displaying the current fluid flow rate, such as received from the infusion pump. The user interface template can include layout information, such as instructions for how to display information, descriptions of various widgets, graphs, labels for the graph axes, labels for the display, buttons, and / or labels for providing controls or visual information to the user for one or more patient-care devices. The user interface template can be a template describing a QT-based template and / or can use HTML or CSS.

[0319] Act 1102 identifies or selects a patient-care device for communication with the monitoring client having a user interface. For example, in act 1102, the monitoring client may automatically identify a predetermined infusion pump previously designated by the patient's treating provider. 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 about the operation of the selected patient-care device(s) on the monitoring client's user interface.

[0320] Act 1104 determines whether the patient-care device has a stored user interface template. For example, an infusion pump may have 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 the 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 the current infusion rate, and act 1112, in this example, displays the current infusion rate (a patient-care parameter) on the display using the user interface template.

[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 patient-care parameters on the patient-care device. Additionally or alternatively, act 1104 can raise an alarm via the monitoring client and / or the patient-care device. Act 1114 determines the type of 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 patient-care device. If a user interface template is present, 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, patient-care parameters such as an infusion rate can be displayed within a predetermined 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 multiple user interface templates on a user interface of the monitoring client, and additionally or alternatively, act 1114 can 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 multiple 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, pre-stored fonts, etc., and communicated for use within a field to provide a display of the operational parameter (e.g., rather than communicating the 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 the value of the operational parameter is sent to the monitoring client for display within the template using the font stored within the monitoring client.

[0324] 16 is a flowchart diagram of a method 1134 of downloading an application for controlling a patient-care device according to an embodiment of the present disclosure. Although a monitoring device is described in method 1134 of FIG. 16 as an exemplary device for controlling the patient-care device, 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, operations 1136-1146 are optional. The monitoring client of method 1134 may optionally be monitoring client 1, 4, or 11 of Figures 1, 3, 5, 7, or 8, monitoring client 9, 4, or 11 of Figure 9, or one of other monitoring clients disclosed herein. The patient-care device of method 1134 may optionally be patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, or 148 of Figures 1, 3, 5, or 7, patient-care device 14, 15, 16, 17, 830, 810, 812, or 814 of Figure 8, patient-care device 14, 15, 16, 17, 904, 906, or 908 of Figure 9, or one of other patient-care devices disclosed herein. The server of the method 1134 may optionally be one of the monitoring servers 3 of FIGS.

[0326] Act 1136 docks a patient-care device into the dock. For example, infusion device 7 of Figures 1, 3, 5, or 7, infusion devices 830, 810, or 812 of Figure 8, or infusion device 904 of Figure 9 may be docked into their respective docks. 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 via, for example, a discovery protocol. The docked patient-care devices may store therein treatment information (e.g., medication amount, infusion rate, total fluid volume, or other patient treatment parameters) that may be associated with or correspond to a patient.

[0327] At act 1140, the monitoring client queries the server for an application for controlling a patient-care device (e.g., for setting an infusion rate). At act 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 act 1144, the monitoring client executes the application. At act 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 execute 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 the 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 volume, infusion flow rate, total fluid 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 flowchart diagram of a method 1200 for ensuring data integrity when communicating data (eg, requests) for patient-care devices according to an embodiment of the present disclosure. Method 1200 includes operations 1202-1222. In some embodiments, operations 1202-1222 are 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, or the like.

[0330] Act 1202 submits a request to a patient-care device using a user interface of the monitoring client. For example, using the touchscreen of monitoring client 1 of FIG. 1, a user submits an infusion rate to 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 be delivered, 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 criteria.

[0331] Act 1204 is optional and may display a "pending request" on the 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 meet the communication requirements of the patient-care device.

[0332] Act 1208 determines a check value for the request. For example, a cyclic redundancy check algorithm is used to determine the check value corresponding to the request. 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 requests confirmation from the user for communicating the request using a user interface. The request for confirmation may be a pop-up dialog box on a touchscreen displaying "Did you confirm the 90 ml / hour infusion rate?" with a box for selecting "Confirm." The text and formatting shown in act 1212 may be in a different font, font size, and / or display location than other displayed information, such as that displayed during request entry, to provide additional safeguards against bad display pixels, corrupted font tables, user misinterpretation, and the like. Act 1214 confirms the request for communication using a user interface. The user may touch the "Confirm" box to confirm the request for communication 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] Act 1218 of method 1200 facilitates detection of corrupted data. During act 1218, the patient-care device authenticates the check value according to the request. In act 1218, the patient-care device can use the same cyclic redundancy check algorithm as act 1208 on the request to calculate an additional check value. The check value of act 1216 as calculated by the patient-care device is identical to the check value calculated in act 1208 only if the data in the request is identical. That is, the check value of act 1216 and the check value of act 1208 differ only if the data in the request is corrupted, has fewer or more bits, or is not identical to the digital data used to determine the check value of act 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 can proceed to any of acts 1202-2116. If the retransmission of the request is not successful, method 1200 can 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 act 1218 is additionally 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, in this alternative embodiment, may check to determine whether the request is within a predetermined range (e.g., whether the infusion rate for a particular medication is safe). In this alternative embodiment, the monitoring client may compare the request received from the patient-care device with the original request stored in memory (allowing the requests to be correlated), and / or the monitoring client may display the request to the user for confirmation. The request for confirmation may be a pop-up dialog box on a touchscreen displaying "Did you confirm the 90 ml / hour infusion rate?" with a box to select "Confirm." The text and format shown in this alternative embodiment for confirmation may be in a different font, a different font size, and / or a different display location than other displayed information, such as that displayed during request entry, 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 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 carried out. Additionally or alternatively, 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 the '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. 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, for example, provide USB or other standard communication 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 to which a patient-care device 1320 is docked. The wireless dock 1306 may be the same as or similar to the dock 1304, although in some embodiments the wireless dock 1306 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 an on-board battery 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 specific connector pins 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 each other. 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 optionally ensures that the patient-care device 1318 is operating properly by making the above-mentioned inquiries and monitoring the output of the patient-care device 1318 to determine whether it is within a predetermined range (e.g., a physically possible or probable range) and may have feedback that follows the input applied or is operating properly. Additionally or alternatively, the system monitor 13010 may optionally monitor the operation of the monitoring client 1302 through the cable 1308. While one watchdog 1310 is described herein, one or more watchdogs 1310, e.g., multiple watchdogs 1310, may 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 a 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 a red LED 1326. The reaction action 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 via cable 1308. For example, on 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 when the patient-care device 1326 is operating properly or is currently treating a patient. Additionally or alternatively, a speaker within the monitoring client 1302 may emit 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 pre-programmed 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, for example, an audible sound using the speaker 1324 or flashing an LED 1326 red. In some embodiments, a speaker within the monitoring client 1302 can emit an audible alarm. In some embodiments, a speaker within 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, and may or may not include an 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 on 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. System 1400 includes a monitoring client 1402, a dock 1404, a large-volume pump 1406, a syringe pump 1408, and a sensor 1410. System 1400 also includes a USB sensor 1412 coupled to dock 1404 through a USB cable, a wireless sensor 1414 in wireless communication with dock 1404, a server 1416, and a hospital information server 1418. Monitoring client 1402 may be any monitoring client, such as one of monitoring clients 1, 4, or 11 of FIGS. 1, 3, 5, 7, and 8, monitoring clients 9, 4, or 11 of FIG. 9, a tablet, a smart phone, a PDA, or a laptop. 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. Note that other embodiments may utilize connections other than USB type.

[0353] Connectors 1438-1450 enable dock 1404 to operably supply power to large volume pump 1406, syringe pump 1408, and sensor 1410. Additionally or alternatively, connectors 1438 and 1440 provide serial communication between dock 1404 and large volume pump 1406, connectors 1442 and 1444 provide serial communication between large 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 contains electrical conductors such that both of its connectors contain 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 convert the dock 1404's protocol 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 service 8 of FIGS. 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 AC power 1420. The AC / DC converter 1452 can 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 can 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 the power and ground planes of a PCB board, respectively. 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 charging circuitry 1460. Charging circuitry 1460 charges a primary battery 1462 and a backup battery or supercapacitor 1464. Charging circuitry 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, but can also 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 inserted therein (each optional).

[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 1466 at predetermined intervals or may expect a communication from the primary processor 1466 at predetermined intervals. If the safety processor 1468 does not receive the expected 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 the LED fault status light 1401, generate an audible sound using the backup speaker 1403, or vibrate the dock 1404 using the 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 supplied through the device connector using the current sense circuit 1407. If the safety processor 1468 determines that the current supplied to the device connector 1438 exceeds a predetermined threshold or is out of specification, the safety processor 1468 signals the power enable circuit 1409 to remove power supplied from the primary battery 1462 to the device connector 1438. The power enable circuit 1409 may include a relay, switch, solid state switch, 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, for example, 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, for example, by ultrasound, RF, UHF, electromagnetic energy, optics, etc., to determine the distance therebetween. According to one 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 exemplary arrangement of a system 2100 including 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 microinfusion pump 2110, with a monitoring client 2102 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 microinfusion pump 2110 (via the docks 2120, 2104), and the pill dispenser 2114. Alternatively, the monitoring client can communicate wirelessly with the patient-care devices, as suggested by the lack of a wired connection between the drip detection device 2112 and the monitoring client 2102. In embodiments, the wired connection between the monitoring client 2102 and the patient-care devices also provides the opportunity for power to be supplied from the monitoring client 2102 to the patient-care devices. In this case, the monitoring client 2102 can include the necessary electronic circuitry to convert voltage to power the patient-care devices, either from a battery installed in the monitoring client 2102 or from line voltage supplied to the monitoring client 2102 from a power outlet in the patient's room (not shown). Additionally or alternatively, the dock 2104 provides power to the infusion pumps 2106, 2108 and the microinfusion pump 2110.

[0369] In embodiments, 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 attached. 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 a particular device. For example, in FIG. 21 , the infusion pumps 2106 and 2108 can be attached to the dock 2104 via similar connection mounts, and the microinfusion pump 2110 can be attached to the dock 2104 via a connection mount configured to the specific dimensions of the housing of the microinfusion 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 EMR records to verify 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 via 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 transmitted to the monitoring client 2102 that can (1) display the fluid flow rate 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 audio or visual alarm, (3) change the infusion rate of the pump 2108 connected to the bag 2118 by either terminating the infusion or changing the pump speed, or (4) generate an audio alarm (and / or a vibration alarm) on the infusion pump 2106. Alarms can be generated simultaneously on several devices or can be generated consecutively on a predetermined 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 has been pre-specified not to be interrupted or continued in the event of a failure in another part of the system. In some embodiments, a pump programmed to operate independently in 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, in some embodiments, be programmed to stop the infusion if the drip detection device 2112 detects an abnormal flow condition (e.g., a free-flow condition or the presence of air bubbles in the infusion line). 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 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 by the monitoring client 2102 to communicate with the dock 2104 and / or directly 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, and 2308 docking 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, and 2308 have standard connectors that allow them to snap into the dock 2310. Each of the modular infusion pumps 2302, 2304, 2306, and 2308 includes a user interface. For example, the modular infusion pump 2302 includes a touchscreen 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 , showing the outline of a cavity 2400 in which the monitoring client 2312 can be stored, as the mounting post 2402 is movable, 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, in accordance with 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 greater leeway in tubing routing.

[0376] FIG. 26 illustrates an electronic patient-care system 2600 having modular infusion pumps 2602, 2604, 2606 that dock within 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 can be stored entirely within the dock 2608 and / or some of the monitoring client 2610 circuitry can be stored within the dock 2608. As can be readily seen in FIG. 27, which shows 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 electrical connections to the dock 2904 and scanner 2912. Modular infusion pumps 2906, 2908, and 2910 are shown docked within device dock 2904. System 2900 also includes a scanner 2912 coupled to hub 2902. Dock 2904 includes quick-release handles 2914 and 2916 on the left and right sides of dock 2904, respectively. Also shown in the upper left corner of each modular infusion pump 2906, 2908, and 2910 are respective buttons 2918, 2920, and 2922 that illuminate when the patient-care device is the focus of interaction on monitoring client 2901 (a type of monitoring client, shown as a tablet) or is selected for control by the user. The tablet can select a particular modular infusion pump, or the user can select it for operation on monitoring client 2901 by pressing buttons 2918, 2920, and 2922, respectively, on modular infusion pumps 2906, 2908, and 2910.

[0378] 30-32 show several views illustrating a clutch system for mounting an electronic patient-care system on a pole, according to embodiments of the present disclosure. FIG. 30 shows a top view of a dock 3100 having a hole 3102 for receiving a pole 3104. Clutches 3110 and 3112 are shown in FIG. 31. In some embodiments, the clutches 3110, 3112 include cleats 3114, 3116. The handles 3106 and 3107 can be used individually or together to release the clutches 3110 and 3112 from the pole 3104 (e.g., by pulling the handles). Additionally or alternatively, the handles 3106 and 3107 can be used to lock the clutches 3110 and 3112 to the pole 3104 (e.g., by pushing the handles 3106, 3107). As can be readily seen in Figure 31, the downward force due to, for example, gravity, further presses the clutches 3110, 3112 against the post 3104. Although two clutches 3110, 3112 are shown in Figure 31, a single clutch can be used to press the post 3104 against the friction surface. Figure 32 shows an alternative post mounting structure 3300 in which two fasteners 3302 and 3304 are used to fasten the post 3104.

[0379] FIG. 33 illustrates an infusion pump 3400 and retractable connectors 3402, 3406 according to an embodiment of the present disclosure. In FIGS. 33-35, a hub 3401 is shown with retractable connectors 3402 and 3406. The hub 3401 has a docking connector, also referred to as a dock. The retractable connectors 3402 and 3406 are shown closed in FIG. 33. However, in alternative embodiments, the retractable connectors 3402 and 3406 can be directly connected to the infusion pump 3400, the infusion pump 3412, and / or additional infusion pumps. The hub 3401 can have a pole attachment mechanism surrounded by the hub 3401 (see FIG. 36). The hub 3401 can be a dock or cradle in some embodiments and can optionally include a handle coupled to its top. The handle can be integrated into the pole attachment mechanism, such that lifting the handle releases the hub 3401 from the pole. Alternatively, in some embodiments, the hub 3401 can support a cradle to attach to a monitoring client, such as a tablet, or the monitoring client can be separately attached to a pole. The retractable connectors 3402 and 3406, in some embodiments, can have a support feature (e.g., a lip) on the bottom of the retractable connectors 3402 and 3406 to support the infusion pump when attached. In this exemplary embodiment, the lip can also be a feature for an electrical connection.

[0380] In FIG. 34, retractable connector 3402 is shown open, revealing connectors 3408 and 3410. While connectors 3408 and 3410 are shown on retractable connector 3402, in other embodiments, connectors 3408 and 3410 are on hub 3401, or infusion pumps 3400 and 3402 are covers for covering connectors 3408 and 3410. Retractable connector 3406 has infusion pump 3412 docked thereto. FIG. 35 shows infusion pump 3416 docked to retractable connector 3402, with infusion pump 3412 docked to retractable connector 3406. Infusion pumps 3400, 3412, and 3416 are electrically connected together in FIG. 35 via hub 3401. FIG. 36 shows a top view of infusion pump 3400 and hub 3401 as mounted on post 3420 of FIGS. 33-35. Retractable connectors 3402 and 3406 are shown in an open configuration.

[0381] FIG. 37 illustrates a rectangular hub 3701 having several connectors 3703, 3705, 3707, and 3709 in accordance with an embodiment of the present disclosure. Each connector 3703, 3705, 3707, and 3709 can be used to connect additional batteries, communication modules, scanners, monitoring clients, monitoring client UIs, patient-care devices, and the like. Each connector 3703, 3705, 3707, and 3709 can use a standard pinout, with a subset used by the module attached thereto. In some embodiments, each connector 3703, 3705, 3707, and 3709 can use a subset of available pins specific to the connected device based on the type of device, for example, as determined from the signal. A post mounting mechanism can be located on the rear of the rectangular hub 3701. The rectangular hub 3701 can also include a front connector 3711 and a rear connector 3713. The mechanical attachment associated with each connector 3703, 3705, 3707, 3709, 3711, 3712 may be a permanent attachment (eg, a screw) or a quick-release attachment point (eg, a latch).

[0382] FIG. 38 illustrates an electronic patient-care system having a hub 3701 coupled to a support post 3715 according to another embodiment of the present disclosure. FIG. 38 illustrates an articulating monitoring client 3712 on the left, an extended battery / communications module 3717 on the top, a barcode scanner module 3719 on the bottom, and a pump dock 3723 on the right side of the hub 3701. The pump dock 3723 is removable for transport, with all infusion pumps 3725, 3727, and 3729 still attached so they can all be shipped as a single unit. A quick-release handle 3731 is located on the top of the pump dock 3727 to allow for easy removal from the hub 3701. Alternatively, in other embodiments, the infusion pumps 3725, 3727, and 3729 can be daisy-chained together. An articulated monitoring c...

Claims

1. 1. A method for renewing a prescription, comprising: determining the safety of a renewed prescription; and communicating the renewed prescription to a medical device. A method comprising:

2. the determination includes medical record data; Querying said data and / or receiving said data The method of claim 1 further comprising:

3. The method of claim 1 , further comprising causing the medical device to display a confirmation request.

4. The method of claim 1 , wherein the method is configured to be performed at a hub.

5. The method of claim 1 , further comprising, after receiving a confirmation, instructing the medical device to operate in accordance with the updated prescription.

6. The method of claim 1 , further comprising updating the prescription and defining an updated prescription.

7. The method of claim 6 , wherein the update includes an interface to an application.

8. The method of claim 6 , further comprising receiving the updated prescription.

9. The method of claim 8 , wherein the receiving includes middleware.

10. The method of claim 9 , wherein the middleware is configured to run on a monitoring server.

11. The method of claim 1 , further comprising causing the medical device to display a parameter.

12. The method of claim 1 , further comprising receiving a parameter from the medical device.

13. The method of claim 12 , further comprising broadcasting the parameters.

14. The method of claim 13 , further comprising causing the monitoring client to display the parameters.

15. The method of claim 14 , wherein the monitoring client is a tablet.

16. The method of claim 12 , further comprising communicating the parameters to an application and / or a monitoring client.

17. The method of claim 12 , further comprising updating an electronic medical record with the parameters.

18. The method of claim 1 , further comprising updating an electronic medical record with the updated prescription.

19. The method of claim 1 , wherein the determining comprises interfacing with a medication error reduction system.

20. 20. The method of claim 19, wherein the medication error reduction system is configured to run at a hub.

21. 21. The method of claim 20, wherein the hub comprises a cached medication error reduction system.

22. 20. The method of claim 19, wherein the medication error reduction system is configured to be implemented on the medical device.

23. 23. The method of claim 22, wherein the medical device comprises a cached medication error reduction system.

24. receiving status information from said medical device and / or tablet; and / or displaying and / or broadcasting said status information. The method of claim 1 further comprising:

25. 13. A system for renewing a prescription comprising a hub including a processor configured in accordance with the method of claim 1.

Images