JP2016219045A - Electronic patient care system, method, and device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an electronic patient care system, method, and device in a hospital.SOLUTION: An electronic patient care system 100 includes a hub. The hub is configured to monitor a patient care device. A sandbox is configured to control access to at least one of a hardware resource and a software resource. The hub is configured to execute an application for identifying a patient care device, and for monitoring the patient care device. The hub is configured to execute the application in the sandbox component such that the application performs access via the sandbox component to at least one of the hardware resource and the software resource. The hub may be configured to control the patient care device.SELECTED DRAWING: Figure 1

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is based on US Provisional Patent Application No. 61 / 297,544 (Attorney Docket No. H53), filed January 22, 2010, named Electronic Instruction Mediation System for Medical Equipment. US Patent Application No. 13 / 011,543 (Attorney Docket No. I52) filed Jan. 21, 2011, claiming priority, filed on Jan. 21, 2011 Both of which are hereby incorporated by reference in their entirety.

  The present disclosure relates to patient care. More particularly, the present disclosure relates to systems, methods, and apparatus for electronic patient care.

  Providing patient care in a hospital is typically necessary to treat many professionals and caregivers (eg, doctors, nurses, pharmacists, technicians, nurse practitioners, etc.) and a given patient Any number of medical device / system interactions are required.

  Directing and delivering medical care, such as medication, despite the presence of systems intended to facilitate the care process, such as those incorporating electronic medical records (EMR) and computerized provider order entries (CPOE) The process of providing comprehensive care to patients, including the patient, is associated with several important issues.

  In an exemplary embodiment related to medication instruction and administration, the electronic patient care system includes a first data collection module (eg, a monitoring client), a user interface for communicating the instructions or receiving patient-related information. A second instruction input module (e.g., a fixed or portable surveillance client). The first module is configured to receive and store measurement parameters relating to the patient's current condition (eg, patient condition parameter), such as blood pressure, heart rate, heart rhythm, temperature, oxygenation, respiratory rate, or ventilation. can do. The first module also includes patient condition parameters such as, for example, drug allergy or hypersensitivity, other currently administered drugs present in the patient's tissue, age, weight, height, kidney, or liver function, Information regarding an existing parameter associated with the patient may be received from a first database (eg, an EHR database including information regarding the patient). The first module is directed from a second database (eg, drug information database) such as known drug interactions, drug effects, or existing drugs related to, for example, blood pressure, pulse, heart rhythm, or respiration. It may also be configured to obtain drug information relating to drugs and / or existing drugs. The first module compares the patient's current measured patient status parameters and the received existing patient status parameters to a known normal range and creates a table of patient status parameters found to be outside the normal range It can be constituted as follows. The first module can then compare the table of patient condition parameters with the corresponding table of parameters obtained from the drug information database. If it is found that there is a match between the table of patient condition parameters and the corresponding table of parameters, the first module then transmits one or more to communicate to the second (instruction input) module Pre-input and stored messages can be read out. These messages may include, for example, alerts to the user of the second module appropriate for the indicated specific medication, the patient's existing medication, and the patient's current and existing medical conditions. Optionally, if the alert is received by the second module and the alert is acknowledged by a user of the second module through an input signal from the user interface, further repetition of the alert can be avoided.

In other embodiments, the electronic patient care system can provide the user with editable default values derived from standard medication and administration guidelines derived from a drug information database, and the patient's current and existing The user can be alerted of changes that can be indicated based on their medical condition, allergies, existing medications, or other patient condition parameters. The electronic patient care system preferably minimizes the amount of input typed by the user.

In other embodiments, the first module or other module of the electronic patient care system is used to direct delivery to the patient bedside (eg, through a bar code and reader, or RFID tag and scanner) Drugs can be identified and verified that appropriate drugs and dosages have been prepared and delivered to the patient. In the embodiment, the first
The module can also interact through a wired or wireless communication link with a patient-care device that provides treatment, such as an infusion pump or pill dispenser. In the case of an infusion pump, the first module or another connection module provides the infusion pump with patient treatment parameters such as infusion settings including infusion rate or infusion pressure from which, for example, the presence of air in the infusion line, Various operating parameters can be received, such as the amount of solution remaining in the connected intravenous bag, or the pressure of the fluid in the infusion line. If the operating parameter is found to be abnormal, the first module responds by sending a signal to the infusion pump to interrupt the infusion and sending a signal to mechanical occlusion to occlude the venous line. Alert the health care provider or the like either directly, by changing the infusion rate, and / or directly by an alarm embedded in the first module or by transmitting an alarm to the second module It can be constituted as follows. In another embodiment, the first module also monitors the patient's condition, eg, a blood pressure monitor, E
It can be configured to communicate with various patient care devices used to determine patient condition parameters such as CG monitors, pulse oximetry monitors, temperature monitors, and the like. Various parameters that are measured 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 other person when the monitored patient condition parameter is outside a predetermined range. In some embodiments, the first module can communicate a signal to the monitoring client to make measurements that are not scheduled by the patient-care device to obtain another patient condition parameter. The first module can communicate with various health care providers at various locations, and in embodiments, can notify the patient to whom the first module has been assigned, for example,
Corrective action can be recommended by audible alert or recorded message.

In one embodiment, a system for preparing a microinfusion pump comprises a monitoring client, a pharmacy computer, a combined robot, a microinfusion pump, and a data download device. The monitoring client is configured to communicate prescription instructions via a user interface. Pharmacy computer
Operately communicate with the monitoring client to receive the prescription instructions. The composite robot is configured to prepare the prescription into at least one liquid corresponding to the prescription instruction. The microinfusion pump is configured to receive at least one liquid corresponding to the prescription instructions. The data download device is configured to download the prescription instructions into the memory of the microinfusion pump.

In some embodiments, the composite robot fills the microinfusion pump with at least one liquid. The compound robot can operably communicate with the data download device, and the compound robot can instruct the data download device to download the prescription instructions into the memory of the microinfusion pump. it can. The data download device can receive prescription instructions from the complex robot and / or pharmacy computer. In some embodiments, the composite robot receives prescription instructions from the pharmacy computer.

In one embodiment of the present disclosure, the system includes a hub. The hub is configured to monitor the patient-care device. The hub includes an operating system (which can be embodied as processor execution software) and a sandbox component (which can be embodied as processor execution software). The operating system component is configured to access at least one of a hub hardware resource and a hub software resource.

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

The hub may be further configured to control the patient-care device. Patient care devices include infusion pumps, pill dispensers, microinfusion pumps, ECG monitors, blood pressure monitors, pulse oximeters, CO ₂ capnometers, intravenous bags, and / or
Or it may be one or more of the drip flowmeters.

The hub receives identification information (eg, serial number, (encrypted or unencrypted) code, or other identification value) from the patient-care device and downloads the application from the server associated with the identification information It may be configured to. The hub may also be configured to receive identification information from the patient-care device and update an application from a server associated with the identification information.

Hardware resources include disk drives, memory, and buzzers
, Microphones, speakers, and cameras. Software resources include variables, secure data objects, secure variables, protected APIs, APIs,
And one of the hardware component software representations.

In yet another embodiment, an electronic patient care system includes a hub. Hub is
A patient care device is configured to be monitored. Sandbox is hardware
It can be configured to control access to at least one of the resource and the software resource. The hub is further configured to execute an application to identify the patient-care device and monitor the patient-care device. Hub is
An application is executed within a sandbox component, whereby the application accesses at least one of hardware 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 the 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 the identification information from the patient-care device and update the application from the server associated with the identification information.

Hardware resources include disk drive, memory, buzzer, microphone,
It may be a speaker and a camera. A 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.

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

The patient-care device may be an infusion pump, pill dispenser, microinfusion pump, ECG monitor, blood pressure monitor, pulse oximeter, and / or CO ₂ capnometer, intravenous bag, and infusion flow meter.

The monitoring client may be further configured to receive the 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 the identification information from the patient-care device and update an application from the server associated with the identification information.

Hardware resources include disk drive, memory, buzzer, microphone,
It may be a speaker and a camera. A 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.

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

The patient-care device may be an infusion pump, pill dispenser, microinfusion pump, ECG monitor, blood pressure monitor, pulse oximeter, and / or CO ₂ capnometer, intravenous bag, and infusion flow meter.

The monitoring client may be further configured to receive the 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 the identification information from the patient-care device and update an application from the server associated with the identification information.

Hardware resources include disk drive, memory, buzzer, microphone,
It may be a speaker and a camera. A 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.

In another embodiment, an electronic patient care system includes a hub configured to communicate with an electronic medical record and a patient care device. Hubs are used for patient and patient care devices (
For example, an infusion pump) is configured to be identified. The hub is also configured to download at least one treatment parameter (eg, infusion drug and / or infusion rate or rate profile) from the electronic medical record and program the patient-care device with the at least one treatment parameter. Yes. The hub uses an RFID interrogator to RF
Reading ID tags, voice using voice recognition software coupled using a microphone, face using face recognition software coupled to a camera, biometric parameters for biometric reading, identification information, barcode The patient is identified according to at least one of the barcode readings by the reader. In one particular embodiment, the hub can download at least one treatment parameter using one or more of the identification techniques described herein.

In another embodiment, an electronic patient care system includes a monitoring client configured to communicate with an electronic medical record and a patient care device. The monitoring client is configured to identify patients and patient care devices (eg, infusion pumps). The monitoring client is also configured to download at least one treatment parameter (eg, an infusion drug and / or an infusion rate or rate profile) from the electronic medical record and program the patient-care device with the at least one treatment parameter. ing.
Surveillance clients can read RFID tags using an RFID interrogator, voice using speech recognition software coupled using a microphone, face using face recognition software coupled to a camera, biometric reading The patient is identified according to at least one of: biometric parameters, identification information, barcode reading by a barcode reader. In one particular embodiment, the monitoring client can download at least one treatment parameter using one or more of the identification techniques described herein.

In yet another embodiment, an electronic patient care system 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 to cause the monitoring client to dock there. The patient care device is configured to communicate at least one patient care parameter. The device dock is configured to receive the patient-care device for docking the patient-care device there.

In an embodiment, the monitoring client dock and device dock are configured to communicate either wirelessly and through a cable operatively coupled to the monitoring client dock and device dock.

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

In another embodiment, the monitoring client dock is configured to communicate wirelessly with the monitoring client, the monitoring client transmitting at least one patient care parameter wirelessly with the monitoring client dock to the dock through the cable. It is also in operative communication with the patient-care device by communicating to the docked patient-care device.

In another embodiment, the monitoring client is not available for communication through the cable.
And at least one patient care parameter is operable using wireless communication with the monitoring client dock when the monitoring client determines that the monitoring client is at least one of being undocked from the monitoring client dock connect.

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

  In another embodiment, the monitoring client is not available for communication over the cable, communication between the monitoring client and the monitoring client dock is not available, and the monitoring client undocked from the monitoring client dock. If the monitoring client determines that the at least one has been performed, wireless communication with the device dock is utilized to operatively communicate at least one patient care parameter.

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

In another embodiment, the monitoring client is not available for communication through the cable.
At least one 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 And at least one patient care parameter is operatively communicated wirelessly with the patient care device.

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 surveillance client dock and the device dock, the surveillance client dock and the dock being a device dock, a surveillance client dock,
And at least one of the monitoring clients is configured to communicate wirelessly if it determines that the cable is not available as a communication link.

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

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 CO ₂ capnometer, an intravenous bag, and an infusion flow meter. is there.

In another embodiment, the patient care parameters, intravenous pump flow parameters, ECG parameters, blood pressure parameter, a pulse oximeter parameters, CO ₂ capnometers parameters, intravenous bag parameters, and the infusion flow meter value of at least 1 One. The patient care parameter may be a patient condition parameter and / or a patient treatment parameter.

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

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

In yet another embodiment, an electronic patient care system 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 to dock the patient-care device there and to receive the monitoring client to dock the monitoring client there.

In yet another embodiment, an electronic patient care system includes a patient care device configured to communicate at least one patient care parameter and 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 the patient-care device therewith. The device dock and monitoring client are integrated together.

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

In yet another embodiment, an electronic patient care system includes a patient care device configured to communicate at least one patient care parameter and a hub configured to communicate at least one patient care parameter. A client and a device dock configured to receive the patient-care device for docking the patient-care device therein. The hub can plug into the device dock to establish a communication link therebetween. The system can further comprise a monitoring client in operative communication with the hub to receive at least one patient care parameter. Patient treatment parameters can be in operative communication with the hub, which communicates the patient treatment parameters to the patient-care device.

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

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

In certain embodiments, the patient-care device may include a user interface, and the patient-care device may require user authentication of patient treatment parameters prior to treating the patient.

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 a hardware resource and a software resource.

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

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

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

At least one patient monitor includes an electrocardiogram monitor, blood pressure monitor, pulse oximeter,
A monitor and at least one of a CO ₂ capnometer can be provided. The monitoring client can be configured to download patient information according to a specified unique patient identifier. The unique patient identifier can be encoded in a barcode placed on the wristband. The unique patient identifier can be encoded on an RFID tag (eg, RFID interrogator) coupled to the wristband. Patient information includes patient status or patient care parameters. The unique patient identifier can be operatively transmitted to the monitoring server to obtain electronic permission to communicate patient specific data. A subset of patient-specific data can be stored in the memory of the monitoring client. The monitoring client is adapted to determine whether the new indication meets a predetermined criteria based on a subset of patient-specific data stored in memory.

In another embodiment, the system further comprises a portable monitoring client adapted to present new instructions to the monitoring client. At least one of the monitoring client and / or the remote communicator is adapted to communicate a new indication to the monitoring server, which determines whether the new indication meets another predetermined criterion. ing.

In another embodiment, the new instruction may be a medication instruction, and the monitoring server determines whether the new instruction is another predetermined criterion by determining whether the medication instruction is not contraindicated for the currently prescribed medication. It is designed to determine whether or not The monitoring server can communicate with the database to determine whether the new indication meets another predetermined criteria. The monitoring server can be configured to send an alert to the monitoring client if the new indication does not meet another predetermined criteria.

In another embodiment, the system can comprise remote communication adapted to operably communicate with at least one of the monitoring client and the monitoring server.

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 has a touch screen.

In another embodiment, the system can further comprise 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 removable from the monitoring client.

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

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

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

In another embodiment, the monitoring server is adapted to format data from multiple databases in order to download the data to the monitoring client. Optionally, and in some specific embodiments, the monitoring client can communicate at least one patient parameter to the monitoring server. In certain embodiments, the patient parameter is one or more of infusion pump therapy progress, an electrocardiogram signal, a blood pressure signal, a pulse oximeter signal, a CO ₂ capnometer signal, and / or a temperature signal, and / or Or at least one can be provided.

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

The monitoring client can receive a user request to read patient parameters and can query the monitoring device to receive patient parameters.

In another embodiment, the system can further comprise a portable monitoring client. The portable monitoring client can be in operative communication with the monitoring client so as to communicate directly with the patient information, thereby bypassing the monitoring server. The portable monitoring client can be configured to change at least one parameter of the infusion pump and communicate the at least one changed parameter to the monitoring server.

Changes to patient instructions presented via a portable monitoring client can be communicated to another portable monitoring client.

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

The system can further comprise another monitoring client adapted to receive information from a patient specific database.

The information can include at least one of patient instructions, patient medication, progress notes, monitoring data from a patient monitor, and treatment data from an attached device.

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 in accordance with the patient information.

The predetermined set of information includes patient age, height, weight, diagnosis, current medication, medication category,
It may include at least one of drug allergy and hypersensitivity.

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

In another embodiment, an electronic patient care method displays a plurality of patients on a display and displays at least one patient parameter associated with one 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.

The method may further include, in some specific embodiments, sending an alert from a monitoring client to a portable remote communicator device having a display.

In yet another embodiment, an electronic patient care system includes a monitoring client configured to communicate at least one patient care parameter, and a patient care device configured to communicate at least one patient care parameter; Facilitates communication between the monitoring client and at least one patient-care device by discovering the presence of at least one patient-care device and converting communication signals from that device into a communication protocol associated with the monitoring client And a communication interface configured as described above.

In certain embodiments, the communication interface is further configured to discover the presence of additional other patient-care devices that differ from each other and convert communication signals from these devices into a communication protocol associated with the monitoring client. Yes.

In another specific embodiment, the communication interface is further configured to provide suitable power for each device. In yet another specific embodiment, the system further includes a monitoring client that enables at least one of patient information and / or central storage of download information that can be used to treat a patient associated with the monitoring client. It has one or more accessible databases.

In yet another specific embodiment, the communication interface further performs a failure check on at least one of the access data integrity of communication with the patient-care device, evaluates whether the monitoring client is functioning properly, and the patient The care device is configured to assess whether it is functioning properly and / or to assess whether the communication interface is functioning properly.

In yet another embodiment, an electronic patient-care system includes a hub client configured to communicate at least one patient-care parameter, and a patient-care device configured to communicate at least one patient-care parameter. Facilitating communication between the hub and at least one patient-care device by discovering the presence of at least one patient-care device and converting communication signals from that device into a communication protocol associated with the hub And a communication interface configured as described above.

In certain embodiments, the communication interface is further configured to discover the presence of additional other patient-care devices that differ from each other and convert communication signals from that device into a communication protocol associated with the hub.

In another specific embodiment, the communication interface is further configured to provide suitable power for each device. In yet another specific embodiment, the system is further accessible by a hub that allows at least one of patient information and / or central storage of download information that can be used to treat a patient associated with the hub. One or more databases.

In yet another specific embodiment, the communication interface further performs a failure check on at least one of the access data integrity of communication with the patient-care device, evaluates whether the monitoring client is functioning properly, and the patient The care device is configured to assess whether it is functioning properly and / or to assess whether the communication interface is functioning properly.

In yet another embodiment, an electronic patient care system includes a dock configured to communicate at least one patient care parameter, and a patient care device configured to communicate at least one patient care parameter; To facilitate communication between the dock and at least one patient-care device by discovering the presence of at least one patient-care device and converting a communication signal from that device into a communication protocol associated with the dock And a configured communication interface.

In certain embodiments, the communication interface is further configured to discover the presence of additional other patient-care devices that are different from each other and convert communication signals from that device into a communication protocol associated with the dock.

In another specific embodiment, the communication interface is further configured to provide suitable power for each device. In yet another specific embodiment, the system is further accessible by a dock that allows at least one of central storage of patient information and / or download information that can be used to treat a patient associated with the dock. One
Has one or more databases.

In yet another specific embodiment, the communication interface further performs a failure check on at least one of the access data integrity of communication with the patient-care device, evaluates whether the monitoring client is functioning properly, and the patient The care device is configured to assess whether it is functioning properly and / or to assess whether the communication interface is functioning properly.

In an embodiment, a patient-care device is configured to couple to the main body, a track in the main body configured to receive the strut, and to functionally lock the main body to the strut in the track. And two functional members.

In an embodiment, the hub includes a patient-care device interface and a patient-care device
A power source coupled to the interface and configured to power the patient-care device; a processor; and a patient-care device interface configured to allow communication between the processor and the patient-care device. With a transceiver. The processor may be configured to disable the patient-care device in some specific embodiments when in an alarm condition.

In an embodiment, 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 between the processor and the patient-care device. A transceiver coupled to the patient-care device interface configured to enable communication. The processor may be configured to disable the patient-care device in some specific embodiments when in an alarm condition.

In an embodiment, the communication module includes a patient-care device interface, a power source coupled to the patient-care device interface and configured to supply power to the patient-care device, a processor, a patient-care device, and another device. And a transceiver coupled to the patient-care device interface configured to enable communication with the device. The processor may be configured to disable the patient-care device in some specific embodiments when in an alarm condition.

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

In yet another embodiment, the electronic patient care system is a first module configured to receive and store information about a patient, wherein the information of the patient is measured by a device connected to the patient. A first module comprising data relating to a first parameter and data relating to a second parameter of the patient received from a first database comprising information about the patient; and a user interface associated with the second module And a second module configured to receive a medication instruction from a user via the first module, and further configured to transmit the treatment instruction to the first module, the first module further comprising: A) Drug information about the drug or other drug from a second database, where such drug is Acquires drug information including data to provide a restriction to be administered to, b) a drug instruction (this particular embodiment), the agent information, the value of the first parameter,
And whether to confirm by the second module based on the value of the second parameter and c) confirming the acceptability of the medication indication for display on the user interface, or related thereto A pre-established message for warning is configured to be communicated from the first module to the second module.

The drug information can include drug interaction information, drug allergy information, blood pressure action information, heart rate action information, heart rhythm action information, or respiratory action information. The first parameter or the second parameter is a patient Data on currently administered drugs, known drug allergies, current blood pressure, current heart rate, current heart rhythm, current respiratory rate or current ventilation.

The pre-established message can include a warning regarding the potential action of the indicated medication, said warning being received by the measurement data for the first parameter, the received data for the second parameter, or the first module. Contains obtained drug information.

  When the first module receives a confirmation signal triggered by an input signal from the user interface from the second module after a pre-established message has been communicated, the drug instruction or modified drug instruction is processed. Can be configured to generate a signal to be transmitted.

In another embodiment, the patient-care device comprises a first communication link and a second communication link, and the dock comprises a first communication link and a second communication link. If the patient-care device is within a predetermined range at the dock, the patient-care device and dock are first
Paired using the second 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 may be near field communication and the second communication link may be Bluetooth, Bluetooth Low Energy, WiFi, or other communication link.

In another embodiment, the patient-care device comprises a first communication link and a second communication link, and the monitoring client comprises a first communication link and a second communication link. If the patient-care device is within a predetermined range at the monitoring client, the patient-care device and the monitoring client are paired using the first communication link and, after pairing, using the second communication link Stay in communication. The pairing that occurs using the first communication link can pair the patient-care device and the monitoring client to the second communication link. The first communication link may be near field communication and the second communication link may be Bluetooth, Bluetooth Low Energy, WiFi.
Or other communication link.

In some embodiments, the patient-care device comprises a memory in which user interface templates are stored. The user interface template can communicate with the dock, hub, and / or monitoring client for display on the 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 the patient care device (eg, in real time).

In yet another embodiment, the infusion pump comprises an attachable electronic component. The attachable electronic component includes at least one processor, a power conditioner, and a control system.

In an embodiment, the communication module includes at least one processor and one of a transceiver, a battery, and a power source for providing the patient-care device with at least one of communication capability and power.
One or more.

In yet another embodiment, the wearable system monitor comprises a watchdog component and a transceiver. The wearable system monitor can comprise a processor coupled to the watchdog component and the transceiver to perform a watchdog function on at least one paired device. The paired device may be at least one of a dock, hub, monitoring client, and / or patient-care device.

In yet another embodiment, the method includes establishing a communication link between the patient-care device and the monitoring server, communicating the patient-care parameter to the monitoring server, de-identifying the patient-care parameter, and / or Including one or more of storing unidentified patient care parameters in the monitoring server.

In yet another embodiment, the method establishes a communication link between the monitoring server and a plurality of patient-care devices associated with the plurality of patients, the plurality of patient-care parameters from the plurality of patient-care devices to the monitoring server. Communicating, de-identifying patient-care parameters, storing patient-care parameters in a monitoring server, treating multiple patients, and associating with multiple patients to determine the effectiveness of treatment One or more of analyzing a subset of the plurality of determined patient care parameters.

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

In yet another embodiment, a method having a hot-swappable patient-care device, such as an infusion pump, receives one or more patient-care parameters associated with the patient-care device, a non-volatile memory of the patient-care device One of storing one or more patient-care parameters in the memory, loading one or more patient-care parameters in the operating memory, and resuming operation of the patient-care device.
Contains one or more. The method can include, in additional embodiments, determining that operation of the patient-care device can resume.

In yet another embodiment, a method having a hot-swappable patient-care device, eg, an infusion pump, calculates one or more operating parameters associated with the patient-care device, in a non-volatile memory of the patient-care device One or more of: storing one or more operating parameters, loading one or more operating parameters into the operating memory, and resuming operation of the patient-care device. The method can include, in additional embodiments, determining that operation of the patient-care device can resume.

In yet another embodiment, the pairing method includes positioning a monitoring client and / or a hub having a user interface within an operating distance of a patient-care device (eg, an infusion pump), patient-care device identification information Displaying on a user interface, selecting a patient-care device for pairing using the user interface, pairing a patient-care device to a monitoring client and / or hub, and / or patient Communicating care parameters to the monitoring client and / or hub. In yet another embodiment, and optionally, the method includes the step of operatively communicating additional patient-care parameters with another patient-care device through the patient-care device, for example to a monitoring client and / or hub. Can do.

In yet another embodiment, the method includes docking the patient-care device in the dock, identifying the patient-care device, querying the server for an application for controlling the patient-care device, docking the application, hub And / or downloading into the monitoring client, executing the application using the dock, hub, and / or monitoring client, and controlling the patient-care device using the application.

In yet another embodiment, the method includes arranging the patient-care device in operative communication with the hub. The hub can identify the patient-care device, can query the server for an application to control the patient-care device, can download the application into the hub, can execute the application, The application can be used to control a patient-care device.

In yet another embodiment, the method includes placing the patient-care device in operative communication with the dock. The dock can identify the patient-care device, can query the server for an application to control the patient-care device, can download the application into the dock, can run the application, The application can be used to control a patient-care device.

In yet another embodiment, the method includes arranging a patient-care device in operative communication with a monitoring client. The monitoring client can identify the patient-care device, can query the server for applications to control the patient-care device, can download the application to the monitoring client, and can execute the application The application can be used to control the patient care device.

In yet another embodiment, a method presents a request on a user interface of a communication device, confirms the request, sends the request, receives the request with a check value, and the check value is sent. A step of confirming that the previous request is being followed can be included.

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

In yet another embodiment, the hub is at least one of electronic medical records, DERS, CPOE, and / or the Internet for controlling and / or monitoring a patient-care device.
Operably communicate with one.

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

In yet another embodiment, the battery pack includes a patient-care device interface, a battery, and a regulated power source configured to power the patient-care device using the battery. The battery may be recharged using a DC power source in some embodiments.

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

In yet another embodiment, an electronic patient care system includes a monitoring client and a dock configured to couple to a strut. The adapter can be coupled to the dock. The adapter can comprise at least one electronic coupler to position the patient-care device in operative communication with the monitoring client. The patient-care device can slide into the adapter.

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

These and other aspects will become more apparent from the following detailed description of various embodiments of the present disclosure with reference to the drawings.

1 is a block diagram of an electronic patient care system having two docks according to an embodiment of the present disclosure. FIG. FIG. 2 is a flowchart diagram illustrating a method for maintaining communication between the monitoring client of FIG. 1 and a patient-care device, according to an embodiment of the present disclosure. FIG. 3 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. FIG. 4 is a flowchart diagram illustrating a method for maintaining communication between the monitoring client of FIG. 3 and a patient-care device in accordance with an embodiment of the present disclosure. FIG. 4 is a block diagram of an electronic patient care system having a dock for docking together a monitoring client and a patient care device according to yet another embodiment of the present disclosure. FIG. 6 is a flowchart diagram illustrating a method for maintaining communication between the monitoring client of FIG. 5 and a patient-care device according to an embodiment of the present disclosure. FIG. 6 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. FIG. 3 is a block diagram of an electronic patient care system having a hub according to yet another embodiment of the present disclosure. FIG. 4 is a block diagram of an electronic patient care system having a stackable monitoring client and a stackable patient care device according to yet another embodiment of the present disclosure. FIG. 5 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. FIG. 5 is a flowchart diagram of a method for collecting patient care parameters for multiple patients in a monitoring server, according to an embodiment of the present disclosure. FIG. 6 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. FIG. 6 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. FIG. 6 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. FIG. 6 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. FIG. 5 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. FIG. 6 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. FIG. 6 is a block diagram of an electronic patient care system according to yet another embodiment of the present disclosure. 1 is a block diagram of an electronic patient care system according to another embodiment of the present disclosure. FIG. FIG. 20 is a block diagram of a dock of the electronic patient care system of FIG. 19 according to an embodiment of the present disclosure. 1 illustrates an electronic patient care system having a tablet docked in a dock having a cable electrically coupled to a patient care device, in accordance with an embodiment of the present disclosure. 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. FIG. 1 illustrates an electronic patient care system having a modular infusion pump that docks into a dock having a monitoring client with a retractable user interface according to an embodiment of the present disclosure. FIG. FIG. 24 is a side view of the electronic patient care system of FIG. 23 according to an embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having staggered modular infusion pumps docked in a dock having a monitoring client with a retractable user interface according to another embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having a modular infusion pump that docks into a dock along a common horizontal plane, including a monitoring client with a retractable user interface, according to yet another embodiment of the present disclosure. FIG. 27 is a side view of the electronic patient care system of FIG. 26 according to another embodiment of the present disclosure. In accordance with yet another embodiment of the present disclosure, a modular infusion pump that docks into a dock along a common horizontal plane, including a surveillance client with a retractable user interface, and a hub coupled to the scanner and dock It is a figure which shows the electronic patient care system which has. FIG. 29 is a side view of the electronic patient care system of FIG. 28 according to another embodiment of the present disclosure. FIG. 3 is a number of diagrams illustrating a clutch system for mounting an electronic patient care system on a post according to an embodiment of the present disclosure. FIG. 3 illustrates an infusion pump and a dock coupled to a strut, according to an embodiment of the present disclosure. FIG. 4 shows another infusion pump coupled to an open connector and an infusion pump with an open connector, according to an embodiment of the present disclosure. FIG. 34 illustrates the infusion pump of FIG. 33 with two additional infusion pumps each coupled to an open connector in accordance with an embodiment of the present disclosure. FIG. 36 is a top view of one of the infusion pumps of FIGS. 33-35 and a hub, according to an embodiment of the present disclosure. FIG. 3 illustrates a square hub having several connectors according to an embodiment of the present disclosure. FIG. 4 illustrates an electronic patient care system having a hub coupled to a post according to another embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having a post coupled to a portable dock and a hub with a quick release handle for removing the portable dock from the hub according to another embodiment of the present disclosure. FIG. 3 illustrates an electronic patient care system having a hub coupled to a post and a dock coupled to the hub, according to another embodiment of the present disclosure. FIG. 4 illustrates an electronic patient care system having a hub coupled to a post according to another embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having a monitoring client coupled to a hub having a notch for receiving a patient care device according to another embodiment of the present disclosure. FIG. 43 is an enlarged view of a T-connector that connects with a notch in the hub as shown in FIG. 42 according to another embodiment of the present disclosure. FIG. 4 illustrates an electronic patient care system having a stackable patient-care device and a stackable container for storing an infusion bag, according to another embodiment of the present disclosure. FIG. 6 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. FIG. 4 illustrates an electronic patient care system having a stackable patient care device with a syringe pump patient care device having a single syringe, according to another embodiment of the present disclosure. FIG. 3 illustrates an electronic patient care system having a stackable patient care device with a syringe pump patient care device having two syringes according to another embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having stackable patient care devices each having a display according to another embodiment of the present disclosure. 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. FIG. 49 is an enlarged view of an infusion line port showing an infusion line positioned therethrough of the electronic patient care system of FIG. 48 according to another embodiment of the present disclosure. FIG. 4 illustrates another embodiment of an electronic patient care system illustrating the removal of a stackable patient care device according to another embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system prepared for transport according to another embodiment of the present disclosure. FIG. 4 illustrates an electronic patient care system having a stackable patient care device according to another embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having a stackable patient care device that is stackable from the bottom up, according to another embodiment of the present disclosure. FIG. 3 illustrates an electronic patient care system having a stackable patient care device coupled to a post and stackable from top to bottom according to another embodiment of the present disclosure. FIG. 7 is a perspective view of a clutch system having a release handle for functionally gripping a post according to another embodiment of the present disclosure. FIG. 57 is a rear view of the clutch system of FIG. 56 showing a transparent rear surface according to another embodiment of the present disclosure. FIG. 57 is a top cross-sectional view of the clutch system of FIG. 56 according to another embodiment of the present disclosure. 1 is a block diagram of a system for controlling an infusion pump according to an embodiment of the present disclosure. FIG. 1 is a block diagram of an electronic patient care system having a hub for communicating with several electronic patient care devices according to embodiments of the present disclosure. 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. FIG. FIG. 6 is a process diagram illustrating several stages of electronic patient care according to an embodiment of the present disclosure. FIG. 6 illustrates several arrangements of an electronic patient care system according to an embodiment of the present disclosure. FIG. 6 is a timing diagram of an electronic patient care treatment using an infusion pump according to an embodiment of the present disclosure. FIG. 68 is a flowchart diagram of a method illustrating the timing diagram of FIG. 67 according to an embodiment of the present disclosure. FIG. 6 illustrates additional placement of an electronic patient care system according to an embodiment of the present disclosure. FIG. 6 is a timing diagram of an electronic patient care treatment using an infusion pump according to an embodiment of the present disclosure. FIG. 72 is a flowchart diagram of a method illustrating the timing diagram of FIG. 71 according to an embodiment of the present disclosure. FIG. 6 is another timing diagram of an electronic patient care treatment using an infusion pump according to an embodiment of the present disclosure. FIG. 74 is a flowchart diagram of a method illustrating the timing diagram of FIG. 73 according to an embodiment of the present disclosure. FIG. 6 is yet another timing diagram of an electronic patient care treatment using an infusion pump according to another embodiment of the present disclosure. FIG. 76 is a flowchart diagram of a method illustrating the timing diagram of FIG. 75 according to an embodiment of the present disclosure. FIG. 6 illustrates several arrangements of an electronic patient care system according to an embodiment of the present disclosure. FIG. 4 is another timing diagram of an electronic patient care treatment using an infusion pump according to another embodiment of the present disclosure. FIG. 80 is a flowchart diagram of a method illustrating the timing diagram of FIG. 79 according to an embodiment of the present disclosure. FIG. 4 is another timing diagram of an electronic patient care treatment using an infusion pump according to another embodiment of the present disclosure. 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. 3 illustrates some additional embodiments of an electronic patient care system according to some embodiments of the present disclosure. 2 is a block diagram of an electronic circuit of an embodiment of a hub according to an embodiment of the present disclosure. FIG. FIG. 3 is a block diagram of an electronic circuit for interfacing with an infusion pump according to an embodiment of the present disclosure. FIG. 4 illustrates another embodiment of an electronic patient care system having a vertically arranged patient care device docked within a dock, in accordance with an embodiment of the present disclosure. 2 is a block diagram of an electronic circuit of an embodiment of a hub according to an embodiment of the present disclosure. FIG. 2 is a block diagram of an electronic circuit of a communication module according to an embodiment of the present disclosure. FIG. FIG. 3 illustrates some embodiments of an electronic patient care system having an infusion pump coupled to a communication module, according to some embodiments of the present disclosure. FIG. 3 is a block diagram of several of the dock's electronic circuitry, according to some embodiments of the present disclosure. 1 is a block diagram of a battery pack according to an embodiment of the present disclosure. FIG. FIG. 4 illustrates an additional embodiment of a dock electronic circuit according to an additional embodiment of the present disclosure. FIG. 4 illustrates some embodiments of an attachable pump attached to a monitoring client, according to additional embodiments of the present disclosure. FIG. 3 shows a backplane for use with an infusion pump according to an embodiment of the present disclosure. FIG. 118 is a cross-sectional view of the backplane panel of FIG. 117 according to an embodiment of the present disclosure. FIG. 4 illustrates some embodiments of an attachable pump attached to a monitoring client, according to additional embodiments of the present disclosure. FIG. 3 illustrates a communication module according to an embodiment of the present disclosure. FIG. 4 illustrates a communication module attached to a patient monitoring device, according to an embodiment of the present disclosure. FIG. 122 is a diagram of an electronic circuit of the communication module of FIG. 121 according to an embodiment of the present disclosure. FIG. 4 is a diagram of an electronic circuit that converts near field communication to UHF, in accordance with an embodiment of the present disclosure. FIG. 6 illustrates several antennas according to additional embodiments of the present disclosure. FIG. 4 shows a patient wrist band with an RFID tag attached thereto, according to an embodiment of the present disclosure. 129 is a diagram illustrating a split ring resonant circuit for use on the wrist band of FIG. 128, according to an embodiment of the present disclosure. FIG. FIG. 6 illustrates a near-field antenna according to an embodiment of the present disclosure. FIG. 131 is a diagram illustrating an equivalent circuit of the split ring resonant circuit of FIG. 130 according to an embodiment of the present disclosure. FIG. 6 illustrates a 5R checklist that can be displayed on a monitoring client, in accordance with an embodiment of the present disclosure. FIG. 4 is a diagram illustrating a blockage checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. FIG. 6 illustrates a display of a monitoring client in operative communication with several infusion pumps according to an embodiment of the present disclosure. FIG. 6 is a display on a healthcare provider's portable monitoring client showing a list of patients that the provider can access to that information, according to an embodiment of the present disclosure. Healthcare provider's portable monitoring client showing a device associated with a particular patient with one-touch access to current data from the device and some of the patient's medical information, according to embodiments of the present disclosure It is a figure which shows the upper display. FIG. 6 shows a display on a healthcare provider's portable monitoring client showing a data entry area for a pharmaceutical prescription for use with an intravenous infusion pump according to an embodiment of the present disclosure. FIG. 7 shows a display on a healthcare provider's portable monitoring client showing the risk profile associated with the indicated medication and the proposed operational process as generated by the monitoring client, according to an embodiment of the present disclosure. FIG. FIG. 4 illustrates a display on a healthcare provider's portable monitoring client showing a drug prescription ready to be presented by an instruction provider, according to an embodiment of the present disclosure. FIG. 6 illustrates a display on a healthcare provider's portable monitoring client showing how the monitoring system can display to an instruction provider a confirmation that a prescription has been communicated to a pharmacist, according to an embodiment of the present disclosure. is there. FIG. 3 is a perspective view of a microinfusion pump coupled to an adapter according to an embodiment of the present disclosure. 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 dock, in accordance with an embodiment of the present disclosure. 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 dock according to an embodiment of the present disclosure. FIG. 143 is a side perspective view of the electronic patient care system of FIG. 143, according to an embodiment of the present disclosure. FIG. FIG. 143 is an enlarged perspective view of one interface of the patient-care device shown in FIG. 143, in accordance with an embodiment of the present disclosure. 143 is a top view of the electronic patient care system of FIG. 143, according to an embodiment of the present disclosure. FIG. 1 is a diagram illustrating a system for an electronic patient care system according to an embodiment of the present disclosure. FIG. 1 is a block diagram of an electronic patient care system according to an embodiment of the present disclosure. FIG. 147 is a block diagram of the bedside portion of the electronic patient care system of FIGS. 147 and / or 148 in accordance with an embodiment of the present disclosure. FIG. 146 is a block diagram of the dock / hub of FIGS. 147, 148, and / or 149, in accordance with an embodiment of the present disclosure. 146 is a block diagram illustrating the infusion pump circuit of FIGS. 148 and / or 149 according to an embodiment of the present disclosure. FIG. FIG. 6 is a block diagram illustrating a sensor coupled to an infusion pump mechanism, in accordance with an embodiment of the present disclosure.

Techniques for facilitating patient care are disclosed. The technique can be implemented, for example, in a system having one or more patient-care devices communicatively coupled to a monitoring client, according to an exemplary embodiment. Patient care devices can include any number of diverse functions and / or can be manufactured by different manufacturers. In one such case, the communication interface between the client monitoring station and the various diversity patient-care devices can be as diverse as discovery and protocol conversion and power provisioning, compliance with various standards, and user interfaces, for example. Enable other functions. Patient care devices include infusion pumps, microinfusion pumps, insulin pumps, syringe pumps, pill dispensers, dialyzers, ventilators, ultrasonic diagnostic equipment, ECG monitors, blood pressure monitors, pulse oximeters, CO ₂ A capnometer, infusion counter, infusion flow meter, optical Doppler device, heart rate monitor, intravenous bag, hemodialyzer, peritoneal dialyzer, intestinal dialyzer, patient thermometer, and / or other bedside patient-care device Also good. US patent application Ser. No. 11 / 704,899, filed Feb. 9, 2007, entitled Fluid Delivery System and Method, and subsequently published on Oct. 4, 2007, US Patent Application Publication No. 2007-0228071-A1. No. (Agent reference number E70), 2007
US patent application Ser. No. 11 / 704,896, filed Feb. 9, 2007, entitled “Method of Using Pump Fluid Delivery System and Force Applying Assembly,” and subsequently published on September 20, 2007 Publication No. 2007-0219496 (Agent reference number E71
No.), filed Feb. 9, 2007, U.S. Patent Application No. 11 / 704,886, named Patch Size Fluid Delivery System and Method, and subsequently published U.S. Patent Application published on September 20, 2007 No. 2007-0219481 (Attorney Docket No. E72), 20
US patent application Ser. No. 11 / 704,897, filed Feb. 7, 2007, entitled Adhesives and Peripheral Systems and Methods for Medical Devices, and subsequently published on September 20, 2007 Publication No. 2007-0219597 (Attorney Docket No. E73),
U.S. Patent Application No. 12 filed December 31, 2008, named infusion pump assembly.
US Patent Application Publication No. 2009-0299277 (Attorney Docket No. G75) published on Dec. 3, 2009, filed Dec. 31, 2008, wearable pump US patent application Ser. No. 12 / 347,9 entitled Assembly
No. 82 and subsequently published on November 12, 2009.
--0281497 (Attorney Docket No. G76), filed December 31, 2008, US Patent Application No. 12 / 347,981 entitled Infusion Pump Assembly, then published on November 5, 2009 Published US 2009-0275896 (Attorney Docket No. G77), filed December 31, 2008, in US patent application Ser. No. 12 / 347,984, entitled Pump Assembly with Switch. United States Patent Application Publication No. 2009-0299289 (Attorney Docket No. G79) published on Dec. 3, 2009, filed Oct. 10, 2008, United States Patent Application entitled Infusion Pump Assembly No. 12 / 249,882, followed by US Patent Application Publication No. 2010 published on April 15, 2010. No. 0094222 (Attorney Docket No. F51), 200
US patent application Ser. No. 12 / 249,636, filed Oct. 10, 2008, entitled System and Method for Administering Infusible Fluid, and subsequently published on Apr. 15, 2010 No. 2010-0094261 (Attorney Docket No. F52), 20
US patent application Ser. No. 12 filed Oct. 10, 2008, entitled Occlusion Detection System and Method
US Patent Application Publication No. 2010-0090843 (Attorney Docket No. F53) published on April 15, 2010, and filed on October 10, 2008, Multi-Language / Multi US patent application Ser. No. 12 / 249,600, named processor infusion pump assembly, then US Patent Application Publication No. 2010-0094221 published on Apr. 15, 2010 (Attorney Docket No. F54). ), 2011 11
Issued 29th May, U.S. Pat. No. 8,066,672 (Attorney Docket No. F55) entitled Infusion Pump Assembly with Backup Power Supply, issued September 13, 2011, removable cover U.S. Pat. No. 8,016,789 (Attorney Docket No. F56), named pump assembly with assembly, issued December 11, 2007, U.S. Pat. No. 7, named infusion pump load mechanism , 306, 578 (Attorney Docket No. C54) are hereby incorporated by reference in their entirety. Using technology,
Seamless communication and fail-safe operation can be enabled. Numerous other features,
Functions and applications are obvious in light of the present disclosure.

General Overview As noted previously, the process of providing patients with comprehensive care, such as medical care instruction and delivery, is associated with several important issues. For example, significant potential for miscommunication of important information, treatment decisions are made without provision for access to full information, and / or delay of prescription delivery due to unnecessary redundant and inadequate treatment There is.

More specifically, medication errors can cause hundreds of deaths, each year in the United States alone,
May have injured thousands or even millions. Hospitals that are under financial pressure may experience many medication error accidents. Medications associated with many dangerous mistakes include insulin, narcotics, heparin, and chemotherapy. Causes of medication errors include administering the wrong drug, administering the wrong concentration of drug, delivering the drug at the wrong rate, or delivering the drug by the wrong route (drugs are administered orally Can be administered intravenously, intramuscularly, subcutaneously, rectally, locally to the skin, eyes or ears, intrathecally, intraperitoneally, or even intravesically) It is done. Even with proper order and labeling, drugs can still be administered improperly due to illegible handwriting, incorrect delivery of drug prescriptions, and incorrect pronunciation of drugs with similar names is there. There has been a trend to use electronic medical records (EMR) and drug barcode systems to reduce medication error accidents. The EMR system may, for example, enter computer provider instructions (C that do not match the patient's diagnosis, allergy, weight, and / or age
POE) and flag prescription can be facilitated. However, these systems have not been widely adopted and their implementation can lead to significant delays and inefficiencies in ordering, preparing, and administering drugs.

In addition, drug infusion devices, such as infusion pumps, are associated with a significant number (eg, up to a third) of all medication errors that lead to significant damage. Incorrect parameters (such as drug concentration or infusion rate) are entered, where the wrong drug is suspended,
Or existing injection parameters may be changed inappropriately. Nearly half of the deaths associated with infusion pumps are due to user mistakes, and many of these mistakes can be due to mistakes in programming the infusion pump.

An effective monitoring system can be monitored and arbitrated at any stage of the drug instruction and administration process to minimize any of a number of adverse events that may result from treatment. The drug treatment process can be conceptually divided into three stages, a prescription stage, a drug preparation stage, and a drug administration stage. Mistakes can occur when a drug prescription is written or entered, when the drug is collected for use or mixed into a solution, or when the drug is administered to a patient.

Thus, according to embodiments of the present disclosure, 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 at least one patient Configured to facilitate communication between the monitoring client and at least one patient-care device by discovering the presence of the care device and converting communication signals from the device into a communication protocol associated with the monitoring client An electronic patient care system with a communication interface is disclosed. In some embodiments, the monitoring client passively monitors the operation of the patient-care device. The communication interface can be implemented by the communication module described below. The communication interface further discovers the presence of other additional patient-care devices that differ from each other (eg, various manufacturers, functions, and / or communication protocols) and communicates communication signals from these devices to the monitoring client or hub It can be configured to convert to an associated communication protocol. Therefore,
The communication interface effectively uses a monitoring client, such as a tablet computer, as a common general user interface that healthcare providers can use when providing treatment to patients associated with the monitoring client It becomes possible. One or more databases accessible by the monitoring client include central storage of patient information (in any format and database structure desired by the healthcare facility or database maintainer) and patient treatment associated with the monitoring client. Allows downloading of information that can be used by healthcare providers during The communication interface can be implemented in a number of ways using wired and / or wireless technologies, allowing seamless communication and fail-safe operation of multiple patient-care devices. Some patient-care devices, hubs, docks, and / or monitoring clients can communicate simultaneously on two or more communication links and / or simultaneously on two frequency channels (in some embodiments, The data may be redundant). In some embodiments, the communication module allows the patient-care device to be used in a portable manner by including a battery and sufficient circuitry for movement operation of the patient-care device, eg, an infusion pump. In addition, or alternatively, the patient wrist band may comprise a battery that can be plugged into the communication module to power the patient-care device (or in some embodiments, within the patient-care device) Can be plugged directly into). The communication module can be charged wirelessly.

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

System Architecture As shown in FIG. 1, an electronic patient care system 100 includes one or more monitoring clients 1, 4 that can be assigned in physical proximity to each individual patient 2, and several different And a remote monitoring server 3 that uploads information from the monitoring clients 1 and 4 and downloads information and instructions from various sources to the monitoring clients 1 and 4.
In the case of a patient room, the health care provider can interact directly with the monitoring client 1 to obtain information about the patient 2 or to 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 (for example, middleware on the monitoring server 3 in FIG. 1). In addition or alternatively, a provider at a remote location (eg, a doctor's office, a nurse station 5, a hospital pharmacy 6) may connect each monitoring client 1, 4 through a communication link with the monitoring server 3 or It is possible to interact with the individual monitoring clients 1 directly through the hospital local area network which has as a node.

Pharmacy 6 sent to update or dispense patient personal EHR 19
The remote communicator 11, other monitoring client 4, nurse station 5, or doctor's office may be filled in the prescription sent to. The prescription may be a prescription for pills, for injecting fluids, or for other treatments. The prescription may be a prescription for injecting fluid using infusion pump 7, syringe pump 126, or microinfusion pump 130, or for dispensing pills using pill dispenser 128. .

The pharmacy 6 can comprise one or more computers connected to a network, for example the Internet, for receiving the prescription in one or more computers and queuing the prescription. The pharmacy uses (1) an automated compounding device (eg, coupled to one or more computers, capable of compounding fluids or generating pills, or queues of one or more computers) (2) prefill the fluid reservoir of the syringe pump 126 (manually by the pharmacist monitoring the)
3) Program syringe pump 126 (eg, treatment plan is syringe pump 1
(4) prefill the microinfusion pump 130, (5) program the microinfusion pump 130, (6) prefill the intravenous bag 170, (7) Program infusion pump 7, (8) pre-fill pill dispenser 128, or (9) pill dispenser 1 at pharmacy according to prescription
A prescription can be used to program 28. The automatic compounding device can be a syringe pump 126, an intravenous bag 170 or a microinfusion pump 1
Fluids can be automatically filled into one or more of 30 and / or pill dispenser 128 can be automatically filled with pills. The automated compounding device can generate barcodes, RFID tags, and / or data. Barcode, RF
Information in the ID tag and / or data can include treatment plans, prescriptions, and / or patient information.

The automatic compounding device (1) attaches the barcode to the infusion pump 7, syringe pump 126, microinfusion pump 130, pill dispenser 128, or intravenous bag 170. (2) RFID tag to the infusion pump 7, syringe Attached to pump 126, microinfusion pump 130, pill dispenser 128, or intravenous bag 170, and / or (3) infusion pump 7, syringe pump 126, microinfusion pump 130, pills with information or data Dispenser 128,
Alternatively, the RFID tag or memory in the intravenous bag 170 can be programmed. The data or information may include, for example, a bar code, RFID tag, or serial number or other identifying information in memory, prescription pump 7, syringe pump 126,
It can be sent to a database (eg, patient EHR 19 or patient personal EHR 19 ′) associated with the microinfusion pump 130, pill dispenser 128, or intravenous bag 170.

Infusion pump 7, syringe pump 126, microinfusion pump 130,
Or the pill dispenser 128 may be (1) a syringe pump 126 or an intravenous bag 1
70 has the correct fluid, (2) whether the microinfusion pump 130 has the correct fluid, (3) whether the pill dispenser 128 has the correct pill, (4) infusion pump 7, syringe pump 126, microinfusion pump 130, or therapy programmed into intravenous bag 170 is syringe pump 1
26, whether it corresponds to the fluid in the microinfusion pump 130, or intravenous bag 170, (5) whether the treatment programmed in the pill dispenser 128 corresponds to the pill in the pill dispenser 128 And / or (6) treatments programmed into infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 (eg, patient barcode, RFI)
There may be a scanner (eg, RFID interrogator or bar code scanner) that determines whether it is correct for a particular patient (as determined from D, or other patient identification information). That is, in some specific embodiments, infusion pump 7, syringe pump 126, microinfusion pump 130, and / or pill dispenser 128 reads one or more serial numbers from an RFID tag or barcode. Match the value as it is found in the internal memory (eg downloaded via an automatic compounding device), or the value is stored (eg in the patient's EHR 19 or in the patient's personal EHR 19 ′) To ensure that it matches the value as found in the patient's electronic medical record (via the patient's serial number as determined by scanning the patient's RFID tag or scanning the barcode by the patient) it can.

For example, the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 scanner may scan another patient-care device barcode to obtain the patient-care device serial number, and the patient serial. The patient's barcode can be scanned to determine the number, and the patient care device's serial number is in the electronic medical record (eg, may have been updated by the pharmacy 22 or the pharmacy's automatic compounding device) Electronic medical record data can be queried to determine if it corresponds to a patient serial number as stored.

In addition or alternatively, the monitoring client 6 may: (1) Syringe pump 1
26 or intravenous bag 170 has the correct fluid, (2) whether the microinfusion pump 130 has the correct fluid, (3) pill dispenser 128
(4) therapy programmed in infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is syringe pump 126, microinfusion pump 130, or whether it corresponds to the fluid in the intravenous bag 170, (5) whether the treatment programmed in the pill dispenser 128 corresponds to the pill in the pill dispenser 128, and / or (6) Infusion pump 7, syringe pump 126, microinfusion
Treatments programmed into the pump 130 or pill dispenser 128 (e.g.,
Infusion pump 7, syringe pump 126, pill dispenser 128, microinfusion to determine if it is correct for a particular patient (as determined from the patient's barcode, RFID, or other patient identification information) • Pump 130 or intravenous bag 170 can be scanned. In addition or as an alternative, the monitoring client 1, the infusion pump 7, the syringe pump 126, the microinfusion pump 13
0, or pill dispenser 128, for example, infusion pump 7, syringe pump 126
The electronic medical record database 19 or 19 'and the bar code serial number on the microinfusion pump 130, pill dispenser 128, or intravenous bag 170 to verify the prescription or download the prescription Inquiries can be made to the pharmacy 22.

Optionally, instructions or requests can be sent to patient care devices 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148, for example, bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile to infusion pump 7, syringe The monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to transmit to the pump 126 and / or the microinfusion pump 130. In some embodiments, monitoring to send instructions or requests to the pill dispenser 7, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. One or more of the clients 1, 4, 11 can be used. The maximum pill distribution criterion is the maximum amount of drug that can be delivered within a given time interval,
For example, a particular drug may be taken as needed (ie, when needed), but if overdose, the drug may not be safe, and the maximum pill distribution criteria Ingestion at a non-safe level, eg, a predetermined amount during a predetermined time interval, can be prevented.

Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128
, 130, 148 also determine whether an alarm or alert should be issued or transmitted, determine whether the treatment or condition is safe for the patient, system 10
Monitor data to determine if 0 is operating properly or at predetermined boundaries and / or display data on the display of the monitoring client 1, other monitoring clients 4 and / or remote communicator 11 A reply can be sent to the client 1, another monitoring client 4, and / or the remote communicator 11. For example, optionally, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may provide an upstream pressure, a change in upstream pressure, a downstream pressure for patient 2, a downstream pressure for patient 2. Change, presence or absence of air in the infusion line, actual bolus delivered, actual infusion flow, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual The delivery flow profile can be communicated (if applicable) to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 optionally includes, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or the maximum pill dispensing criteria has been exceeded. Data such as
Monitoring client 1, other monitoring client 4, and / or remote communicator 11
Can reply to.

Patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 14
The data received from 8 can be analyzed for any given condition to raise an alarm and / or alarm. For example, one or more of the monitoring clients 1, 4, 11 may be downstream by a material such as excessive coagulation, penetration, occlusion or bending of tubing to the patient, or contamination seen, for example, in the intravenous bag 170. One indication of the resulting blockage can be an increase in pressure downstream of infusion pump 7, syringe pump 126 and / or microinfusion pump 130. In response to the rapid increase in downstream pressure, one or more of the monitoring clients 1, 4, 11, can alert or alarm the user visually or audibly. These alarms and / or alerts also respond to the nurse in other appropriate actions, such as an occlusion (eg, caused by coagulation) when the downstream pressure on the patient rises above a predetermined threshold. A suggestion to replace the needle, or a suggestion to check for folds in the line if the downstream pressure on the patient rises above a predetermined threshold can be informed.

In addition, or alternatively, a sudden drop in downstream pressure on the patient 2 is an indication that the tubing has been removed from the needle and / or that the needle is now removed from the patient, and accordingly, One or more of the monitoring clients 1, 4, 11 may visually or audibly warn or warn the user to reattach the tubing to the needle or insert a new needle for continuous infusion. Can do. Alarms can also be activated quickly because the patient may be bleeding, for example when the tubing is disconnected from the needle, and the patient is bleeding due to an unattached needle coupler May indicate that.

In some embodiments, in addition or alternatively, the upstream pressure for one or more infusion pumps 7 can be monitored for any upstream blockage. For example, contamination in the intravenous bag 170 may block the upstream piping of the infusion pump 7. Each time infusion pump 7 attempts to pump fluid from intravenous bag 170,
The upstream pressure for the infusion pump 7 may be lower than would occur if there was no blockage upstream. Thus, one or more of the monitoring clients 1, 4, 11 will issue an alarm or alarm when the upstream pressure falls below a predetermined threshold, for example, by the caregiver replacing the tubing or intravenous bag 170 May suggest or need to relieve the obstruction.

One or more of the monitoring clients 1, 4, 11 are optionally configured to stop the delivery of fluid in response to a rapid increase and / or decrease in downstream pressure on the patient 2. Pump 126 and / or microinfusion pump 1
Instructions can be sent to one or more of 30.

As shown in FIG. 1 and as in some embodiments, the system 100 includes a monitoring client dock 102 and a device dock 104. Monitoring client
The dock 102 is configured to receive the 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). Device dock 10
4 is shown as being capable of receiving several patient-care devices, but in other embodiments, the device dock 104 is a single patient-care device, multiple patient-care devices, or any Any number of patient-care devices can be received. in addition,
Although the monitoring client dock 102 is shown as being capable of receiving one monitoring client 1, in other embodiments, the monitoring client dock 102 has two monitoring clients 1, three or more monitors. It is possible to receive a client 1 or any arbitrary number of monitoring clients 1.

In the exemplary embodiment, cable 110 is coupled to both docks 102, 104 to provide a communication link therebetween. The cable 110 is connected to the docks 102 and 104.
Can be or can be permanently attached to one or both of them. Additionally or alternatively, the cable 110 may include one or more connectors (not explicitly shown) for plugging the cable into one or both of the docks 102, 104.

In some embodiments, the docks 102, 104 can communicate with each other using one or more wires and / or waveguides within the cable 110. For example, in an embodiment of the present disclosure, the cable 110 includes 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 this disclosure, cable 110 may be replaced with one or more wireless communication links (eg, Bluetooth, etc.) if desired. Yet another embodiment is a dock 1
A combination of wired and wireless communication channels between 02 and 104 can be utilized. Any number of suitable wired connection types can be used in various embodiments.

In some embodiments, the communication link between docks 102, 104 is any known communication link such as serial communication, parallel communication, synchronous communication, asynchronous communication, packet-based communication, virtual circuit-based communication, etc. Can be used. Additionally or alternatively, in some embodiments, the communication link established between the docks 102, 104 may be a wireless communication, a wired communication, a connectionless protocol, such as a user datagram protocol (UDP) Or a connection-based protocol, such as a communication control protocol (TCP
) Can be used. For example, communication between docks 102, 104 can be universal serial bus standards, SATA, eSATA, FireWire, Ethernet standards, Fiber Channel, Bluetooth, Bluetooth Low Energy, WiFi, any physical layer technology, any OSI. It can be based on one or more such as layer technology.

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

Still referring to the exemplary embodiment shown in FIG. 1, the device dock 104 can include various accessories such as an attachable display 134, a camera 136, and a microphone 138, each of which is optional. Similarly, the surveillance client dock 102 can include various accessories such as a camera 140 and a microphone 142, each of which is optional. The monitoring client 1 can include various accessories such as a camera 144 and a microphone 146, each of which is optional. The cameras 136, 140, 144 can be used by face recognition software, for example, to authenticate or identify the presence of a provider (eg, nurse, nurse practitioner, physician, etc.) and / or patient.
Additionally or alternatively, microphones 138, 142, and 146 can be used by voice recognition software, for example, to authenticate or identify the presence of a provider and / or patient. As can be appreciated in view of the present disclosure, the cameras 136, 140,
144 and microphones 138, 142, 146, for example, the patient communicates with the remote care provider before initiating treatment to ensure that the correct patient receives the correct treatment, and / or
Or it can be used to allow confirmation of patient identification information (eg, using voice and / or facial recognition techniques, retinal scanning, etc.).

As shown in FIG. 1, in some embodiments, the monitoring client 1, the monitoring client dock 102, and the device dock 104 are each an antenna 11 for wireless communication.
2, 106, and 108 (each antenna 112, 106, and / or 108
Is optional). Dock 10 with cable 110 disconnected or via cable 110
If communication between the two, 104 is otherwise interrupted or compromised, the monitoring client dock 102 and device dock 104 communicate with each other using a wireless communication link established through antennas 106, 108. Can continue. In addition to it,
If the monitoring client 1 is removed from the monitoring client dock 102, the monitoring client 1 can communicate directly to the device dock 104, for example, and / or the monitoring client 1 can be connected via the cable 110 or the dock 102. , 104 can communicate with the device dock 104 by wirelessly communicating with the monitoring client dock 102 that relays the communication over the wireless communication link between them. As described previously, 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.

In some embodiments, the monitoring client 1 is, for example, the monitoring client dock 1
Measuring the voltage or impedance between the two electrical contacts of the connector of the monitoring client 1 used for docking to 02 and for providing electrical communication between the monitoring client dock 102 and the monitoring client 1 To determine whether one or more electrical contacts of one or more connectors are in electrical engagement with the monitoring client dock 102 to determine whether the cable 110 is available as a communication link. Can be determined. Also, if the monitoring client 1 determines that the monitoring client 1 is not electrically coupled to the cable 110, the monitoring client 1 can determine that the cable 110 is not available. Additionally or alternatively, in some embodiments, the magnet in the dock 102 engages the Hall effect sensor in the monitoring client 1 and then the cable 110 is unplugged when the monitoring client 1 is not docked. This is used by the monitoring client 1 to determine if it is docked so that it is not available as a communication link. In addition, 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 periodically rotates the ““ of the device dock 104 via the cable 110.
You can “ping the network connection”. If the monitoring client does not receive a response from the device dock 104 within a predetermined time, the monitoring client 1 estimates that the cable 110 is not available as a communication link.

If the monitoring client 1 determines that the cable 110 is not available as a communication link, the monitoring client 1 can issue an alarm or alarm using a speaker and / or a vibration motor, and an alarm or alarm remote communicator. 11 can use a speaker and / or vibration motor to alert or alert a remote communicator, and / or the monitoring client 1 communicates with the patient-care device via other communication links. You can try to. The term “alarm” as used herein is intended to include “soft” alarms, such as alarms that do not cause people to watch until after a certain amount of time has passed and the cause of the alarm remains, for example. doing.

In some embodiments of the present disclosure, the monitoring client dock 102 includes one or more wires or waveguides from the monitoring client 1 to the cable 110 with or without minimal circuitry. For example, in some embodiments of the present disclosure, the monitoring client dock 102 is a cradle that provides direct electrical coupling from the monitoring client 1 to the cable 110. In addition or alternatively, in some embodiments of the present disclosure, the device dock 104 may include various docked devices via the monitoring client dock 102 that use minimal circuitry or no circuitry. One or more wires or waveguides that facilitate communication between the monitoring clients 1.
The device dock 104 may be a cradle in some embodiments.

In an embodiment of the present disclosure, each monitoring client 1 is assigned to a specific patient 2 and may be desk-based, portable, or hand-held and have display and user input capabilities. The monitoring client 1 can be portable and can facilitate efficient data browsing and data entry, and the monitoring client 1 can be a notebook PC, a netbook PC with or without a touch screen. , Tablet PC, “smart phone”. Additionally or alternatively, in some embodiments, the monitoring client 1 and / or the remote communicator 11
It can be docked or coupled to a cable connected to a much larger display, thereby making a much larger display (eg, a 24 inch display) a display for the surveillance client 1 and / or the remote communicator 11 and much more The large display can have input capabilities such as touch screen capability, touch pen input capability, keyboard input capability, remote control input capability, etc. that are communicated to the monitoring client 1 and / or the remote communicator 11. For example, viewing of X-ray or patient imaging files can be facilitated by docking the surveillance client 1 and / or remote communicator 11 to a surveillance dock coupled to a larger display, thereby providing caregiver care. Can view patient imaging files using a larger display. The browsing dock can also charge the monitoring client and / or the remote communicator 11.

The monitoring client 1 includes a Linux-based operating system, an Android-based operating system, a BlackBerry-based operating system, a tablet-based operating system, iOS,
An iPad OS, an iPhone OS, or the like can be executed. The designation of a particular monitoring client 1 to a particular patient 2 may include (but is not limited to) a unique patient identifier encoded on, for example, a barcode 114 or RFID tag 116 embedded in the wristband 118. This can be done using any of several methods, including: The device dock 104 includes a scanner 120 to determine a unique patient identifier for the barcode 114 or RFID tag 116. The scanner 120 can be a laser bar code scanner, a CCD based bar code scanner, a short range communicator or interrogator, RF
It may be an ID reader or the like. In other embodiments, the unique patient identifier may be based on patient biometric data. In one such exemplary case, vital capabilities (eg, face and / or voice recognition, retinal scan, blood group monitor, fingerprint scan, etc.) can be embedded in or associated with the monitoring client 1. . The device dock 104 monitors the unique patient identifier to facilitate patient 2 treatment.
It can communicate with the dock 102, the monitoring client 1, the monitoring server 3, the remote communicator 11, another monitoring client 4, another server, or an electronic computing device.

The monitoring client 1 is a microprocessor, microcontroller,
One or more of logic devices, digital circuits, analog circuits, etc. can be provided. For example, the monitoring client 1 can send or receive patient care parameters such as patient condition parameters and / or patient treatment parameters. Some exemplary patient condition parameters are measurements such as blood pressure, body temperature, heart rate, pulse oximeter, CO ₂ level, blood oxygen level, patient arousal, patient awareness, patient response, and the like. Some exemplary patient treatment parameters include administered drug, drug or liquid flow rates, drug administration schedules, or other bedside treatment parameters.

In some embodiments, for example, the monitoring client 1 can be physically associated with the infusion pump 7, can be permanently attached, can be attached, can be removed therefrom, or can be attached. Can be removed. This can be achieved by a docking interface between two devices, eg, the monitoring client dock 102 and the device dock 104. In one such embodiment, the monitoring client 1 is connected by an electrical connector, for example through electrical contact with the docks 102, 104.
Or communicate with the pump 7 (or other patient-care device) in several ways, including using each antenna 112, 122A wirelessly by a transceiver on each device.
Additionally or alternatively, the infusion pump may 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. Can be included.

The monitoring client 1 also includes one or more databases in the facility 8 and the facilities 9, 1
Can communicate with zero external databases and / or with healthcare providers that use the portable communicator 11 (eg, including physicians, nurses, and pharmacists). This may be via a wired connection to the equipment server 8 through a connector in the patient's room (eg, Category 5 local area network connector, USB, wired Ethernet, etc.) or (eg, WiFi, 3G, 4G). , EVDO, WiMax, etc.) can be achieved. In one embodiment, access to the intra and extra equipment databases is mediated 13 (e.g., using middleware) through the monitoring server 3 and then communicates with databases having heterogeneous organizations, formatting, and communication protocols. Software and application programming interfaces. Therefore, in the embodiment of the present disclosure, any software update can be largely limited to the monitoring server 3, and maintenance requirements on the individual monitoring clients 1, 4, 11 can be reduced. Optionally, the monitoring client 1 can communicate with a patient treatment device such as an infusion pump 7 in order to receive information regarding the progress of treatment (such as operating parameters) and provide operational instructions to the patient treatment device. In another embodiment, the monitoring client 1 also receives read information from the device,
Potentially, to instruct the device 14, 15, 16, 17 to take a reading if desired by the provider or by the algorithm (eg, an electrocardiogram (EC
G) monitor 14, a blood pressure (BP) monitor 15, a pulse oximeter, or CO ₂ capnometer 16 or such other devices such as a temperature monitor) and diagnostic or monitoring purposes patient care devices for receiving patient condition parameter Can communicate.

  In an embodiment of the present disclosure, the facility service 8 and / or the adverse drug event network 9 may also include a drug 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. The soft alarm can be disabled (eg, stopped) by the caregiver using the infusion pump 7 and / or the user interface of the monitoring client 1 (and may only be an audible and / or vibration alarm). On the other hand, a hard alarm interrupts treatment until the cause is removed.

In yet additional embodiments of the present disclosure, the DERS system may include a first set of predetermined criteria defining soft limits and / or a second set of predetermined criteria defining hard limits. it can. Hard and soft limits define treatment limits, such as drug dose limits, based on dimensions, weight, age, other patient parameters, or other criteria. The soft limit prevents the treatment from starting while the hard limit prevents the treatment from starting until the setting is changed to meet the second set of predefined criteria that define the hard limit. Despite being outside the predetermined criteria, it can be disabled by the caregiver using the infusion pump 7 and / or the user interface of the monitoring client 1 to initiate treatment.

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

Each communication module 124A-124K is optionally connected to one another on the one or more wireless links, to the device dock 104, to the monitoring client dock 102, to the monitoring client 1, to the remote communicator 11, and to the monitoring server. 3. On a local area network and / or a wide area network (eg, the Internet)
One or more transceivers are provided for communicating to the hub 802 (see FIG. 8) and / or for communicating with any other device that otherwise has sufficient wireless communication capabilities. In some specific embodiments, the communication modules 124A-124K may be, for example, IEEE 802.14.4, Zigbee, XBee, Wibre, IEEE 802.
. 11 can be used, for example, to operate as a wireless mesh network. In a more general sense, communication between modules 124A-124K and other components of system 100 (eg, docks 102 and 104, monitoring clients 1, 4, 11, etc.) is, for example, (eg, monitoring client 1, 4, 11 and / or dock 1
Device discovery, handshake, as described herein, whether in static, dynamic, or ad hoc topologies (to accommodate the mobility of various medical devices associated with 04) And / or can be implemented using any wireless communication protocol that enables inter-device communication.

In other embodiments, each patient-care device may not include a module, or may include more than two modules (eg, a communication module). For example, each module can have a specific function, for example WiFi, and the user can select multiple modules each having a specific function and combine them together. The group of modules can then be applied to a patient-care device, such as an infusion pump. Consider yet another embodiment. Each module can have a primary processor, a backup processor, and functional circuitry, all in operative communication with each other. The functional circuit is an interface to a wireless transceiver, battery, touch screen or display (the display can be attached to the housing), wire connection, Bluetooth, Bluetooth Low Energy, WiFi, 3G, 4G, coprocessor (e.g. It may be a control system (to control the infusion pump), medication using a fluid measurement circuit, or the like. Selected modules can be connected to each other, eg, in a daisy chain, and then connected to an infusion pump. Selected modules can operably communicate with each other in this example to coordinate their operation and / or function, eg, via a CAN bus, wired communication, wireless, and / or the like.

Each module may comprise a speaker and a microphone. If several modules are connected to each other, the module can adjust its operation, so that while another module is using the microphone to determine if the speaker is functioning properly In addition, one module audibly sends a signal to the speaker. Several modules can each use their speakers on different frequencies, so that any one of the modules senses audio through its microphone and at the same time inspects some of the speakers Different frequencies can be demodulated. The test can be requested by the first module to the second module, and the second module can send the result of the test to the first module.

With continued reference to FIG. 1, one or more of the communication modules 124A-124K may also optionally include one or more batteries to provide power to devices coupled thereto. For example, the communication module 124A can be coupled to the infusion pump 7 to provide power thereto. Other structures and functions of the communication modules 124A-124K may be included depending on the purpose and function of the associated device. For example, in some embodiments, control of infusion occurs at the infusion pump and input related to the desired delivery occurs at the infusion pump, and therefore, in some embodiments of the present disclosure, the communication module 124A may In order to control, a control algorithm, such as a proportional integral derivative (PID) control loop, is implemented. In such a case, the monitoring client 1 can communicate the fluid flow signal to the communication module 124A (eg, via a wireless link), for example, and then to achieve the desired flow rate of the infusion pump 7 A signal corresponding to the fluid flow signal is applied through an electrical contact coupled to a motor (not explicitly shown). In some embodiments, the infusion pump 7 provides one or more feedback signals from a flow meter provided in the infusion pump 7 to the communication module 124A so that the communication module 124A operates the infusion pump 7. (E.g., some aspects of operation such as a PID control system) can be controlled. The results can be delivered to the monitoring client 1 for display to the user using a GUI, such as a QT-based GUI (in some embodiments, the monitoring client 1 is a tablet). Additionally or alternatively, in some embodiments, an infusion flow meter 148 is used to wirelessly communicate the flow rate to the communication module 124A via the communication module 124K and antenna 122K associated with the infusion flow meter 148. can do.

As can be appreciated in view of the present disclosure, the communication modules 124A-124K can be operatively coupled to various patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. For example, with further reference to FIG. 1, communication module 124B is operatively coupled to syringe pump 126 and communication module 124C is connected to pill dispenser 12
8 is operably coupled. In addition or alternatively, the communication module 124
E is operably coupled to ECG monitor 12, communication module 124F is operably coupled to blood pressure monitor 15, and communication module 124G is connected to pulse oximeter / CO.
_{The two-} capnometer 16 is operably coupled and the communication module 124H is connected to another monitor 1
The communication module 124I is operably coupled to the patient's intravenous access 35, and the communication module 124K is operably coupled to the drip flow meter 148. Each respective communication module 124A-124K includes, for example, a suitable control system, control algorithm, battery power, or respective patient care device 7, 14, 15, 16, 17, 35, 126, 128, coupled thereto. Alternatively, other functions for 148 can be provided.

Additionally or alternatively, in some embodiments, the communication module 124D
Are docked in the device dock 104, for example to communicate with any device attached to the device dock 104, and in the device dock 104, in the monitoring client dock 102, and In order to communicate with the monitoring client 1, it is operatively coupled to the device dock 104 via a bus or backplane. Optionally, the communication module 124D is configured to use the device dock 10
Any device docked in 4, eg infusion pump 7, syringe pump 12
6. Communication and / or power may be provided to the pill dispenser 128, or the microinfusion pump 130. Note that the functionality of the communication module 124D can also be integrated into the circuitry of the device dock 104 itself.

Additionally or alternatively, in some embodiments, each communication module 124 is replenished with one or more wired power sources, for example, power sources accessible through a bus or backplane in device dock 104. It is optional to configure each device 7, 14, 15, 16, 17, 35, 126, 148 capable of providing sufficient power supply. As previously discussed, in some embodiments of the present disclosure, the communication module 124D provides sufficient power to the devices 7, 126, 128, 130, and 133.

As previously discussed, in some embodiments, the communication modules 124 each provide a power circuit (eg, voltage converter, regulator circuit, etc.) that provides sufficient power to the corresponding devices 7, 126, 128, and 130. Rectification and filtering circuit, buck circuit, boost circuit, buck-boost circuit, switch mode power supply, etc.). In some such cases, this power circuit may be connected to a variety of different patient-care devices 7, 14, 15, 16,
17, 35, 126, 128, 148 can be configured to allow provision of various power supply characteristics (eg, voltage levels, maximum load / current requirements, and A / C frequency). is there. Any number of power provision and management schemes will be apparent in light of the present disclosure.

Optionally, in other embodiments of the present disclosure, a power module 132 having one or more battery cells, eg, lithium ion battery cells, provides sufficient power for the device 7, 126, 128 for the entire treatment duration. , 130, 133 for attachment to device dock 104. In addition or as an alternative, the power module 13
2 can be plugged into an outlet in the patient's room (generally shown as an AC source in FIG. 1) when available. In such cases, outlet power may be used to power the devices in dock 104, if available, and to charge the batteries contained in power module 132 (which may occur simultaneously). Can be used. If outlet power is lost or otherwise not available, the batteries in power module 132 and / or communication modules 124A, 124B, 124C
Power can be provided to the docked device.

Exemplary system 100 may optionally include a dongle 133. The dongle 133 may be docked in the device dock 104 shown in FIG. 1, or in other embodiments, remote from the device dock 104 and / or the monitoring client 1. Dongle 133 can provide a communication link or protocol for wireless devices that would otherwise not be available. For example, as new wireless protocols, technologies, standards, and technologies become available over time, dongle 1
33 can be used to provide bridges, routers, or repeaters between new communication protocols and convert information communicated in one protocol to another protocol, whereby the new protocol device can Care devices 7, 14, 15, 17,
35, 126, 128, 130, device dock 104, communication module 124D, monitoring client dock 102, monitoring client 1, hub 802 of FIG. 8, and / or other devices. The dongle 133 is a format known or used by each other, for example, the monitoring server 3 or the monitoring client 1.
Patient care device 7, 14, 15, 17, 35, 126, 128, 130, device dock 104, communication module 124D, monitoring client dock 102, monitoring client 1, hub 802 of FIG. 8, and / or other devices The data received from the new communication link may be retransmitted using the wireless protocol, technology, standard or technology used by any one or more of the above. Dongle 133 can also provide a communication bridge for mobile-based communication links, such as EVDO or CDMA-based mobile systems.

In some embodiments, the dongle 133 communicates patient care parameters from one or more patient care devices, eg, patient treatment parameters or patient condition parameters,
These can be retransmitted to the monitoring client 1, the hub 802 of FIG. 8, and / or the monitoring server 3, and vice versa. Optionally, in some embodiments, the dongle 133 can include a wired attachment connector, such as an RS-232 connector, to communicate from a legacy device with one or more other patient-care devices, monitoring clients. 1 for providing to the hub 802 of FIG. 8, and / or the monitoring server 3, etc.
Can be connected to the device. Legacy devices include, for example, legacy patient care devices,
It may be a legacy computing device, another device using a legacy wired communication protocol, or the like.

Optionally, the system 100 can also include various devices, docks, monitoring clients,
And / or a wearable system monitor 131 for monitoring the operation of the server. Program the wearable system monitor 131 using the monitoring client 1, the remote communicator 11, and / or the hub 802 of FIG.
Can interact with and / or pair with it. The wearable system monitor 131 can be worn by the patient 2 or a provider and a number of wearable system monitors 131 can be used. The wearable system monitor 131 can query various devices to ensure proper operation. For example, in one exemplary embodiment, the wearable system monitor 13
1 for patient care devices 14, 15, 16, 1 to determine whether any failure, mistake, fraud, data corruption, communication degradation, incomplete operation, slow operation, or other problems exist.
7, 35, 126, 128, 130, monitoring client 1, monitoring client dock 1
02, communicate with device dock 104, and / or hub 802 of FIG.

Communication from the wearable system monitor 131 is that the device being queried is functioning properly, is functioning within predetermined operating parameters, and / or is in a desired state or situation One or more interrogation signals can be included to determine whether. The system monitor 131 alerts the provider, initiates a shutdown procedure, and / or initiates other appropriate therapeutic actions directed to the device that is not operating normally, or the monitoring server 3, the monitoring client 1, or The detected condition or mistake can be communicated to one or more devices, such as hub 802 of FIG. For example, the system monitor 131 may be a monitoring client 1, a monitoring server 3, another monitoring client 4, a communication module 124 or other remote communicator 11 via a WiFi router coupled to the network and / or the Internet. The transceiver of the communication module 124J that communicates with the device can be used to signal an alarm and / or alarm due to an abnormal inquiry response or absence of an inquiry response. The alert and / or alarm can cause the device to audibly sound or visually indicate the alert and / or alarm. In some embodiments of the present disclosure, the system
The monitor 131 includes a call button (not explicitly shown) to allow the patient 2 to request to a care provider, eg, the request is visible to the user who owns the device Requests are routed to the monitoring client 1 or the remote communicator 11 for audible indication.

The system monitor 131 may, for example, (1) predict response to a query within a predetermined time, (2) increment a counter within the device being queried, and then increment the counter value from the device after being incremented. Requesting, (3) challenge response inquiry,
And / or (4) the functionality may be implemented in a variety of ways, including other system monitoring techniques or methods.

As previously described, in some embodiments, the system monitor 131 predicts a response to a query within a predetermined time after querying a patient-care device paired with the system monitor 131. For example, the system monitor 131 can send a text string message of “system monitor inquiry” to the infusion pump 7. In this example, infusion pump 7 receives a message labeled “System Monitor Query” from system monitor 131 and processes the message using one or more processors therein. When the infusion pump 7 processes a message, the software routine therein executes code that sends the response message back to the system monitor 131, for example, the response message is sent to the system monitor 131・
It may be a text string message of “monitor response”. In this embodiment, the system monitor 131 can expect to receive a response message within a predetermined time, such as 2 seconds, and if the system monitor 131 does not receive a response message within 2 seconds, System monitor 131 alerts other devices and / or sends alerts (eg,
The system monitor 131 can broadcast an alarm or a miss message, or the alarm or alarm can be audibly or visually provided to the processor via the remote communicator 11).

As previously described, in some embodiments, the system monitor 131 increments a counter in the device being queried and requests the counter value from the device after it has been incremented. For example, the system monitor 131 can send a request to the patient-care device, eg, the infusion pump 7, by sending a message such as an “incremental counter” to the device. The device's processor receives the "increment counter" message, reads the value from the device's memory location, increments the value found at the memory location, and stores the new value in the same memory location by overwriting the previous value . Thereafter, in this embodiment, the processor reads the new value from the memory location and transmits the new value to the system monitor 131, eg, via a wireless transceiver on the device being queried.
The system monitor 131, in this embodiment, predicts a specific value from the device being queried (this predicted value can be stored in the system monitor memory, eg, in a table). ). For example, the system monitor 131 can store 48 values previously received from a device in its memory, and after requesting that the values be updated in the queried device, 49 values from the device. Expect to receive a value.

Further, as described above, a challenge / response inquiry is sent to the system monitor 13.
1 can be used. For example, the system monitor 131 can send an encrypted message to the patient-care device. The patient-care device is then tasked to decrypt the message using, for example, an encryption key and send the message back to the system monitor 131. The system monitor 131 can predict an unencrypted message to return within a predetermined time. In this embodiment, when the system monitor 131 does not receive a response message within a predetermined time, the system monitor 1
31 alerts other devices and / or sends alerts (eg, system
The monitor 131 can broadcast alarms or alarm messages and / or communicate them to the monitoring client 1, the monitoring server 3, the hub 802 of FIG. 8, or the remote communicator 11, after which the Alarm or display audible).

In an embodiment of the present disclosure, the monitoring client 1 uses a handheld or portable remote communicator 11 (eg, may be a smart phone, tablet computer, PDA, laptop, or other portable computing device). Healthcare
Has the ability to communicate and interact directly with the provider. This can be accomplished by the radio 12 so that communication can be maintained regardless of the location of the patient within the facility or the location of the provider either within or outside the facility. In one aspect, information specific to the patient 2 can be stored locally within the monitoring client 1 so that the patient's healthcare provider can access the information directly without having to access the monitoring server 3. it can.

In some embodiments, the connected infusion pump 7 or patient monitoring devices 14-17, optionally by incorporating appropriate safety and security checks,
Changes to 35, 126, 128, 130, 148 settings or flow parameters are (
Monitoring client 11 and monitoring client 1 of the provider (via wired or wireless communication)
Selected changes can also be communicated to the monitoring server 3 and thereby optionally other suitable locations such as the nurse station 5 and / or the pharmacy 6. In addition, any new instructions regarding the patient 2 are entered into the instructing provider's remote communicator 11 (eg, smart phone) and the monitoring client 1
And then inform the caregiver (eg, nurse, nurse practitioner, doctor, physician, or other health care professional) via the caregiver's own portable communicator 11 Can do. In addition, or alternatively, in some embodiments, new instructions are sent to the infusion pump 7 or patient monitoring devices 14-17, 35, 12
6, 128, 130, 148 so that the control system therein or coupled thereto can change its operation, eg, set point, in response to new instructions. In some embodiments, any information obtained and stored in the monitoring client 1 is periodically uploaded to the monitoring server 3 and stored in a patient specific database. Thus, if the patient 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 added again. Instructions from the patient's attached device, medication, progress notes, monitoring data, treatment data, patient treatment parameters, patient monitoring parameters, and / or operating parameters are also for permanent, temporary or transient storage And / or predetermined criteria,
For example, from the monitoring client 1 to the patient's EHR 19, any applicable remote communicator 11, hub 8 in FIG. 8 for analysis to confirm compliance with ranges, thresholds, etc.
02 and / or upload to the monitoring server 3.

In some embodiments, the monitoring server 3 has several monitoring clients 1 in the facility 8.
4, 11 can be provided with a computer capable of communicating with and providing some elements of control. The monitoring server 3 can provide the monitoring clients 1, 4, 11 with data extracted from several databases on both the inside 8 and outside 9 of the facility. In an embodiment of the present disclosure, the monitoring server 3 queries the facility's EHR system 19 for target information about the patient 2 and then asks the patient's monitoring client 1 a predetermined set of information (eg, patient age, height, weight, Disease categories, current drugs and drug categories, drug allergies and hypersensitivity, etc.) can be added.
According to one such embodiment, the monitoring server 3 may include an EHR 19, laboratory 20, radiation 21, pharmacy 22, and / or other system in the facility, for example, when the monitoring client 1 is assigned to a patient 2. (For example, heart disease 23 or scheduling database 2
4)). With a unique patient identifier, the monitoring server 3 can obtain electronic access (permission) to receive patient-specific data from these systems and send them to the system. A predetermined (selectable) subset of the data can be downloaded into the memory of the monitoring client 1 (not explicitly shown in FIG. 1).

The information thus obtained can then serve as a key database where new instructions can be analyzed. The instruction input in the monitoring client 1 is
The compatibility with the patient-specific information obtained by the monitoring server 3 can be checked.
Optionally, for safety redundancy, instructions entered remotely from the communicator 11 can be intercepted by the monitoring server 3 and checked as well. The monitoring server 3 also retrieves information from drug databases in the pharmacy 22 of the facility or external 9 to determine whether new patient instructions may generate incompatibilities with the patient's existing drugs, for example. Can be obtained. In an embodiment of the present disclosure, the monitoring server 3 can download new information about the patient's indicated medication and communicate 13 with a warning or alarm to the patient's healthcare provider (s). Can be programmed to access a publicly accessible Internet site 25. The monitoring server 3 can also route information between the remote portable communicator 11 and the patient monitoring client 1.

In an embodiment of the present disclosure, the patient's physician, nurse or pharmacist can use the patient monitoring client 1 to relay or receive new instructions (eg, drug instructions, etc.) regarding the patient 2.
You can have access to The monitoring client 1 or server 3 then records the new instructions and sends the request to the pharmacist 6 and the patient's nurse.
It can be relayed via the communicator 11 and / or via the fixed terminal of the nurse station 5. A “smart phone” with a customized communication application on the monitoring client 1 (for example, Google Nexus One ph
one, Apple's iPhone, or RIM's BlackBerry OS) can serve as a convenient portable communicator 11 for providers that are not in fixed locations (such as offices or remote nurse stations). A tablet PC, netbook, or laptop computer can also serve as a portable communicator 11 that is convenient for both portable or fixed locations. The 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.

The monitoring client 1 can receive, process and communicate information about a specific patient 2 assigned or designated. The monitoring client 1 is most conveniently attachable or dockable to the monitoring client dock 102 to communicate with the infusion pump 7 or any other device to which the 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 is convenient to be able to have a touch screen interface for use by a patient provider. It is also possible to provide output through a wired or wireless connection to a larger fixed display in the patient's room or at the nurse station 5 or other convenient location.
Each monitoring client 1 can communicate with a central monitoring server 3 through which the equipment EHR database 19, laboratory database 20, radiation database 21, pharmacy database 22, or other databases of various other equipment departments. Can access patient data. In some cases, the monitoring client 1 may upload information received from the patient monitoring devices 14-17 or from provider inputs to the patient's EHR 19 via the monitoring server 3. The monitoring clients 1, 4 can also receive information from a database outside the facility through the monitoring server 3 having an internet connection 25. Various external databases 9 are therefore accessible, including various drug information databases and alarm networks that handle adverse drug related events.

The monitoring server 3 can be arranged, for example, to manage various levels of external database information that helps in keeping the contents of the monitoring client 1 as up-to-date as possible. This can be achieved, for example, by comparing patient-related safety and drug information when available and prioritizing updates / downloads on the data transfer schedule. The monitoring clients 1, 4 can also communicate either directly with the portable communicator 11 used by healthcare providers such as nurses, physicians, and pharmacists or through the monitoring server 3. In some cases, these devices may have a wired connection to the monitoring server 3 (for example, when used at a fixed location, such as a hospital pharmacy or nurse station). In other cases, the portable communicator 11 uses a wired or wireless (eg, Bluetooth or WiFi 802.11) connection 13 with the computer and device 11 to provide a secure internet connection (eg, a VPN-based internet connection, UPN, Htt
communication with the monitoring server 3 through ps, private key mechanism, etc. Alternatively, a handheld remote communicator 11 (such as a smart phone or a tablet netbook) can be directly connected to the equipment monitoring client 1 via a mobile phone network.
2 can communicate and / or the facility is connected to a WiFi network (e.g.
4 GHz to 2.4835 GHz unlicensed ISM band) can be included.

In some embodiments, the communication link between the monitoring clients 1, 4 and the monitoring server 3 is over an Ethernet network when widely available in the facility or using one of several criteria. All patient-specific monitoring clients 1, 4 can be linked to the central monitoring server 3 by way of wireless transmission. Server 3 can then act as a relay for communication with other equipment servers 8, web-based server 25, and inner and outer portable communicators 11 owned by medical care providers. In some embodiments, the wireless network provides additional functionality that allows communication with the monitoring server 3 regardless of where the patient 2 is in the facility.

One way to cover the entire facility in radio range requires the facility to obtain a private mobile phone network license. One or more micro-portable frequencies can be acquired or borrowed to provide a local communication network throughout the facility. Such an arrangement maintains communication when the patient and the monitoring clients 1, 4 are moved from one location in the facility to another so that the monitoring server 3, various in-hospital and off-hospital databases 8 25, and monitoring clients 11 (e.g., portable smart phones, laptops) with users at fixed stations (e.g., nurse station 5 and pharmacy 6 in some embodiments) or either inside or outside the hospital Or a tablet-type device). In some embodiments,
This type of system provides additional security through an authorized mobile communications infrastructure. In addition, in some embodiments, the active radio system can monitor the strength used in an area and command additional channel frequencies in that area.
However, in some embodiments, the bandwidth capacity of the network may not allow efficient transmission of large data files, such as those containing radiographic images. Such high bandwidth data files can be more efficiently communicated via a wired connection.

Alternatively or additionally, the hospital can implement an internet or intranet-based communication system in which the 802.11 WiFi type protocol is wireless between the individual monitoring clients 1, 4 and the monitoring server 3. Used for communication. In order to ensure proper signal reception throughout the facility, a broadband antenna can be mounted on the roof of the building to collect mobile phone signals from local wireless telephone companies. The fiber optic or cable network can then distribute the signal throughout the facility. In addition or alternatively, the monitoring server 3 can use the private mobile phone network described above. Such a system is typically capable of providing secure communications and can efficiently communicate large files, such as, for example, radiological images stored in the radiation database 21. . Home or office based users can connect to the hospital server through, for example, VPN or another secure access using wired or fiber optic cable, or a DSL telephone line. Data encryption can be used to provide patient data security. In some applications, it may be advantageous to implement an asymmetric bandwidth communication network to optimize infrastructure capabilities. This embodiment uses an authorized mobile frequency in the “upstream” direction from the monitoring client 1 to the monitoring server 3 and an unlicensed 802.11 WiFi frequency 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. For upstream transmissions with low priority, the monitoring client 1 allows data to be transmitted over a more distributed and cost-effective network, such as a ZigBee network, a Bluetooth network, a mesh network, and the like.

As previously described, communication between various monitoring devices, such as patient care devices 14, 15, 16, 17, 35 and monitoring client 1, can be, for example, ZigBee wireless mesh
It can be accomplished in a cost effective manner using a network and / or a Bluetooth network. Exemplary monitoring devices include, among others, ECG monitor 14,
Examples include a blood pressure monitor 15, a pulse oximeter / capnometer 16, a thermometer, and a weight scale. The most common feature of these devices is that they perform a periodic readout of a single or few parameters. In-hospital device communication systems, such as wireless mesh networks, provide low-power digital wireless connectivity between devices and utilize widely available license-free frequency bands (eg, 2.4 GHz in some jurisdictions) can do. A high level communication protocol can be used to ensure data fidelity and security, such as TCP, UDP, for example. For example, using a symmetric encryption key, Twofish, Serpent, AES (Rijndael), Blowf
Communication between the monitoring client and the patient-care device, such as that generated for cryptographic algorithms such as ish, CAST5, RC4, 3DES, IDEA, can be ensured. In addition or alternatively, various data integrity techniques may be used, such as, for example, CRC, odd parity bit check, or even parity bit check.

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 transfer data. Mesh networks are relatively low cost, scalable, and mobile to the patient being monitored. In some embodiments, the radio range for devices linked to a wireless mesh network can reach 70 meters from each node of the system in the facility. A similar network may be used to provide a wireless link within the facility between the portable communicator 11 owned by the healthcare provider and its assigned patient through the patient monitoring client 1, 4. it can.

In many cases, the information being communicated to the monitoring client 1 can include a single parameter value (eg, blood pressure, etc.) and a time stamp. The monitoring client 1 can be programmed to determine if the value is outside the predetermined range, record the value in the patient's EHR 19 and inform the appropriate provider via the monitoring client 11. In addition, the network allows two-way communication so that the monitoring client 1 is connected to the patient monitoring device (
For example, the BP monitor 15) can be queried and instructed to take an unscheduled read. This can be useful, for example, when an abnormal reading is received and its authenticity needs to be verified. The monitoring client 1 can be programmed to request repeated readings to verify abnormal readings. In another embodiment, the monitoring client 1 may be programmed to interrupt or adjust the flow rate, operating parameters, and / or treatment parameters of the infusion pump 7 according to the readings received from the monitoring devices 14-17. it can. For example, if the BP monitor 15 shows blood pressure below a predetermined tolerance, the monitoring client 1 can be programmed to instruct the infusion pump 7 to stop infusion, and an emergency notification 12 (one) (Or multiple) health care provider monitoring clients 11. In another embodiment,
If the infusion pump 7 is capable of determining the amount of fluid being delivered to the patient 2 (eg, the flow rate or cumulative amount of fluid that can be pumped during the interval), the monitoring client 1
The processor within can track the cumulative amount delivered and infer the amount of fluid remaining in the drug 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 infusion.)

When the estimated residual amount reaches a predetermined amount, the monitoring client 1 can signal the infusion pump 7 to reduce its flow rate and prevent the patient's intravenous access 35 from drying out. For example, the monitoring client 1 can determine whether the nurse is scheduled to return to change the bag at a particular time, and the intravenous fluid is gone before the nurse's scheduled return. Rather than sending the alarm and / or sending its alarm, the monitoring client 1 will empty the intravenous bag when the nurse arrives or after a predetermined time from the nurse's scheduled return time Thus, a signal can be sent to the infusion pump 7 to slow down the infusion rate. In addition, a notification recommending refilling of the intravenous bag 17 can be transmitted to the monitoring client 11 of the nurse.

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 and thereby lit (eg, when the border is filled, the percentage of the border that begins to form a fully filled outer perimeter) is such as the infusion pump 7, Fig. 4 shows the progress of treatment being performed by the patient-care device. The border can be communicated from the infusion pump 7 to the monitoring client 1 in image format (eg, JPEG, BMP, etc.) and / or as a completed percentage to the monitoring client 1, in which case the monitoring client 1 Is generated.

In some embodiments, a GPS and / or ranging module (eg, an ultrasonic ranging module using time-of-flight estimation) may be used for the infusion pump 7, the monitoring client 1, the caregiver,
And / or can be placed on the patient. The predetermined setting is that the infusion pump 7, the monitoring client 1, the hub 802 of FIG. 8, the caregiver, and / or a predetermined group of patients, in this particular embodiment, before initiating treatment and / or infusion. Before configuring one of the pump 7 and / or the monitoring client 1, it may be necessary to be at a predetermined distance relative to each other.

In some embodiments, patient care devices 7, 170, 126, 128, 130, 1
4, 15, 16, 17, 124, or 148, dock 102 or 104, monitoring client 1, hub 802 of FIG. 8 (e.g., caregiver solutions for removing the cause of the alarm without disturbing the patient). Soft alarms, hard alarms, and / or critical alerts without warning on the device that issues an alarm and / or on the monitoring client 1 until after a predetermined period of time (so that it can be found) No alarms can be sent to the remote communicator 11. If the cause of the alarm is removed before a predetermined time, the alarming device and / or the monitoring client 1 may not warn, thereby preventing additional disturbance of the patient.

In some embodiments, the AC cable of FIG. 1 includes a clip that can clip a venous tube thereto.

In some embodiments, the infusion pump 7 is in a state that indicates one or more of having passed a safety check, that the pump is flowing, that there is a blockage, and / or that the pump has been disconnected. Includes LED light. The user can read the barcode on the intravenous bag 170 using the monitoring client 1 (eg, using the camera 144 or camera 136 and / or the scanner 120), at which time the LED on the plug Can flash to indicate to the user that a tube connected to the intravenous bag 170 should be inserted therein.

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

In addition, in some embodiments, a number of items, components, devices, patients, numbered or unnumbered, as shown in FIG. 1 or as described herein. Although care devices, docks, and computing devices are shown as the only items, components, devices, patient-care devices, docks or computing devices, many items, components, devices, patient-care devices, docks and computing devices are Conceivable. For example, a single infusion pump 7 is shown in FIG. 1, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or Any arbitrary number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, multiple device docks 104 and / or multiple monitoring client docks 102 can be used.

In addition or alternatively, certain patient-care devices 7, 14, 15, 16, 1
Although 7, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. For example,
In some embodiments, only infusion pump 7 of the patient-care device is used,
In this particular embodiment, other patient-care devices 14, 15, 16, 17, 126, 128
, 130, 148, not present or not available for system use, powered down, or not part of the system 100 of FIG. In addition, or alternatively, in some specific embodiments, only the patient-care device that is used can be docked to the device dock 104. For example, in this particular embodiment, infusion pump 7 is the only device docked within device dock 102;
Only the device dock 102 receives one device, for example the infusion pump 7. In addition, alternatively or optionally, in some specific embodiments, the patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is dockable. Can be operated without, and / or not dockable and can operate as a stand-alone patient-care device.

In some embodiments, patient care devices 7, 14, 15, 16, 17, 35, 12
6, 128, 130, and / or 148, monitoring client 1, remote communicator 11, and docks 102 and / or 104 may include a secure data class, for example, via an API.

Any of the functions described with reference to FIG. 1 may, in some embodiments, be the hub 802 of FIG.
Can be done.

FIG. 2 illustrates a monitoring client, such as the monitoring client 1 of FIG. 1 and one or more of a patient-care device, such as the patient-care devices 7, 14, 15 of FIG.
, 16, 17, 35, 126, 128, 130, 148 shows a flowchart diagram illustrating a method 150 for maintaining communication between one or more. The example method 150 includes acts 152-169. The monitoring client 1 can display an icon indicating when communication has been established with the paired and / or designated patient-care device.
The monitoring client 1 can check to determine that pairing and / or communication with the designated patient-care device is available at predetermined intervals, and to the paired or designated patient-care device If the communication is not available for a predetermined time, the monitoring client 1 can sound an alarm or alarm.

Act 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.

Act 156 determines whether the monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock over a wireless link. Action 15
If six links are available, method 150 proceeds to operation 154; otherwise, method 150 proceeds to operation 158.

Operation 154 indicates that the monitoring client dock uses a cable to
It is determined whether it can be used as a communication link between the dock and the device dock. Action 15
If four communication links are available, method 150 proceeds to operation 160, otherwise method 150 proceeds to operation 158. Act 160 determines whether the device dock is available as a communication link between the device dock and the patient-care device, eg, via a wireless or wired communication link. If the communication link of operation 160 is available, method 15
0 proceeds to operation 166, otherwise method 150 proceeds to operation 162. Act 162 determines whether the patient-care device is available as a communication link between the monitoring client and the patient-care device dock via a direct wireless link. If the communication link of operation 162 is available, the method proceeds to operation 166, otherwise the method 150 proceeds to operation 164.

Action 158 is that the device dock is connected to the monitoring client and the device
It is determined whether it can be used as a communication link between docks. If the communication link of operation 158 is not available, method 150 proceeds to operation 162; otherwise, method 150 proceeds to operation 160.

Act 166 attempts a handshake between the monitoring client and the patient-care device using the available communication link. In an alternative embodiment, handshaking is not used, for example, not all protocols use handshaking 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 includes
Determining 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 16
9 communicates data using a sufficient number of communication links determined to be available by method 150.

Method 150 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, the method 150 includes a schedule for the communication link, but other schedules can be used, broadcast, anycast, multicast or unicast can be used, and a routing algorithm is used. Distance vector routing
Protocol can be used, link state routing protocol can be used, optimized link state routing protocol can be used, path vector protocol can be used, given alternative communication Static routing in the path can be used and / or an adaptive network can be used. For example,
In some embodiments of the present disclosure, a weight can be assigned to each communication path, and Dijk
Stra's algorithm can be used to communicate between the monitoring client 1 and one or more patient-care devices, and weight can be determined in any known manner, with bandwidth, signal quality, bits Inclusion as a function of error rate may be linear with available data throughput or latency and / or the like.

Referring to the drawings, FIG. 3 shows a block diagram of an electronic patient care system 300 having two docks 102, 104 for wireless communication therebetween according to another embodiment of the present disclosure. The system 300 is similar to the system 100 of FIG. 1, but communication between the monitoring client dock 102 and the device dock 104 is through a wireless link. For example,
In some embodiments, the system 300 of FIG. 3 is the system 100 of FIG. 1 with the cable 110 of FIG. 1 absent or not operating, and in addition or alternatively, the system 300 of FIG. Can have docks 102 and 104 that are not connectable together using a cable.

Optionally, instructions or requests can be sent to patient care devices 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148, for example, bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile to infusion pump 7, syringe The monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to transmit to the pump 126 and / or the microinfusion pump 130. In some embodiments, instructions or requests such as, for example, pill dispensing instructions for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria may be sent to pill dispenser 128.
One or more of the monitoring clients 1, 4, 11 can be used to transmit to The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval, for example, a particular drug is taken as needed (ie, when needed), but overdose The drug may not be safe if it is done, and the maximum pill dispensing standard can prevent the drug from being taken by the patient at an unsafe level, eg, in a predetermined amount during a predetermined time interval .

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

Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128
, 130, 148 also determine whether an alarm or alert should be issued or transmitted, determine whether the treatment or condition is safe for the patient, system 30
Monitor data to determine if 0 is operating properly or at predetermined boundaries and / or display data on the display of the monitoring client 1, other monitoring clients 4 and / or remote communicator 11 A reply can be sent to the client 1, another monitoring client 4, and / or the remote communicator 11. For example, optionally, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may provide an upstream pressure, a change in upstream pressure, a downstream pressure for patient 2, a downstream pressure for patient 2. Change, presence or absence of air in the infusion line, actual bolus delivered, actual infusion flow, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual The delivery flow profile can be communicated (if applicable) to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 optionally includes, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or the maximum pill dispensing criteria has been exceeded. Data such as
Monitoring client 1, other monitoring client 4, and / or remote communicator 11
Can reply to.

Patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 14
The data received from 8 can be analyzed for any given condition to raise an alarm and / or alarm. For example, one or more of the monitoring clients 1, 4, 11 are one indication of excessive coagulation, penetration, occlusion or bending of tubing to the patient, or occlusion by other materials in the intravenous bag 170. Increases in pressure downstream of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 can be used. In response to the rapid increase in downstream pressure, the monitoring clients 1, 4, 11
One or more of these can visually or audibly warn or alert the user. In addition, or alternatively, a sudden drop in downstream pressure on the patient 2 is an indication that the tubing has been removed from the needle and / or that the needle is now removed from the patient, and accordingly, One or more of the monitoring clients 1, 4, 11, can alert or alert the user visually or audibly. One or more of the monitoring clients 1, 4, 11 are optionally depending on whether the downstream pressure suddenly increases and / or decreases for the patient 2,
Instructions can be sent to one or more of infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery.

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

In addition, in some embodiments, some items, components, devices, patients, as numbered or unnumbered, as shown in FIG. 3 or as described herein. Although care devices, docks, and computing devices are shown as the only items, components, devices, patient-care devices, docks or computing devices, many items, components, devices, patient-care devices, docks and computing devices are Conceivable. For example, a single infusion pump 7 is shown in FIG. 3, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or Any arbitrary number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, multiple device docks 104 and / or multiple monitoring client docks 102 can be used.

In addition or alternatively, certain patient-care devices 7, 14, 15, 16, 1
Although 7, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. For example,
In some embodiments, only infusion pump 7 of the patient-care device is used,
In this particular embodiment, other patient-care devices 14, 15, 16, 17, 126, 128
, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 300 of FIG. Additionally or alternatively, in some embodiments, only the patient-care device that is used can be docked to the device dock 104. For example, in certain embodiments, infusion pump 7 is the only device docked within device dock 102 and only device dock 102 receives one device, eg, infusion pump 7. In addition, alternatively or optionally, in some specific embodiments, patient care devices 7, 14
, 15, 16, 17, 35, 126, 128, 130, 148 can be docked,
It can operate without docking and / or can be non-docked and operate as a stand-alone patient-care device.

In FIG. 3, the device dock 104 is shown as being capable of receiving several patient-care devices, but in other embodiments, the device dock 104 is a single patient-care device, multiple A patient-care device, or any number of patient-care devices can be received. Also, the dock compartment may not be used, for example, an empty compartment 170 is shown in the device dock 104 as shown in FIG. In addition, although the monitoring client dock 102 is shown as being capable of receiving one monitoring client 1, in other embodiments, the monitoring client dock 102 is
Two monitoring clients 1, three or more monitoring clients 1, or any arbitrary number of monitoring clients 1 can be received.

4 illustrates one or more of a monitoring client, eg, a monitoring client 1 and a device, such as the patient care device 7, 14, 15, 16, 17, of FIG. 3, according to an embodiment of the present disclosure.
FIG. 7 shows a flowchart diagram illustrating a method 202 for maintaining communication between one or more of 35, 126, 128, 130, 148.

Act 204 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 204 is available, method 202 proceeds to operation 206, otherwise method 202 proceeds to operation 208. Act 208 determines whether the monitoring client dock is available as a communication link between the monitoring client and the monitoring client dock over 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.

Act 206 determines whether the monitoring client dock is available as a communication link between the monitoring client dock and the device dock over a wireless link. Action 206
If the communication link is available, the method 202 proceeds to operation 212;
Method 202 proceeds to operation 210.

Operation 210 indicates that the device dock is connected to the monitoring client and the device
It is determined whether it can be used as a communication link between docks. If the communication link of operation 210 is available, method 202 proceeds to operation 212, otherwise method 202 proceeds to operation 214.

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 operation 216, otherwise, method 202 proceeds to operation 214.

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

Act 216 attempts a handshake between the monitoring client and the patient-care device using the available communication link (s). In alternative embodiments, handshaking is not attempted, for example, some communication protocols do not utilize handshaking. Decision operation 220 determines whether the handshake was successful and whether communication between the monitoring client and the device has been established. If operation 220 determines that a communication link has been established, method 202 uses the available communication link (s) to operate 22
2 to communicate data between the monitoring client and the device. If the decision operation 220 determines that the handshake has not been successful, the method 202 determines that communication with the device is not available in the operation 218, or the method 202 includes an unverified communication link (explicit Attempt to communicate between monitoring clients through (not shown).

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, the method 202 includes a schedule for the communication link, but other schedules can be used, broadcast, anycast, multicast or unicast can be used and a routing algorithm is used. Can use distance vector routing protocol, can use link state routing protocol, can use optimized link state routing protocol, can use path vector
Protocols can be used, static routing with a predetermined alternative communication path can be used, and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, weight can be assigned to each communication path and Dijkstr
can communicate between the monitoring client 1 and one or more patient-care devices using the algorithm of a, can determine the weight in any known manner, bandwidth, signal quality, bit Inclusion as a function of error rate may be linear with available data throughput or latency and / or the like.

Referring now to FIG. 5, the monitoring client 1 and various patient-care devices (eg, patient-care devices 7, 126, 128, or 13) according to yet another embodiment of the present disclosure.
An electronic patient care system 500 in the form of a block diagram is shown having a dock 502, a communication module 124D, and a dongle 133 for docking 0) together. FIG.
The electronic patient care system 500 is similar to the electronic patient care system 100 of FIG.
Monitoring client 1, patient-care device 7, 126, 128, 130, communication module 1
Each of the 24D and the dongle 133 can be docked to the dock 502. As can be appreciated in view of the present disclosure, the dock 502 may include one or more buses, backplanes, communication paths, electronic circuits, etc. to facilitate communication.

Optionally, instructions or requests can be sent to patient care devices 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148, for example, bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile to infusion pump 7, syringe The monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to transmit to the pump 126 and / or the microinfusion pump 130. In some embodiments, instructions or requests such as, for example, pill dispensing instructions for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria may be sent to pill dispenser 128.
One or more of the monitoring clients 1, 4, 11 can be used to transmit to The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval, for example, a particular drug is taken as needed (ie, when needed), but overdose The drug may not be safe if it is done, and the maximum pill dispensing standard can prevent the drug from being taken by the patient at an unsafe level, eg, in a predetermined amount during a predetermined time interval .

Optionally, patient care devices 7, 14, 15, 16, 17, 35, 126, 128
, 130, 148 also determine whether an alarm or alert should be issued or transmitted, determine whether the treatment or condition is safe for the patient, system 50
Monitor data to determine if 0 is operating properly or at predetermined boundaries and / or display data on the display of the monitoring client 1, other monitoring clients 4 and / or remote communicator 11 A reply can be sent to the client 1, another monitoring client 4, and / or the remote communicator 11. For example, optionally, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may provide an upstream pressure, a change in upstream pressure, a downstream pressure for patient 2, a downstream pressure for patient 2. Change, presence or absence of air in the infusion line, actual bolus delivered, actual infusion flow, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual The delivery flow profile can be communicated (if applicable) to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 optionally includes, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or the maximum pill dispensing criteria has been exceeded. Data such as
Monitoring client 1, other monitoring client 4, and / or remote communicator 11
Can reply to.

Patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 14
The data received from 8 can be analyzed for any given condition to raise an alarm and / or alarm. For example, one or more of the monitoring clients 1, 4, 11 are one indication of excessive coagulation, penetration, occlusion or bending of tubing to the patient, or occlusion by other materials in the intravenous bag 170. Increases in pressure downstream of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 can be used. In response to the rapid increase in downstream pressure, the monitoring clients 1, 4, 11
One or more of these can visually or audibly warn or alert the user. In addition, or alternatively, a sudden drop in downstream pressure on the patient 2 is an indication that the tubing has been removed from the needle and / or that the needle is now removed from the patient, and accordingly, One or more of the monitoring clients 1, 4, 11, can alert or alert the user visually or audibly. One or more of the monitoring clients 1, 4, 11 are optionally in response to a sudden increase and / or decrease in downstream pressure on the patient 2,
Instructions can be sent to one or more of infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery.

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

In addition, in some embodiments, some items, components, devices, patients, as numbered or unnumbered, as shown in FIG. 5 or as described herein. Although care devices, docks, and computing devices are shown as the only items, components, devices, patient-care devices, docks or computing devices, many items, components, devices, patient-care devices, docks and computing devices are Conceivable. For example, a single infusion pump 7 is shown in FIG. 5, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or Any arbitrary number of infusion pumps 7 can be used. Additionally or alternatively, in some embodiments, multiple docks 5
02 can be used.

In addition or alternatively, certain patient-care devices 7, 14, 15, 16, 1
Although 7, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. For example,
In some embodiments, only infusion pump 7 of the patient-care device is used,
In this particular embodiment, other patient-care devices 14, 15, 16, 17, 126, 128
, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 500 of FIG. In addition or alternatively, in some specific embodiments, only the patient-care device that is used can be docked to the dock 502. For example, in certain embodiments, infusion pump 7 is the only device docked within device dock 102 and only device dock 102 receives one device, eg, infusion pump 7. In addition, alternatively or optionally, in some specific embodiments, patient care devices 7, 14, 1
5, 16, 17, 35, 126, 128, 130, 148 can be docked, can be operated without docking, and / or can be operated as a stand-alone patient-care device without being dockable.

In FIG. 5, the dock 502 is shown as being capable of receiving several patient-care devices, but in other embodiments, the dock 502 is a single patient-care device, multiple patient-care devices, Or any number of patient-care devices can be received. Also, the dock compartment may not be used, for example, an empty compartment 170 is shown in the dock 502 as shown in FIG. In addition, although the dock 502 is shown as being capable of receiving one monitoring client 1, in other embodiments, the dock 502 includes two monitoring clients 1, three or more monitoring clients 1. , Or any arbitrary number of monitoring clients 1 can be received.

FIG. 6 illustrates a monitoring client, eg, the monitoring client 1 of FIG. 5, and one or more patient-care devices, eg, patient-care devices 7, 14, 15 of FIG. 5, according to an embodiment of the present disclosure.
16, 16, 17, 35, 126, 128, 130, 148, is a flowchart diagram illustrating a method 304 for maintaining communication between one or more.

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

Act 308 determines whether the dock is available as a communication link between the monitoring client and the dock over 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.

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

Act 314 attempts a handshake between the monitoring client and the device using the available communication link (s). In alternative embodiments, handshaking is not utilized, eg, some protocols do not utilize handshaking. Decision action 3
18 determines whether the handshake was successful, and if successful, the method 304 proceeds to operation 320 to communicate data using the available communication link (s). If the decision operation 318 determines that the handshake was not successful at the operation 314, the operation 316 determines that communication with the device is not available. In other embodiments, if the decision operation 318 determines that the handshake was not successful at the operation 314, the method 30
4 attempts to communicate with the patient-care device via an unverified communication link (not explicitly shown).

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, the method 304 includes a schedule for the communication link, but other schedules can be used, broadcast, anycast, multicast or unicast can be used, and a routing algorithm is used. Can use distance vector routing protocol, can use link state routing protocol, can use optimized link state routing protocol, can use path vector
Protocols can be used, static routing with a predetermined alternative communication path can be used, and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, weight can be assigned to each communication path and Dijkstr
can communicate between the monitoring client 1 and one or more patient-care devices using the algorithm of a, can determine the weight in any known manner, bandwidth, signal quality, bit Inclusion as a function of error rate may be linear with available data throughput or latency and / or the like.

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

Optionally, instructions or requests can be sent to patient care devices 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148, for example, bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile to infusion pump 7, syringe The monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to transmit to the pump 126 and / or the microinfusion pump 130. In some embodiments, instructions or requests such as, for example, pill dispensing instructions for dispensing pills, pill types, pill dispensing schedules, and / or maximum pill dispensing criteria may be sent to pill dispenser 128.
One or more of the monitoring clients 1, 4, 11 can be used to transmit to The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval, for example, a particular drug is taken as needed (ie, when needed), but overdose The drug may not be safe if it is done, and the maximum pill dispensing standard can prevent the drug from being taken by the patient at an unsafe level, eg, in a predetermined amount during a predetermined time interval .

  Optionally, the patient care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 also determines whether a treatment or condition should be issued or transmitted to the patient or treatment On the display of monitoring client 1, other monitoring clients 4 and / or remote communicator 11, and determining whether system 700 is operating properly or at predetermined boundaries. The data can be sent back to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 to display the data. For example, optionally, infusion pump 7, syringe pump 126, and / or microinfusion pump 130 may provide an upstream pressure, a change in upstream pressure, a downstream pressure for patient 2, a downstream pressure for patient 2. Change, presence or absence of air in the infusion line, actual bolus delivered, actual infusion flow, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual The delivery flow profile can be communicated (if applicable) to one or more of the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 optionally includes, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or the maximum pill dispensing criteria has been exceeded. Can be returned to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11.

Patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 14
The data received from 8 can be analyzed for any given condition to raise an alarm and / or alarm. For example, one or more of the monitoring clients 1, 4, 11 are one indication of excessive coagulation, penetration, occlusion or bending of tubing to the patient, or occlusion by other materials in the intravenous bag 170. Increases in pressure downstream of the infusion pump 7, syringe pump 126 and / or microinfusion pump 130 can be used. In response to the rapid increase in downstream pressure, the monitoring clients 1, 4, 11
One or more of these can visually or audibly warn or alert the user. In addition, or alternatively, a sudden drop in downstream pressure on the patient 2 is an indication that the tubing has been removed from the needle and / or that the needle is now removed from the patient, and accordingly, One or more of the monitoring clients 1, 4, 11, can alert or alert the user visually or audibly. One or more of the monitoring clients 1, 4, 11 are optionally depending on whether the downstream pressure suddenly increases and / or decreases for the patient 2,
Instructions can be sent to one or more of infusion pump 7, syringe pump 126, and / or microinfusion pump 130 to stop fluid delivery.

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

In addition, in some embodiments, a number of items, components, devices, patients, numbered or unnumbered, as shown in FIG. 7 or described herein. Although care devices, docks, and computing devices are shown as the only items, components, devices, patient-care devices, docks or computing devices, many items, components, devices, patient-care devices, docks and computing devices are Conceivable. For example, a single infusion pump 7 is shown in FIG. 7, but in some embodiments, two infusion pumps 7 can be used, multiple infusion pumps 7 can be used, or Any arbitrary number of infusion pumps 7 can be used. In addition or as an alternative, in some embodiments, the integrated dock 7
02 can be used.

In addition or alternatively, certain patient-care devices 7, 14, 15, 16, 1
Although 7, 126, 128, 130, 148 are shown, other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. For example,
In some embodiments, only infusion pump 7 of the patient-care device is used,
In this particular embodiment, other patient-care devices 14, 15, 16, 17, 126, 128
, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 700 of FIG. In addition or alternatively, in some specific embodiments, only the patient-care device that is used can be docked to the integrated dock 702. For example, in certain embodiments, the infusion pump 7 is the only device docked in the integrated dock 702 and the integrated dock 7
Only 02 receives one device, for example the infusion pump 7. In addition, as an alternative,
Or optionally, in some particular embodiments, patient-care devices 7, 14, 15
16, 17, 35, 126, 128, 130, 148 can be docked, can be operated without docking, and / or can be operated as a stand-alone patient-care device.

In FIG. 7, the integrated dock 702 is shown as being capable of receiving several patient-care devices, but in other embodiments, the integrated dock 702 is a single patient-care device, multiple A patient-care device, or any number of patient-care devices can be received. Also, the dock compartment may not be used, for example, an empty compartment 170 is shown in the integrated dock 702, as shown in FIG. In addition, although the integrated dock 702 is shown as being capable of receiving one integrated monitoring client 1, in other embodiments, the integrated dock 702 has two integrated monitoring clients 1.
Three or more integrated monitoring clients 1 or any arbitrary number of integrated monitoring clients 1 can be received.

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 is
A communication interface is provided between the monitoring client dock 102 and the device docks 804, 806. In yet additional embodiments, the hub 802 includes the monitoring client 1,
The patient care device is controlled without other monitoring clients 4 and / or remote communicators 11. For example, the hub 802 may include the monitoring server 3, equipment service 8, nurse station 5, pharmacy 6, cloud server 25, online drug database or adverse drug event network 9, patient personal EHR 19 ′, and / or treatment result database 10. Can communicate with. Hub 802 is responsible for all devices connected to it (
For example, patient care device, monitoring client, remote communicator, etc.)
The clock can be provided such that the real-time device uses the hub 802 clock, or the time critical device uses the hub 802 clock.

In some embodiments, a GPS and / or ranging module (eg, an ultrasonic ranging module) can be installed on the infusion pump 830, the monitoring client 1, the hub 802, the caregiver, and / or the patient. . The predetermined setting is that infusion pump 830, monitoring client 1, hub 802, caregiver, and / or a predetermined group of patients, in this particular embodiment, before initiating therapy and / or infusion pump 830, Before configuring the hub 802 and / or one of the monitoring clients 1, it may be necessary to have a predetermined distance relative to each other.

In some embodiments, the hub 802 includes an application programming interface (API) to display GUIs, windows, data, etc. on the monitoring client 1 and / or the remote communicator 11. The API can include a secure data class. In yet additional embodiments, the docks 102, 804,
And / or 806 on the monitoring client 1 or the remote communicator 11
Contains APIs for displaying UI, windows, data, etc. In yet additional embodiments, the dock 102, 804, or 806, or the hub 802 may be the patient care device 8.
An API is included to display GUIs, windows, data, etc. on 30, 810, and / or 814.

In some embodiments, hub 802 and / or docks 102, 804, and / or
Or 806 is the associated patient-care device (the device paired there,
Identifying the type of patient-care device associated therewith and loading the configuration data based on the type of hub 802 and / or devices 102 804, and / or 806) Can do.

In some embodiments, hub 802 and / or docks 102, 804, and / or
Or 806 identifies the type of patient-care device associated therewith,
A UI can be configured using CSS, JavaScript, or the like. In some embodiments, hub 802 and / or dock 102, 804, and / or 806
Can have a distributed UI system.

The user interface described herein can utilize a request action framework.

Optionally, in some specific embodiments, the hub 802 includes all of the safety critical circuitry and software for communicating with the monitoring client 1. For example, in this particular embodiment, the hub 802 receives treatment parameters from the monitoring client 1 and the hub 802 may determine that the treatment parameters are patient independent of any safety checks performed somewhere on the monitoring client 1, for example. 2 is guaranteed to be safe. In yet a further specific embodiment, the system 800 is optionally fully fault tolerant of the monitoring client 1, for example, independent safety checks performed within a predetermined criteria, such as an infusion pump 7. If the prescribed safe range of drug delivery is not met,
There is a possibility that instructions, requests, or parameters from the monitoring client 1 are ignored.

Optionally, in yet additional specific embodiments, a barcode attached to intravenous bag 170 can be scanned by scanner 120 to download a predetermined prescription (eg, from a patient's personal EHR 19 ′). And / or infusion pump 830 includes a predetermined prescription that is uploaded to hub 802 when docked to dock 804. Thereafter, in this particular embodiment, and optionally, the hub 802
Starts infusing intravenous bag 170 into patient 2 and monitors the progress of treatment to ensure patient 2 safety. In addition, alternatively or optionally, in this particular embodiment, the caregiver can interact with system 800 as shown in FIG. 8 via hub 802 alone. Optionally, in some embodiments, the hub 802 uploads treatment, status, or patient information to the monitoring client 1. For example, the hub 802 may receive treatment information received from the infusion pump 830 or scan on the intravenous bag 170 to display to the user for confirmation by the user, for storage in the monitoring client 1, etc. The treatment information received from the patient's personal EHR 19 ′ corresponding to the received barcode can be uploaded to the monitoring client 1.

In some embodiments, device dock 804 receives infusion pumps 830, 810, and 812. In some embodiments, device dock 804 is a single 2
Receive one or more or multiple patient-care devices. Device dock 806 receives pill dispenser 814. In some embodiments, device dock 806 receives one, more than one, or multiple patient-care devices, such as pill dispenser 806. The device dock 804 includes an antenna 816 for wireless communication, and the device dock 806 includes an antenna 818 for wireless communication. Similarly, the hub 802 includes an antenna 820 for wireless communication. Additionally or alternatively, device dock 804, hub 802, and / or monitoring client 1 communicate with each other using a wired connection. Hub 802 and docks 804 and 806 are each a U
SB cables can be used to communicate with each other using Ethernet cables and / or via wireless links. Optionally, the hub 802 can include additional accessories such as a display 822, a camera 824, a microphone 826, a scanner 120, a removable display (not shown). As previously described, the hub 802 can provide all patient safety critical functions and can operate independently of the monitoring client 1 and / or the monitoring client dock 102.

Optionally, instructions or requests can be sent to patient care devices 14, 15, 16, 17, 3
5,830, 810, 812, 814, 830, 148 infusion pump for example bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile The monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 can be used to transmit to one or more of 830, 810, 812. In some embodiments, monitoring to send instructions or requests to the pill dispenser 814, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria. One or more of the clients 1, 4, 11 can be used. The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval, for example, a particular drug is taken as needed (ie, when needed), but overdose The drug may not be safe if it is done, and the maximum pill dispensing standard can prevent the drug from being taken by the patient at an unsafe level, eg, in a predetermined amount during a predetermined time interval .

Optionally, patient care devices 14, 15, 16, 17, 35, 830, 810, 8
12, 814, 830, 148 also determine whether an alarm or alert should be issued or transmitted, determine whether the treatment or condition is safe for the patient,
Determine whether the system 800 is operating properly or at a predetermined boundary, and / or monitoring client 1, other monitoring clients 4 and / or remote communicator 1
Data can be sent back to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11 to display the data on one display. For example, optionally, one or more of the infusion pumps 830, 810, 812 may have an upstream pressure, a change in upstream pressure, a downstream pressure for patient 2, a change in downstream pressure for patient 2, a change in the infusion line Monitor for air presence, actual bolus delivered, actual infusion flow, actual total fluid delivered, actual start time of drug delivery, actual stop time of drug delivery, or actual delivery flow profile Communicate to one or more of client 1, other monitoring clients 4, and / or remote communicator 11 (if applicable). In another embodiment, the pill dispenser 814 optionally includes, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or the maximum pill dispensing criteria has been exceeded. Can be returned to the monitoring client 1, other monitoring clients 4, and / or the remote communicator 11.

Patient care devices 14, 15, 16, 17, 35, 830, 810, 812, 814,
The data received from 830, 148 can be analyzed for any given condition in order to generate an alarm and / or alert. For example, the monitoring clients 1, 4, 1
One or more of the infusion pumps 830, one of which is one indication of excessive coagulation, infiltration, occlusion or bending of tubing to the patient, or occlusion by other materials in the intravenous bag 170,
One or more downstream pressure increases at 810, 812 can be used. In response to the rapid increase in downstream pressure, one or more of the monitoring clients 1, 4, 11, can alert or alarm the user visually or audibly. In addition or alternatively, a sudden drop in downstream pressure on the patient 2 is an indication that the tubing has been removed from the needle and / or that the needle is now removed from the patient, and is monitored accordingly. Client 1, 4,
One or more of 11 can alert or alarm the user visually or audibly. One or more of the monitoring clients 1, 4, 11 may optionally be infused pumps 830, 810, to stop delivery of fluid in response to a sudden increase and / or decrease in downstream pressure on the patient 2. An indication can be sent to one or more of 812.

In some embodiments, each item, component, device, patient-care device, dock, and numbered or unnumbered as shown in FIG. 8 or as described herein, The computing device is optional. For example, in some embodiments, the monitoring client 1 is optional, the monitoring server 3 is optional, the facility service 8 is optional, and each service 19, 20, 21, 22, 23, 24 is Optional, the cloud server 25 is optional, the other monitoring clients 4 are optional, the online drug database 9 is optional, the adverse drug event network is optional, and the patient's personal EHR 19 ′ is optional and / or
Alternatively, the treatment result database 10 is optional. In addition or as an alternative,
In some embodiments, each patient-care device 830, 810, 812 is optional. Similarly, the system monitor 131, wrist band 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power source, respectively,
Optional in some embodiments of the present disclosure.

In addition, in some embodiments, some items, components, devices, patients, as numbered or unnumbered, as shown in FIG. 8 or as described herein. Although care devices, docks, and computing devices are shown as the only items, components, devices, patient-care devices, docks or computing devices, many items, components, devices, patient-care devices, docks and computing devices are Conceivable. For example, although a single pill dispenser 814 is shown in FIG. 8, in some embodiments, two pill dispensers 814 can be used, multiple pill dispensers 814 can be used, or Any arbitrary number of pill dispensers 814 can be used. In addition or alternatively, in some embodiments, multiple docks 804 or 806 and / or multiple monitoring client docks 102 can be used.

Additionally or alternatively, specific patient-care devices 830, 810, 812 are shown, but other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. . For example, in some embodiments, only infusion pump 830 of the patient-care device is used, and in this particular example, the system is used to disable other patient-care devices 810, 812, 814. Present or unavailable, may be powered down or not part of the system 800 of FIG.
Additionally or alternatively, in some specific embodiments, only the patient-care device that is used can be docked to the dock 804 or 806. For example, in one particular embodiment, infusion pump 830 is the only device docked in dock 804 and only dock 804 receives one device, eg, infusion pump 830.

In FIG. 8, the dock 804 is shown as being capable of receiving several patient-care devices, but in other embodiments, the device dock 804 is a single patient-care device, multiple patient-care devices. The device or any number of patient-care devices can be received. Also, the dock compartment may not be used (not shown in FIG. 8).
In addition, although the monitoring client dock 102 is shown as being capable of receiving one monitoring client 1, in other embodiments, the monitoring client dock 1
02 can receive two monitoring clients 1, three or more monitoring clients 1, or any arbitrary number of monitoring clients 1. In addition, alternatively or optionally, in some specific embodiments, patient care devices 14, 15, 16, 1
7, 35, 830, 810, 812, 814 can be docked, can be operated without docking, and / or can be operated as a stand-alone patient-care device that is not dockable.

The system 800 of FIG. 8 can use any known communication method for maintaining communication with it. For example, in some embodiments, any communication schedule can be used, broadcast, anycast, multicast or unicast can be used, a routing algorithm can be used, and distance vector routing can be used. Protocol can be used, link state routing protocol can be used, optimized link state routing protocol can be used, path vector protocol can be used, given alternatives Static routing in the communication path can be used and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, weight can be assigned to each communication path and the Dijkstra algorithm is used to monitor client 1 or hub 8.
02 and one or more patient-care devices (eg, patient-care devices 830, 810,
812, and 814), weight can be determined in any known manner, including as a function of bandwidth, signal quality, bit error rate, It may be linear with respect to throughput or latency, and / or others.

In an embodiment of the present disclosure, the facility service 8 and / or the adverse drug event network 9 may also include a drug 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. The soft alarm may cause 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 the hard alarm interrupts treatment until the cause of the hard alarm is removed. It can be used and disabled (eg, stopped) by the caregiver (and may be only an audible and / or vibration alarm).

In yet additional embodiments of the present disclosure, the DERS system may include a first set of predetermined criteria defining soft limits and / or a second set of predetermined criteria defining hard limits. it can. Hard and soft limits define treatment limits, such as drug dosage, based on dimensions, weight, age, other patient parameters, or other criteria. The soft limit prevents the treatment from starting until the setting is changed to meet a second set of predetermined criteria that define the hard limit,
A user interface of infusion pump 830, a user interface of monitoring client 1, and / or a user interface of hub 802 to initiate therapy, even though the therapy is outside the first set of predetermined criteria 808 can be used to be overridden by the caregiver.

In some embodiments, patient care devices 830, 810, 812, 814, 14,
15, 16, 17, 35 and / or 148, monitoring client 1, remote communicator 11, and dock 102 and / or 804, and / or hub 802 may include a secure data class, eg, via an API. Can do.

Referring again to the drawings, FIG. 9 illustrates a stackable monitoring client 902, a stackable infusion pump 904, a stackable syringe, according to yet another embodiment of the present disclosure.
FIG. 6 shows a block diagram of an electronic patient care system 900 having a pump 906 and another stackable patient care device 908. Stackable devices 902-908 are:
The backplane and / or bus can be used to communicate (in some embodiments, the stackable devices 902-908 communicate via a communication module).

Optionally, instructions or requests can be sent to patient care devices 14, 15, 16, 17, 3
5, 128, 904, 906, 908, 148, for example, a bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile can be stacked Pump 904, stackable syringe pump 906
And / or other stackable patient-care devices 908 can be used to use the monitoring client 902, other monitoring clients 4, and / or the remote communicator 11. In some embodiments, such as, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria, such as:
In order to send instructions or requests to the pill dispenser 128, the monitoring client 9
One or more of 02, 4, 11 can be used. The maximum pill dispensing criteria is the maximum amount of drug that can be delivered within a given time interval, for example, a particular drug is taken as needed (ie, when needed), but overdose The drug may not be safe if it is done, and the maximum pill dispensing standard can prevent the drug from being taken by the patient at an unsafe level, eg, in a predetermined amount during a predetermined time interval .

Optionally, patient care devices 14, 15, 16, 17, 35, 128, 904, 9
06, 908, 148 also determine whether an alarm or alert should be issued or transmitted, determine whether the treatment or condition is safe for the patient, and the system 900 operates appropriately or at predetermined boundaries. To monitor and / or display the data on the display of the monitoring client 902, other monitoring client 4 and / or the remote communicator 11, the monitoring client 902, the other monitoring client 4, and / or Or it can reply to the remote communicator 11. For example, optionally, stackable infusion pump 904, stackable syringe pump 906, and / or other stackable patient-care devices 908 may be configured to provide upstream pressure, upstream pressure change, downstream relative to patient 2. Pressure, change in downstream pressure for patient 2, presence or absence of air in infusion line, actual bolus delivered, actual infusion flow, actual total fluid delivered, actual start time of drug delivery, drug delivery The actual stop time or actual delivery flow profile can be communicated (if applicable) to one or more of the monitoring client 902, other monitoring clients 4, and / or the remote communicator 11. In another embodiment, the pill dispenser 128 optionally includes, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or the maximum pill dispensing criteria has been exceeded. Can be sent back to the stackable monitoring client 902, other monitoring clients 4, and / or the remote communicator 11.

Patient care devices 14, 15, 16, 17, 35, 128, 904, 906, 908,
The data received from 148 can be analyzed for any given condition to raise an alarm and / or alarm. For example, one or more of the monitoring clients 902, 4, 11 is one indication of excessive coagulation, infiltration, occlusion or bending of tubing to the patient, or occlusion by other materials in the intravenous bag 170. An increase in pressure downstream of the stackable infusion pump 904 and / or the stackable syringe pump 906 can be used. In response to the rapid increase in downstream pressure, the monitoring clients 902, 4,
One or more of 11 can alert or alarm the user visually or audibly. In addition or alternatively, a sudden drop in downstream pressure on the patient 2 is an indication that the tubing has been removed from the needle and / or that the needle is now removed from the patient, and is monitored accordingly. One or more of the clients 902, 4, 11 can alert or alert the user visually or audibly. One or more of the monitoring clients 902, 4, 11 are optionally stacked infusion pumps 904 to stop delivery of fluid in response to a sudden increase and / or decrease in downstream pressure on the patient 2. Instructions can be sent to one or more of the stackable syringe pumps 906 and / or.

Stackable monitoring client 902, stackable device 908, stackable infusion pump 904, and stackable syringe pump 906 are daisy chained together through connectors coupled to the top and bottom of each device. be able to. For example, instead of using a stackable syringe pump 906, the monitoring client 9
02 can be stacked on top of it, so that it can be stacked 9
The bottom connector at 06 is electrically coupled to the connector at the top of the monitoring client 902.

A daisy chain can be created, for example, through electrical conductors in each of the stackable monitoring client 902, the stackable patient-care device 908, the stackable infusion pump 904, and the stackable syringe pump 906, thereby Continuous electrical contact is maintained between each of these devices.

Additionally or alternatively, stackable devices 902, 908, 904,
906 can optionally maintain wireless communication with each other. For example, the stackable monitoring client 902 is electrically non-responsive due to an internal short circuit in one of the stackable devices 902, 908, 904, 906 in which daisy chained conductors can be stacked. The stackable monitoring client 902 can detect each stackable device 9 to determine which device has failed.
08, 904, and 906 can be inquired. After making the decision, the stackable monitoring client 902 can stack the devices 902, 908, 904, 906 to electrically disengage the failed device from the daisy chained conductors.
Wireless communication with a disconnect circuit isolated within the failed device. In addition or alternatively, one or more of the stackable devices 902, 908, 904, 906 is one of the stackable devices 902, 908, 904, 906 has failed and / or is stackable. Warning that one of the devices 902, 908, 904, 906 communicates wirelessly rather than via a daisy chained wired communication link, sending an alarm, and / or displaying a message it can.

Additionally or alternatively, a stackable monitoring client 902, a stackable device 908, a stackable infusion pump 904, and a stackable syringe pump 906, respectively, are respectively below or above the daisy chain. Can relay or retransmit information to other devices. For example, a stackable infusion pump 9
04 is a patient care device 9 that can buffer and stack data in internal memory.
All data received from stackable syringe pump 906 is communicated by communicating information when 08 receives a signal from stackable patient care device 908 indicating that it is ready to receive additional data. Can communicate. In some embodiments, each item, component, device, patient-care device, dock, and numbered or unnumbered as shown in FIG. 8 or as described herein, The computing device is optional. For example, in some embodiments, the monitoring client 1 is optional, the monitoring server 3 is optional, the facility service 8 is optional, and each service 19, 20, 21, 22, 23, 24 is Optional, the cloud server 25 is optional, and the other monitoring clients 4 are optional,
The online drug database 9 is optional, the adverse drug event network is optional, the patient's personal EHR 19 ′ is optional, and / or the treatment outcome database 10 is optional. Additionally or alternatively, in some embodiments, each patient care device 830, 810, 812 is optional. Similarly, the system monitor 131, wrist band 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power source are each optional in some embodiments of the present disclosure.

In addition, in some embodiments, some items, components, devices, patients, as numbered or unnumbered, as shown in FIG. 9 or as described herein. Although care devices and computing devices are shown as the only items, components, devices, patient-care devices, or computing devices,
Numerous items, components, devices, patient care devices, and computing devices are contemplated. For example, a single pill dispenser 128 is shown in FIG. 9, but in some embodiments, two pill dispensers 128 can be used, multiple pill dispensers 128 can be used, or Any arbitrary number of pill dispensers 128 can be used.

In addition, or alternatively, specific patient-care devices 904, 906, 908 are shown, but other combinations, subsets, multiples, or combinations of specific patient-care devices may be used. . For example, in some embodiments, only stackable infusion pumps 904 of patient care devices are used, and in this particular example, for other system devices that disable other patient devices 906, 908. Present or unavailable, may be powered down or not part of the system 900 of FIG. In addition, or alternatively, in some specific embodiments, only the patient-care devices that are used are stacked. For example, in one particular embodiment, infusion pump 904 is the only device stacked. In addition, or alternatively, non-stacked patient-care devices, such as patient-care devices 904, 906, and / or 908, can continue to operate when operating as stand-alone devices. In addition, alternatively or optionally, in some specific embodiments, the patient-care device 14, 15, 16, 17, 35, 904, 906, 908, 128, 148 is dockable, docking Can be operated without, and / or not dockable and can operate as a stand-alone patient-care device.

In FIG. 9, the stack is shown as being capable of stacking several patient-care devices, but in other embodiments the stack is one patient-care device, multiple patient-care devices, or any arbitrary Can receive a number of patient-care devices. In addition, although the stack is shown as being capable of receiving one monitoring client 902, in other embodiments, two stackable monitoring clients 902, three or more stackable monitoring clients 902, or any arbitrary number of stackable monitoring clients 902, are stacked in system 900.

The system 900 of FIG. 9 can use any known communication method for maintaining communication with it. For example, in some embodiments, any communication schedule can be used, broadcast, anycast, multicast or unicast can be used, a routing algorithm can be used, and distance vector routing can be used. Protocol can be used, link state routing protocol can be used, optimized link state routing protocol can be used, path vector protocol can be used, given alternatives Static routing in the communication path can be used and / or an adaptive network can be used. For example, in some embodiments of the present disclosure, weight can be assigned to each communication path and Dijkstra's algorithm is used to monitor client 902 and one or more patient-care devices (eg, patient-care device 904, 906, 908) and can determine weight in any known manner, including as a function of bandwidth, signal quality, bit error rate, available data throughput Or it may be linear with respect to latency and / or others.

Referring to FIGS. 1, 3, 5, 7, 8, and 9, various update technologies and / or techniques may be utilized to generate hubs, docks, devices, insulin pumps, infusion pumps, and / or
Or the patient-care device can be updated. For example, a patient-care device may be a computing device (in some embodiments, a personal computer, or a personal computer, for example, with a bus converter that converts RS232 format data, eg, I2C format data, in some embodiments. It can be coupled to any device that can be used in a manner similar to a computer, such as but not limited to a tablet. A processor in a hub, dock, device, insulin pump, infusion pump, and / or patient-care device, in some embodiments, for example, software in flash memory by a supervisor processor and / or command processor. Updates can be executed to control or organize downloading. In some embodiments, the computing device is a hub, dock, device, insulin pump, infusion pump, and / or patient care device flash device.
Downloading software into memory can be organized. Software updates obtained by the computing device can be sent in flash memory (not shown) accessible by the supervisor processor and / or the command processor. The software update may, in some embodiments, be a command line program that can be automatically invoked by a script process.

In some embodiments, the hub, dock, device, insulin pump, infusion pump, and / or patient-care device can be, but is not limited to, through a web-based secure portal and / or through email. A web connection that may include, but is not limited to, the ability to download applications, download software updates, upload information, and / or send information to various machines, and / or via wireless communication protocols It may be or have the capability of a remote interface. Thus, in various embodiments, the remote interface application can run on any functional device and is not limited to so-called dedicated devices. Further, in some embodiments, the remote interface may be, but is not limited to, a hub, dock, device, insulin pump, infusion pump, patient-care device, Bluetooth or other communication device, patient-care device, and / or Bluetooth can be enabled to communicate with one or more devices, which can include one or more of any other devices, eg, using radio frequency (RF) communication, or others Can be made possible by

In some embodiments, the charging station can include a charging area of a 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,
Mini USB ports can be included, and in some embodiments for receiving power to charge hubs, docks, devices, insulin pumps, infusion pumps, patient care devices, and / or remote interfaces via USB A charging station can be enabled. In addition and / or alternatively, the USB port may be connected to a computer or other device, and / or computer type device, via a remote interface, and / or a hub, dock, device, insulin pump, infusion pump And / or for data transfer to / from the patient-care device. In embodiments that include a USB port, the system can call a personal computer and / or web portal to check for updated software while the remote interface is charged, and there is update software available. In this case, for example, the software update can be downloaded via a USB connection. These updates can then be transferred to the hub, dock, device, insulin pump, infusion pump, and / or patient-care device during pairing.

Therefore, users can use hubs, docks, devices, insulin pumps, infusion pumps,
And / or the patient care device's remote interface can be connected to a personal computer, and / or in some embodiments, data can be uploaded from the remote interface to a web portal or the like. In some embodiments, this is a personal interface that can synchronize and / or upload / download data from a personal computer, 1908 and / or web portal in addition to remote interface charging / recharging.・ USB to computer
The connection can be used to achieve during “recharging” of the remote interface, which can be done in some embodiments. At this time, the system can determine if a software update for one or more of the devices and / or the remote interface is available. The user can select “update downloads”, which are also available at the time of charging and / or the web interface specified for the personal computer and / or system specifically for the remote interface either directly or indirectly. At any time connected to the portal, it can be downloaded to the remote interface of the hub, dock, device, insulin pump, infusion pump, and / or patient-care device.
As discussed above, the remote interface can communicate with various devices. Thus, the software update can be communicated to any one or more devices of the remote interface. But not limited to data from all devices
A personal computer / web portal with a remote interface for both uploading information and / or downloading updates and / or applications to any of the devices from a personal computer and / or from an internet / web portal It has many advantages including only connecting to.
This includes, but is not limited to, the ability to efficiently and easily update all devices from one connection and / or the ability to see all of the data from all devices at one location, and It may be desirable for a number of reasons, including the ability to download information and / or settings from a personal computer / web portal to any of the devices via a remote interface.

Thus, in some embodiments, a personal computer / web portal includes all information from all devices including, but not limited to, a remote interface, so a new “remote interface” is always introduced into the system. can do. This can be accomplished by connecting a 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 that the old remote interface be first removed from the “authentication device”, while in other embodiments the system “allows” additional remote interfaces with permission from the user. Can do. Thus, the system can communicate all information and applications to any internet connection and / or remote interface that can communicate with the device and / or connect a personal computer and / or web portal. Includes the ability to download.

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 connect any device (including some parameters such as the ability to wirelessly communicate and connect to a personal computer and / or web portal) to various devices, such as infusion pumps. Control and / or CG
Receive data from M 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, and / or These can be turned into devices that can be controlled. In some embodiments, the remote interface and / or one or more applications on the remote interface can be protected with a password or other and can be paired with one or more devices, eg,
Paired with an infusion pump and / or CGM sensor and / or one or more other devices.

In some embodiments, information on the remote interface, including but not limited to uploading data to an Internet site (web portal) that can be password protected, uploaded and / or otherwise Devices and / or computers and / or machines. Therefore, the user
Information can be accessed from any device and / or information can be downloaded to any device, including any device specific application,
Therefore, although not limited to this, user information including information such as history and preferable settings can be downloaded to any device.

FIG. 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. The method 600 is an operation 602.
˜608. The patient-care device of the method 600 is optionally any patient-care device disclosed herein, for example, the patient-care device 7, 1 of FIGS.
4, 15, 16, 17, 35, 126, 128, 130, 148, patient-care device 14, 15, 16, 17, 830, 810, 812, 814 in FIG. 8, patient-care device 14, 15, in FIG. 16, 17, 904, 906, 908, or other patient care devices disclosed herein.

Act 602 establishes a communication link between the patient-care device and the monitoring server. Action 60
4 communicates patient care parameters to a monitoring server, for example, over a local area network and / or the Internet, over WiFi, through a monitoring client, one or more hubs, a dock, or the like. Act 606 de-identifies the patient care parameter. The operation 606 is performed by the monitoring server 3 shown in FIGS.
Can be done automatically and electronically. For example, the patient's name can be removed and replaced with a random serial number or other indicator that cannot be used to determine patient identification information in the monitoring server. Act 608 stores the unidentified patient care parameters in a database, eg, a monitoring server such as an SQL database, a relational database, an associative database, a cloud server, or the like.

FIG. 11 is a flowchart diagram of a method 701 for collecting patient care parameters from multiple patients as determined from a patient care device within a monitoring server, according to an embodiment of the present disclosure. Method 701 includes acts 703-713. In some embodiments, operation 70.
3 to 713 are all optional. The patient-care device may be any patient-care device disclosed herein, for example, the patient-care device 7, 14, 15 of FIGS.
16, 17, 35, 126, 128, 130, 148, patient care device 14, FIG.
15, 16, 17, 830, 810, 812, 814, patient care device 14, 1 of FIG.
5, 16, 17, 904, 906, 908, or other patient care devices disclosed herein.

Act 703 establishes a communication link between the monitoring server, eg, the monitoring server 3 of FIGS. 1, 3, 5, 7, 8, or 9, and a plurality of patient-care devices associated with the plurality of 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.

Act 705 communicates the plurality of patient-care parameters from the plurality of patient-care devices to the monitoring server. Act 707 de-identifies the patient-care parameters and act 709 stores these patient-care parameters in a monitoring server, eg, a database such as an SQL database, a relational database, an associative database. Operation 707 can be performed automatically and / or electronically. Act 711 treats a subset of patients of the plurality of patients. For example, hypertensive patients can be treated with drugs designated to lower blood pressure. Act 713 analyzes a subset of the plurality of patient care parameters associated with the plurality of patients to determine the effectiveness of the treatment. For example, all patients who have received a blood pressure medication in action 711 will have a blood pressure reading at a predetermined time, eg, 6 months, to determine if the treatment is effective for one or more patients. Can have a blood pressure compared.

FIG. 12 is a flowchart diagram of a method 801 of patient care device recovery when operation of the patient care device is interrupted according to an embodiment of the present disclosure. For example, the patient-care device may be removed from the dock, power may be interrupted, and a hardware or software failure may temporarily disable one or more processors or other circuits within the patient-care device. Additionally or alternatively, one or more processors on the patient-care device can implement the method 801 so that the patient-care device is hot-swappable.

Method 801 includes acts 803-823. Each operation 803-823 is optional in some embodiments. Act 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, eg, FIG. 1, 3, 5, or 7
Patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 14
8. Patient care device 14, 15, 16, 17, 830, 810, 812, 814 of FIG.
Or one of the patient-care devices 14, 15, 16, 17, 904, 906, 908 of FIG.
There may be one or more.

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

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

Act 811 calculates one or more additional operating parameters for the patient-care device. The calculated operating parameter is any parameter calculated to operate the patient-care device, for example, a gain coefficient of a proportional integral derivative (PID) control loop having an adaptive gain coefficient used in automatic gain control. Act 813 stores one or more additional operating parameters in the non-volatile memory of the patient-care device.

Act 815 determines that the operation of the patient-care device has been interrupted, for example, power has been lost to the patient-care device, a failure has occurred in the patient-care device, a low voltage CPU reset has occurred, and so forth. Act 817 determines that the operation of the patient-care device can resume.

Act 819 loads one or more received or calculated operating parameters in the operating memory of the patient-care device, and operation 821 sets one or more in the operating memory of the patient-care device. Load patient care parameters. Act 823 resumes operation of the patient-care device.

Referring now to FIG. 13, a flowchart diagram of a method 900 for pairing a monitoring client having a user interface with a patient-care device according to an embodiment of the present disclosure is shown. Method 900 includes acts 902-912. The monitoring client of the method 900 is the monitoring client 1 or remote communicator 11 of FIG. 1, 3, 5, 7, or 8, the monitoring client 902 of FIG. 9, the remote of FIG. 1, 3, 5, 7, 8, or 9 It may be a communicator 11, a mobile phone, a handheld computer, a tablet computer, a laptop computer, a personal computer, a portable information terminal, or the like.
Method 900 describes the pairing between the monitoring client and the patient-care device,
In some embodiments, method 900 is used to replace a hub (eg, hub 802 of FIG. 8) with a patient-care device (eg, patient-care devices 830, 810, 812, and 814).
A first patient-care device (eg, patient-care device 830 in FIG. 8)
Is paired with a second patient-care device (eg, patient-care device 814 of FIG. 8)
Thereby, the user interface of the first patient-care device can be used to control the second patient-care device and / or the system monitor (e.g. FIG. 1, 3, 5, 7, 8 or 9 system monitoring 131) for patient care devices (eg,
Patient care devices 7, 170, 126, 128, 1 as shown in FIGS.
48, 14, 15, 16, 17 or 170, or the patient care device 830, 8 of FIG.
10, 812, 814, 14, 15, 16, 17, or 148 and / or the patient-care device 904, 906, 908, 14, 15, 16, 17 or 148 of FIG. 9).

Act 902 positions a monitoring client having a user interface (eg, display, touch screen, display, button, user input accelerometer, etc.) within the operating distance of the patient-care device. Act 904 displays patient care device identification information on the user interface. The patient-care device can be identified, for example, by a visual display on the user input of the patient-care device using a serial number, device type, or standard or custom discovery protocol. Act 906 selects the patient-care device for pairing using the user interface. For example, the user in operation 906 can touch the monitoring client's touch screen to display the patient care device selection.

  Act 908 pairs the patient-care device with the monitoring client. For example, patient care device pairing to a monitoring client can be Bluetooth, Bluetooth Low Energy (IEEE 802.15.1), WiFi, Infrared, Near Field (NFC ISO 13157). IR communication or optics can be used. As will be apparent in light of this disclosure, a custom pairing protocol may be utilized that may or may not utilize handshake sequences. Act 910 communicates patient-care parameters between the patient-care device and the monitoring client, such that the patient-care device can be controlled or monitored by the monitoring client, for example.

Act 912 optionally adds additional patient-care parameters to another patient-care device,
Communicate operatively through the patient-care device. At operation 912, the patient-care device can act as a relay or router if the patient-care device is operatively coupled to or operatively communicates with another patient-care device, whereby the monitoring client is separately Can communicate with other patient-care devices. In addition or alternatively, a patient-care device can use information from another patient-care device for its operation, for example, an infusion pump can determine the flow rate, or temperature, determined by a flow meter The temperature from the probe can be used and / or the infusion pump can relay information from the flow meter to the monitoring client. In addition, the monitoring client can optionally communicate with multiple patient-care devices coupled to paired patient-care devices, either in parallel or in series. In addition or alternatively, in some embodiments of the present disclosure, in method 900, the monitoring client communicates with the patient-care device using a venous tube. Communication is via electrical conductors embedded or attached to the venous tube, using electrical waves using the fluid in the venous tube as a conductive medium, using sound waves traveling through the venous tube, or fluid in the tube May be caused by optical use as a light guide. Using communication via the vein, using another communication link such as Bluetooth, Bluetooth Low Energy, WiFi, etc. (eg, monitoring client, hub, dock, patient-care device and / or monitoring client Pairing can be set up (between a system monitor with one or more of a hub, dock, patient-care device and / or system monitor).

In yet additional embodiments of the present disclosure, a first device (eg, monitoring client, hub, patient-care device, or system monitor) to a second device (eg, monitoring client, hub, patient-care device, or system) The pairing with the monitor can be configured and / or initialized using the first communication link, whereby the device is paired using the second communication link. For example, near field communication or IR
Communication can set up a pairing between devices using, for example, Bluetooth, Bluetooth Low Energy, or WiFi. The pairing setting (for example, via short-range communication or IR communication) is a monitoring client that monitors a user confirmation request of a pairing device, for example, pairing via Bluetooth,
Requests on the hub, patient-care device, and / or system can be commanded. In some embodiments, when a patient-care device is paired to a hub, monitoring client, and / or dock, the ID and software version number are
Sent to the monitoring client and / or dock, and a server, eg, the monitoring server 3,
Check middleware, cloud servers, or other servers to determine if the software on the patient-care device is up-to-date, and if the software is not up-to-date,
The hub, monitoring client, dock, or patient-care device itself (eg, 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 optionally provide the user with an option on the touch screen to update the patient-care device if the software is not up-to-date. Can be given. The communication link that sets up the pairing (e.g. NFC) and / or the communication link that uses the pairing (e.g. Bluetooth or Bluetooth Low Energy) is updated software,
ID, software version number can be communicated and notifications etc. can be provided. For example, one pairing that can be used with a pump patient care device or an insulin pump is (1) filed March 25, 2010, Attorney Docket No. I06, Application No. 12 / 731,843. Mandro et al., “Infusion Pump Methods and Systems (“
INFUSION PUMP METHODS AND SYSTEMS "), (2) filed April 4, 2009, agent serial number G98, application number 12 / 416,662, Bryant et al. Method and system for controlling a pump ("METHODS AND SYSTEMS FOR CONTROLLING"
Patent application entitled "AN INFORMATION PUMP") and / or (3
) Filed December 31, 2009, agent serial number G75, application number 12/347,
985, Kamen et al.'S “Infusion Pump Assembly (“ INFUSION PU
MP ASSEMBLY ")" and can be found in the patent application, the contents of all three documents being incorporated herein by reference.

FIG. 14 is a flowchart diagram of a method 1000 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. Method 1000 includes acts 1014-1040 and utilizes various devices 1002, 1004, 1006, 1008, 1100, 1112 to facilitate pairing of the method 1000 wearable system monitor to a patient-care device. be able to. In some embodiments, each operation 1014-1040 is optional.

The wearable system monitor of method 1000 is shown in FIGS. 1, 3, 5, 7, 8, and 9.
The wearable system monitor 131 may be used. System monitor pairing of the method 1000 for monitoring one or more patient-care devices may be performed by the device 10.
This can be done using any one or more of 02-1012 or using any of the sufficient devices disclosed herein. For example, the user interface of the monitoring device 1002, the user interface of the remote communicator 1004, the user interface of the communication device 1006, the user interface of the patient care device 1008, the user interface of another patient care device 1010, or the wearable Method 1 using the user interface of system monitor 1012
000 wearable system monitors can be paired with a patient-care device.

The patient-care device of the method 1000 is the patient-care device 7 of FIG.
14, 15, 16, 17, 35, 126, 128, 130, 148, patient care device 14, 15, 16, 17, 830, 810, 812, 814 in FIG. 8, patient care device 14, 15, in FIG. Any patient-care device disclosed herein, such as 16, 17, 904, 906, 908, or other patient-care devices disclosed herein.

The system monitor of the method 1000 is connected to the system 100 of FIG. 1, the system 300 of FIG.
The device 500 that can be used in the system 500 of FIG. 5, the system 700 of FIG. 7, the system 800 of FIG. 8, the system 900 of FIG. 9, the stand-alone system, and / or disclosed herein. Can be used in any other sufficient system or group.

Operation 1014 includes a speech recognition algorithm, a face recognition algorithm, a barcode, an RFID
One or more of tags, near field communication, simple login, secure signature, etc. are used to identify the caregiver (eg, provider). For example, caregiver identification in action 1040 is:
This can be done by a surveillance client, surveillance client docking station, device docking station, communication module, other dock, or hub using onboard cameras and / or microphones. Also, as a safety check, the monitoring client, hub, dock, or patient-care device can request that the user enter in a font as displayed to prevent font corruption errors. In addition or alternatively, in some embodiments, if one or more unsuccessful logins or authentications may cause the device to take a picture and store the picture, the picture is sent to the middleware server. May be transmitted for storage. Operation 1
016 records the presence of the caregiver at one or more of devices 1002-1012. Log input includes devices 1002-1012, patient care devices as described herein, monitoring clients as described herein, wearable system monitors as described herein, and as described herein. It can be stored in a remote communicator and / or any one of the hubs described herein. The log of operation 1016 may be for caregiver compliance, diagnostic purposes, and the like. For example, if a caregiver is scheduled to appear but does not appear, operation 1016 can record that the caregiver did not appear at the scheduled time.

The face recognition algorithm at operation 1014 includes relative dimensions, shape, eye position, nose, chin, cheekbones,
Or any caregiver facial feature can be relayed, such as analyzing other facial features. The face recognition algorithm at operation 1014 may use 3D face recognition, skin texture analysis, or other face recognition algorithms. In addition or alternatively, in some embodiments, the speech recognition algorithm of operation 1014 is a hidden Markov model,
Dynamic time warping based speech recognition or other speech recognition algorithm (s) can be used.

Act 1018 removes the wearable system monitor from the wearable dock. For example, the system monitor 131 of FIG. 1 can be worn on the patient's arm so that it can be attached to the patient with a wrist band similar to the wrist band of the watch,
A portion of the wearable system monitor can be removed from a wrist band and a dock with a snap-fit base member to which the wearable system monitor snaps (also referred to herein as a “wearable dock”) Is possible. When the wearable system monitor is removed from its dock, operation 1020 starts a timer. Each timer and associated operation is optional in the method 1000 of FIG.

The timer at operation 1020 maintains a track of the time that the wearable system monitor is outside its dock. Act 1022 stops therapy when a predetermined amount of time has elapsed after the wearable system monitor is undocked from the wearable dock. For example, the wearable system monitor of method 1000 can signal the infusion pump to stop pumping. When the wearable system monitor is docked again, operation 1024 occurs when treatment is interrupted, for example, by detaching the wearable system monitor from the wearable dock after a predetermined amount of time has elapsed. Resume treatment.

As previously described, operation 1018 removes the wearable system monitor from the wearable dock. Act 1026 identifies the patient using one or more of, for example, a voice recognition algorithm, a face recognition algorithm, a barcode, an RFID tag, a near field communication, a simple login, a caregiver input, and the like. Act 1026 may be similar to act 1014, may utilize the same software utilized in act 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 can include more than the identification information of the caregiver, for example, using biometric authentication or other identifying patient-specific information. Such patient identification criteria can be used to ensure that a particular treatment is being given to the correct patient and / or to provide compliance with a given rule. Operations 1014 and / or 1026 may be performed using a passkey device on the patient and / or caregiver.

Act 1028 determines whether the caregiver is authorized to pair the wearable system monitor, eg, pair the wearable system monitor to the patient-care device. If the caregiver is not authorized, then method 1000
Prevents additional pairing (or editing of pairing settings) of the wearable system monitor. If the caregiver is authorized to pair the wearable system monitor, action 1030 selects one or more patient-care devices for the caregiver to pair with the wearable system monitor. Enable. Use caregiver authority, for example, to ensure that a specific treatment is being given to the correct patient, and / or
Or it can provide compliance with a given rule.

The caregiver can be provided with a list of patient care devices available for pairing on one or more user interfaces of the devices 1002-1012. During operation 1030, the caregivers use the wearable system monitor (in order to pair with each other).
For example, select the patient wearable system monitor (operation 1018) and the patient-care device. Act 1032 pairs the wearable system monitor with the patient-care device, and act 1034 records the pairing of act 1032 in the wearable system monitor, including caregiver and patient identification information. In additional specific embodiments, the pairing of the wearable system monitor with the patient-care device is parallel or serial of the patient-care device with another device (eg, monitoring client, hub, another patient-care device, etc.) Can be used for pairing. As will be appreciated in light of this disclosure, any suitable pairing protocol (eg, Bluetooth or IEEE 802.11)
) Can be used. In addition or alternatively, operation 1034 may record the pairing within one or more of devices 1002-1012.

Act 1036 reattaches the wearable system monitor to the wearable dock. Act 1038, for example, to determine if the wearable system monitor and the wearable dock are authorized to dock with each other.
Identify and authenticate the wearable dock using the wearable system monitor. For example, operation 1038 may ensure that the wearable system monitor is docked to the correct patient wearable dock. For example, if the wearable system monitor is docked in the wrong patient's wearable dock, the wearable system monitor recognizes the mistake and (in some embodiments) stops the patient care. Preventing the associated therapy from proceeding by sending a signal to a patient-care device associated with the device, such as a monitoring client, eg, FIGS.
7, 8, monitoring client 1, 4, or 11, monitoring client 9, 4, or 11 in FIG. 9, or other monitoring clients disclosed herein. Operation 1024 can resume treatment if treatment is interrupted, or operation 1040 can treat the patient according to any updated settings 1040.

In some specific embodiments, if a caregiver is identified at operation 1016 and / or a patient is identified at operation 1026, the caregiver may be, for example, a monitoring client, hub, remote communicator, or patient care device. The treatment settings can be updated above.

FIG. 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 acts 1102-1132. In some embodiments, each operation 1
102 to 1132 are optional.

The monitoring client of the method 1100 is the monitoring client 1, 4 of FIGS.
, Or 11, one or more of the monitoring clients 9, 4, or 11 of FIG. 9, or other monitoring clients disclosed herein. The patient-care device of the method 1100 is the patient-care device 7, 14, 15, 16, 17, 35 of FIG.
126, 128, 130, 148, patient care device 14, 15, 16, 17, FIG.
830, 810, 812, 814, patient care device 14, 15, 16, 17, 9 of FIG.
04, 906, 908, or one or more of the other patient-care devices disclosed herein.

Although the method 1100 describes using a user interface template with a monitoring client, the monitoring client replaces with a hub, communication module, another patient-care device, or other sufficient device with a user interface. be able to. The user interface template of the user interface of method 1100 provides a specific display on a predetermined display for displaying patient care parameters. For example, an infusion pump user interface template can define a particular area for display on the GUI, such as the current fluid flow rate. The user interface template can also define an area on the display of the monitoring client to display the current fluid flow rate as received from the infusion pump. User interface templates provide instructions on how to display information, descriptions of various widgets, various widgets, graphs, labels for graph axes, labels for displays, buttons, and / or one or more patients Layout information such as labels for providing care device control or visual information to the user may be included. The user interface template may be a template that describes a QT-based template and / or may use HTML or CSS.

Act 1102 identifies or selects a patient-care device for communicating with a monitoring client having a user interface. For example, in operation 1102, the monitoring client can automatically identify a predetermined infusion pump previously specified by the patient's treatment provider. Additionally or alternatively, in operation 1102, the provider selects a patient-care device to select for display on the monitoring client user interface information regarding the operation of the selected patient-care device (s). A list of can be given.

Act 1104 determines whether the patient-care device has a stored user interface template. For example, the infusion pump can include a flash memory in which a user interface template is stored. If the patient-care device has a stored user interface template, operation 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 patient care parameters on the displayed user interface template according to the user interface template. For example, an infusion pump user interface template can include space for the current infusion rate, and operation 1112 in this example uses the user interface template to display the current infusion rate on the display. (Patient care parameters) are displayed.

If in operation 1104 it is determined that the patient-care device does not have a stored user interface template, the method 1100 may be used by the monitoring client to display the patient-care parameters of the patient-care device. And in addition, or alternatively, operation 11004 can raise an alarm via the monitoring client and / or the patient-care device. Operation 1
114 determines the type of patient-care device. If the type is determined, action 111
6 determines whether the user interface template is stored in the monitoring client according to the type of patient-care device. If there is a user interface template, action 1118 is performed on the user interface of the monitoring client.
Display the interface template. Act 1120 communicates patient-care parameters between the patient-care device and the monitoring client. Act 1122 displays patient care parameters on the displayed user interface template according to the user interface template. For example, patient care parameters such as infusion rate can be displayed within a predetermined area of the user interface as specified by the user interface template.

If the type is not determined in operation 1114 or if the user interface template is not placed in the monitoring client based on the determined type, then operation 1124 may include multiple user interfaces on the monitoring client user interface. • Display a selectable list of templates, and in addition or alternatively, operation 1114 may issue an alarm or alert via the monitoring client and / or patient care device. Act 1126 allows the user to select a user interface template from a plurality of user interface templates using the user interface of the monitoring client. Act 1128 displays the user interface template on the user interface of the monitoring client. Act 1130 communicates patient care parameters between the patient care device and the monitoring client. Act 1132 displays patient care parameters on the displayed user interface template according to the user interface template.

  In some embodiments of the present disclosure, the patient-care device of method 1100 may also include one or more fonts for display on the monitoring client using, for example, the user interface template described above. Can be remembered. Fonts can be stored in any format, such as JPEG, BMP, image format, prestore font, and can be communicated for use within a region to provide an indication of operating parameters (e.g., values Rather than communicating an image showing the number or value that is subsequently displayed on the monitoring client). In some embodiments, the font stored in the monitoring client can be used, so that the value of the operating parameter is displayed for display in the template using the font stored in the monitoring client. Sent to the monitoring client.

FIG. 16 is a flowchart diagram of a method 1134 for downloading an application for controlling a patient-care device according to an embodiment of the present disclosure. Method 1134 of FIG.
In which the monitoring device is described as an exemplary device for controlling the patient-care device, the monitoring device is a dock, hub, communication module, remote communicator,
It can be replaced with and / or supplemented by a communication device or the like.

Method 1134 includes acts 1136-1146. In some embodiments, each operation 1
136 to 1146 are optional. The monitoring client of method 1134 is optionally
1, 3, 5, 8, 8, 9, 9, 9, or one of the other monitoring clients disclosed herein. Also good. The patient-care device of method 1134 is optionally a patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, FIG.
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 disclosed herein It may be one of the other patient care devices. The server of method 1134 may optionally be one of the monitoring servers 3 of FIGS. 1, 3, 5, 7, 8, or 9.

Act 1136 docks the patient-care device into the dock. For example, FIG.
Five or seven injection devices 7, the injection device 830, 810, or 812 of FIG. 8, or the injection device 904 of FIG. 9 can be docked within the respective docks. In operation 1138, the monitoring client identifies the patient-care device. For example, the patient care device can communicate, for example, an ID number, serial number, description, prescription, treatment plan, patient treatment parameters, etc. to the monitoring client, eg, via a discovery protocol. Each docked patient-care device can store treatment information (eg, drug volume, infusion rate, total fluid volume, or other patient therapy parameters) that can be associated or associated with each patient.

In operation 1140, the monitoring client queries the server for an application to control the patient-care device (eg, to set the infusion rate). In operation 1142, the monitoring client downloads the application. Communication 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. In addition or alternatively, all communications can be encrypted. During operation 1144, the monitoring client executes the application. At operation 1146, the monitoring client is communicatively and operatively 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 a set of processor-executable instructions that are configured to be executed by one or more processors on the monitoring client. The application may include instructions for displaying the user interface on the display of the monitoring client using, for example, the user interface template of the method 1100 of FIG. In addition or alternatively, in some embodiments, parameters or values for the patient-care device, such as bolus volume, infusion flow, total delivery fluid, start time for drug delivery, stop time for drug delivery, delivery flow profile The application can be used to control the patient-care device by optionally sending pill dispensing instructions, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills.

FIG. 17 is a flowchart diagram of a method 1200 for ensuring data integrity when communicating data (eg, requests) for a patient-care device in accordance with an embodiment of the present disclosure.
Method 1200 includes acts 1202-1222. In some embodiments, each operation 120
2 to 1222 are optional. The patient-care device of method 1200 can be any patient-care device disclosed herein, for example, patient-care device 7, FIG.
14, 15, 16, 17, 35, 126, 128, 130, 148, patient care device 14, 15, 16, 17, 830, 810, 812, 814 in FIG. 8, patient care device 14, 15, in FIG. 16, 17, 904, 906, 908, or other patient care devices disclosed herein.

The request is optionally, for example, the monitoring client 1 or 4 of FIG. 1, 3, 5, 7, or 8, the remote communicator 11 of FIG. 1, 3, 5, 7, 8, or 9, mobile phone, handheld. It can originate from any authorized, authenticated and / or identified surveillance client such as a computer, tablet computer, laptop computer, personal computer, personal digital assistant, etc.

Act 1202 presents a request for the patient-care device using the monitoring client user interface. For example, the user presents the infusion rate to the infusion pump 7 using the touch screen of the monitoring client 1 of FIG. In some embodiments, the request is optionally a parameter associated with the patient-care device, e.g.,
Bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, delivery flow profile, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing It may be a standard.

Operation 1204 is optional and operation 1204 displays a “pending request” on the monitoring client user interface. Act 1206 formats the request for the patient-care device. For example, operation 1206 can prepare the request to meet the communication requirements of the patient-care device.

Act 1208 determines a check value for the request. For example, a cyclic redundancy check algorithm is used to determine a check value corresponding to the request. The check value calculated by the cyclic redundancy check algorithm depends on the request.
A 1-bit change in the request also changes the check value calculated by the cyclic redundancy check algorithm. Similarly, a change of several bits also changes the check value. Additionally or alternatively, in other embodiments, parity bits (even or odd) or other data integrity checks can be used.

Act 1210 adds a check value to the request. Act 1212 is optional and act 1212 is used to communicate a request using the user interface.
Request confirmation from the user. The request for confirmation may be a pop-up dialog box on the touch screen displaying “Did you confirm the 90 ml / hour infusion rate?” With a box to select “confirm”. The text and format shown in operation 1212 may be used to provide other safeguards against bad display pixels, corrupted font tables, user misunderstandings, etc., for example, other displays such as those displayed during request entry. There may be different fonts, different font sizes, and / or different display positions from the information. Act 1214 confirms the request for communication of the request using the user interface. The user can touch the “confirm” box to confirm the request for communication of the request according to some embodiments of the present disclosure.

Act 1216 communicates the request to the patient-care device. Communication can be performed via wired, wireless, induction, or fiber optic communication. During operation 1216, the patient-care device receives the request. During the passage of a request, one or more bits in the request may be corrupted, for example, the value of the bits may change, bits may be lost, bits may be added, etc. Data corruption is undesirable.

Operation 1218 of method 1200 facilitates detection of corrupted data. During operation 1218, the patient-care device authenticates the check value according to the request. In operation 1218, the patient-care device may use the same cyclic redundancy check algorithm as in operation 1208 on the request to calculate additional check values. The check value of operation 1216 as calculated by the patient-care device is the same as the check value calculated in operation 1208 only if the data in the request is the same. That is, operation 121
If the check value of 6 and the check value of operation 1208 are corrupted, the request data is corrupted, has fewer or more bits, or is not identical to the digital data used to determine the check value of operation 1208 Only different.

If the check value of the request is not authenticated, at operation 1222, the patient-care device requests re-transmission of the request from the monitoring client. Although FIG. 17 illustrates operation 1222 as proceeding to operation 1204 of method 1200, in other embodiments, method 1
200 can proceed to any of operations 1202-2116. If the re-transmission of the request is not successful, the method 1200 can communicate an error, alarm, or alert (not shown) to the monitoring client. Alternatively, if the check value is verified not to indicate data corruption, at operation 1220, the patient-care device makes a request.

  In an alternative embodiment, the request for action 1218 may additionally be sent back to the monitoring client after authentication from the patient-care device and include additional CRC checks during transmission. The authenticating patient-care device can in this alternative embodiment perform a check to determine if the request is within a predetermined range (eg, whether the infusion rate for a particular drug is safe). . The monitoring client, in this alternative embodiment, can compare the request received from the patient-care device with the original request stored in memory (and can associate the requests with each other), and / or the monitoring client can The request can be displayed to the user for confirmation. The request for confirmation may be a pop-up dialog box on the touch screen 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 are displayed, for example, during request entry to provide additional safeguards against bad display pixels, corrupted font tables, user misunderstandings, etc. It may be a different font, a different font size, and / or a different display position than other display information. In this alternative embodiment, the user can confirm the request for communication of the request using the user interface. The user can touch the “confirm” box to confirm the request for communication of the request according to some embodiments of the present disclosure.

Thereafter, in this alternative embodiment, re-send to the patient-care device to make a request, in addition or alternatively, in this alternative embodiment, an action message is sent to the patient-care device, and the action message is To link the request to the original request (for example, “This is for a 90 ml / hour request that was just sent”
Operation "is").

FIG. 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, dock 1
304 can serve as a hub as described herein.

The patient-care device is a patient-care device 7, 14, 15, 1 of FIG.
6, 17, 35, 126, 128, 130, 148, patient care device 14, 15 of FIG.
16, 17, 830, 810, 812, 814, or the patient-care device 14 of FIG.
Any patient care device disclosed herein, such as one of 15, 16, 17, 904, 906, 908. The monitoring client 1302 is configured as shown in FIGS.
, 7, 8 monitoring client 1, 4, or 11, monitoring client 9, 4, or 11 in FIG. 9, tablet, smart phone, PDA, etc., can be replaced with any monitoring client described herein .

The dock 1304 sends the monitoring client 13 to the dock 1304 through the cable 1308.
A receiving unit shaped to receive the monitoring client 1302 can be included to connect 02 electrical contacts. The cable 1308 can be integrated with the dock 1304 and / or the monitoring client 1302. The cable 1308 is, for example, a dock 1
USB or other standard communication can be provided between 304 and the monitoring client 1302.

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. Patient care device 1318 can be docked to dock 1304. The system 1300 also includes a wireless dock 1306 with a patient-care device 1320 docked. The wireless dock 1306 may be the same as or similar to the dock 1304, but the wireless dock 1306 is in wireless communication with the monitoring client 1302 in some embodiments.

Battery 1314 can provide power to dock 1304 and patient-care device 1318 when AC power cord 1316 is unplugged from an AC outlet (not shown). In some embodiments, dock 1304 may be the only power source for monitoring client 1302 or patient-care device 1318. In addition or alternatively, the monitoring client 1302 and / or patient-care device 1318 can comprise an on-board battery or a separate AC power cord (not shown).

In some exemplary embodiments, the dock 1304 is connected to the patient-care device 1318 by I
EC-60601 compliant power can be provided. 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 may be a specific connector of the connector 1322
A programmable buck-boost power supply (not shown) can be provided for the pins that can provide a DC voltage from 1 to 24 volts as required by the patient-care device 1318.

Battery 1314 can be charged by charger 1312 when power cord 1316 is plugged into an AC outlet (not shown). Battery 1314 is connected to patient care device 13 when AC power cord 1316 is unplugged from an AC outlet (not shown).
18 provides unimpeded power. For example, patient care device 1318 can be
It may be an infusion pump that continues to operate after the C power cord 1316 is unplugged. This is because the battery 1314 remains in the patient care device 13 after the AC power cord 1316 is unplugged.
This is because the power for replacement is automatically supplied to 18.

The sensor 1308 can optionally include one or more of an atmospheric temperature sensor, an atmospheric pressure sensor, an atmospheric humidity sensor, and the like. The sensor 1308 may optionally include an extra sensor, such as two temperature sensors, and the dock 1304 may determine whether one or both have failed, for example by comparing the two sensor readings with each other. An extra sensor may be used to do this. The dock 1304 communicates with the sensor 1308 and / or other peripherals to provide its measurements, eg, ambient temperature, to the patient-care device 1318 to perform its data integrity check to ensure its proper operation. be able to.

Watchdog 1310 optionally makes the above query and monitors the output of patient-care device 1318 to determine if it is within a predetermined range (eg, a physically possible or possible range). Can ensure that the patient-care device 1318 is operating properly, have feedback that follows the applied input, or is operating properly. In addition, or as an alternative, system monitor 130
10 may optionally monitor the operation of the monitoring client 1302 through the cable 1308. Although one watchdog 1310 is described herein, one or more watchdogs 1310, eg, a plurality of watchdogs 1310 may be used. In some exemplary embodiments, patient-care device 1318 communicates with watchdog 1310 at fixed intervals. A fixed interval is optional and the monitoring client 1
Configurable using a 302 user interface or using a computer attached to cable 1308. If the patient-care device 1318 cannot communicate with the watchdog 1310 during a fixed interval, the watchdog 1310 determines that an error has occurred in the patient-care device 1318 and alerts or alarms such as the speaker 132.
4 is used to emit an audible sound, or LED 1326 blinks red. Responding to not receiving communication within the interval can be configured and / or programmed using, for example, the user interface of the monitoring client 1302 or using a computer attached to the cable 1308 be able to. For example, a non-critical patient-care device may cause LED 1326 to flash red by not responding to watchdog 1310, in addition to operations to the critical patient-care device in addition to dock 1304.
And / or the monitoring client 1302 to a nurse station and / or a remote communicator, such as the remote communicator 11, FIG. 1, 3, 5, 7, 8, or 9;
Notifications may be audibly and visually alerted and transmitted to smart phones, laptop computers, other patient-care devices, and the like. In addition or as an alternative,
The LED 1326 may optionally blink green when the patient-care device 1326 is operating properly or is currently treating the patient. In addition or alternatively, the speakers in the monitoring client 1302 can emit an audible warning or alarm. If appropriate, the patient-care device can be disabled or replaced until the error condition is cleared.

In addition, or alternatively, that the watchdog 1310 needs to communicate with the watchdog 1310 at fixed, predetermined, or pre-programmed intervals to ensure that the monitoring client 1302 is operating properly. Can be guaranteed.
If the monitoring client 1302 cannot communicate with the watchdog 1310 during a fixed interval,
The watchdog 1310 determines that an error has occurred in the monitoring client 1302 and
Alarms or alarms similar to those described above with respect to the patient-care device 1318, for example using the speaker 1324, emit an audible sound or cause the LED 1326 to flash red.
In some embodiments, a speaker in the monitoring client 1302 can emit an audible alarm. In some embodiments, a speaker in the monitoring client 1302 can serve as a backup speaker for the dock 1304, and a speaker 1324 in the dock 1304 can serve as a backup speaker for the monitoring client 1302.

The charger 1312 uses AC power supplied through the AC power cord 1316,
The battery 1314 can be charged. In addition or as an alternative, the charger 131
2 can charge the battery 1328 within the patient-care device 1318.

In some embodiments, wireless dock 1306 may comprise the same hardware as dock 1304 and may or may not include AC power cord 1316. For example, the wireless dock 1306 can include a plurality of contacts for positioning the wireless dock within a recharge cradle that includes a plurality of contacts that engage the contacts of the wireless dock 1306 to charge a battery therein.

FIG. 19 is a block diagram of an electronic patient care system 1400 according to another embodiment of the present disclosure. The system 1400 includes a monitoring client 1402, a dock 1404, a large capacity pump 1406, a syringe pump 1408, and a sensor 1410. The system 1400 also includes a USB sensor 14 coupled to the dock 1404 through a USB cable.
12, a wireless sensor 1414 that communicates wirelessly with the dock 1404, a server 1416, and a hospital information server 1418 are provided. The monitoring client 1402 is the
Monitoring client 1, 4, or 11, monitoring client 9, 4, or 11 of FIG.
It can be any monitoring client such as one of a tablet, smart phone, PDA, laptop. The dock 1404 may include one or more large volume pumps 1406, 1408, and / or via electrical conductors shown in FIG. 19 and / or wirelessly.
Or, it can communicate with sensor 1410 to receive parameters and / or control the device.

Dock 1404 receives AC power 1420 from AC outlet 1422. Dock 1
404 uses a monitoring client adapter 1424 to monitor client 1402
Communicate operably with. The monitoring client adapter 1424 includes a UI connector 1426.
, 1428 to dock 1404. UI connectors 1426 and 1428
Provides power to the monitoring client adapter 1424 and data over the USB link. The monitoring client adapter 1424 has several connectors 1430, 1
It is coupled to the monitoring client 1402 through 432, 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 are in the US
A B connection is provided to facilitate digital communication between the dock 1404 and the monitoring client 1402. Note that other embodiments may utilize connections other than USB type.

  Connectors 1438-1450 allow dock 1404 to operably supply power to mass pump 1406, syringe pump 1408, and sensor 1410. Additionally or alternatively, connectors 1438 and 1440 provide serial communication between dock 1404 and mass pump 1406 and connectors 1442 and 1444 provide serial communication between mass pump 1406 and syringe pump 1408. Provided, connectors 1446 and 1448 provide serial communication between the syringe pump 1408 and the sensor 1410. Connector 1450 provides optional expansion for additional devices (not shown).

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

Dock 1404 can be, for example, Bluetooth, Bluetooth Low Energy, Z
Wireless sensor 1414 using igbee, Xbee, ANT, ANT Plus, etc.
Can communicate with. Sensors 1412, 1414, and / or 1410 may be patient monitoring devices or one or more environmental sensors such as temperature sensors, humidity sensors, cameras, microphones, ambient light sensors, vibration sensors, and the like.

Server 1416 can communicate with hospital information system 1418. Server 141
6 provides a WiFi router, so that the dock 1404 is connected to the hospital information system 14
18 in operative communication. Information for the protocol of the dock 1404, hospital information system 1
It can be transferred to and from hospital information system 1418 through server 1416, which can be translated into and out of 418 or health level 7 (HL7). Server 1416 (and / or hospital information system 1418) may be
Can be provided with a drug error reduction system (DERS) that checks to determine that any treatment being performed on the patient is safe for the patient. The server 1416 may be the monitoring server 3 and the hospital information system 1418 may be the equipment service 8 of FIGS. 1, 3, 5, 7, 8, and / or 9.

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

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

DC power 1454 is a DC power input 1456 that may be a connector for connecting the positive and negative leads of DC power 1454 to the power and ground plane of the PCB board, respectively.
Can be received. DC power input 1456 provides power to the circuitry of dock 1404. DC
The power input 1456 can also receive wireless power 1458.

The power received via DC power input 1456 is transmitted to charging circuit 1460. The charging circuit 1460 includes a primary battery 1462 and a backup battery or super capacitor 146.
4 is charged. The charging circuit 1460 can utilize various charging technologies, such as a constant current / constant voltage charging algorithm.

The dock 1404 includes a primary processor 1466 and a safety processor 1468. Primary processor 1466 is powered by primary battery 1462. The safety processor 1468 is not only powered by the primary battery 1462, but can also receive power from a backup battery or supercapacitor 1464.

In the exemplary embodiment, primary processor 1466 is barcode reader 1470.
, Camera 1472, dock sensor 1474, speaker 1476, WiFi transceiver 14
78, Bluetooth transceiver 1480, USB controller 1482, LED status light 1
484, and three internal expansion slots 1486, 1488, and 1490 (each optional).

Internal expansion slots 1486, 1488, and 1490 can receive additional circuitry. For example, as shown in FIG. 20, the internal expansion slot 1486 includes a communication / ranging module 1492, which includes an RFID reader 1494 and a short range communicator 1488 inserted therein (optionally, respectively). Is).

Safety processor 1468 provides watchdog functionality to primary processor 1466. For example, the safety processor 1468 can communicate with the primary processor at predetermined intervals or predict communication from the primary processor 1466 at predetermined intervals. If safety processor 1468 does not receive the expected response or communication, it can be determined that an error has occurred. In response to the error, the safety processor 1468 sends the LED fault status light 14
01 can be used to indicate a failure, a backup speaker 1403 can be used to generate an audible sound, or a vibration motor 1405 can be used to vibrate the dock 1404. As can be appreciated in light of this disclosure, many failure notifications (eg, telephone, email, text message, etc.) can be sent to many employees (eg, nurses and / or physicians, equipment maintenance, etc.). .

The safety processor 1468 can use the current sensing circuit 1407 to monitor the power supplied through the device connector. 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 is supplied from the primary battery 1462 to the device connector 1438. A signal is sent to the power enable circuit 1409 to release the power.
The power enable circuit 1409 can include relays, switches, solid state switches, contactors, etc. to connect and disconnect the primary battery 1462 to and from the device connector 1438.

Primary processor 1466 is also electrically coupled to optional charge status display 1411 and optional display 1413. The charge state display 1411 is a primary battery 14
62 charging states can be displayed. Display 1413 may be a touch screen and / or may display the operational status of dock 1404. The dock 1404 receives user input via an optional button 1415.

The communication / ranging module 1492 can communicate with other communication / ranging modules 1492, eg, on a patient-care device, other dock, or monitoring client to determine the distance therebetween. For example, two communications / ranging modules (eg, communications / ranging module 1492 and another communications / ranging module) may determine the distance between them.
For example, wireless communication can be performed by ultrasonic waves, RF, UHF, electromagnetic energy, optics, or the like. According to one embodiment, one or more of a patient-care device, a monitoring client, a patient watchdog, a remote communicator, etc., each having a communication / ranging module 1492 is within a predetermined distance relative to each other. Unless determined, it may not work.

FIG. 21 shows an infusion pump 2 connected to and delivered from the smaller fluid bag 2118
106 and an infusion pump 21 connected to and delivered from the larger fluid bag 2116
08, a drip detection device 2112 connected to the pipe from the smaller bag 2118,
FIG. 6 shows an exemplary arrangement of a system 2100 with a pill dispenser 2114 and a microinfusion pump 2110 in which a monitoring client 2102 is linked to several patient care devices via a dock 2120. Yes. Monitoring client 2102 includes infusion pumps 2106, 2108, microinfusion pump 2110 (via docks 2120, 2104), and pill dispenser 21.
As shown for FIG. 14, it is possible to communicate with these patient-care devices in a wired manner.
Alternatively, the monitoring client may include the drip detection device 2112 and the monitoring client 210.
As presented by the lack of a wired connection between the two, wireless communication with the patient-care device can be made. In an embodiment, a wired connection between the monitoring client 2102 and the patient-care device also provides an opportunity for power to be supplied from the monitoring client 2102 to the patient-care device. In this case, the monitoring client 2102 may be connected to the patient-care device either from a battery attached to the monitoring client 2102 or from a line voltage supplied to the monitoring client 2102 from a patient room power outlet (not shown). To provide power, the necessary electronic circuitry can be provided to convert the voltage. Additionally or alternatively, the dock 2104 provides power to the infusion pumps 2106, 2108 and the microinfusion pump 2110.

In embodiments, the monitoring client 2102 can be directly from the device itself or, for example,
It is possible to receive information about each patient-care device that is linked either via a docking station, such as a dock 2104 on which the patient-care device can be mounted. The dock 2104 may 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. it can. For example, in FIG. 21, the infusion pumps 2106 and 2108 can be attached to the dock 2104 via a similar connection mount, and the microinfusion pump 2110 can be, for example, sized to a specific dimension of the microinfusion pump 2110 housing. It can be attached to the dock 2104 via a configured connection mount.

The dock 2104 is configured to electronically identify a 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. can do. In addition, a particular patient-care device can be pre-programmed with treatment information (eg, patient treatment parameters such as infusion rate for a given infusion fluid) communicated to the monitoring client 2102. In some embodiments of the present disclosure, the monitoring client 2102 communicates with the EMR record to ensure that preprogrammed treatment information is safe for the identified patient, and / or
Alternatively, authenticate that pre-programmed treatment information matches the prescribed treatment stored in the EMR record.

In some embodiments, the drip detection device 2112 can communicate with the monitoring client 2102 in either a wireless or wired connection. If an abnormal fluid flow condition is detected (eg, due to a blockage to the patient) (1) the monitoring client 2
The fluid flow rate from the fluid container 2118 can be displayed within the user interface, either locally on 102 or remotely by a user interface at a nurse station or handheld communication device (2 ) An audible or visual alarm can be triggered; (3) the infusion rate of the pump 2108 connected to the bag 2118 can be changed by either terminating the infusion or changing the pump speed; Or (4) a signal that can generate an audible alarm (and / or vibration alarm) on the infusion pump 2106 can be communicated to the monitoring client 2102. Alarms can be generated simultaneously on several devices, or can be generated continuously on a predetermined schedule. For example, if the occlusion is infusion pump 2
(1) the drip detection device 2112 warns using its internal speaker and internal vibration motor, and (2) the infusion pump 2106
Alerts using its internal speaker and internal vibration motor, (3) then the monitoring client 2102 warns using its internal speaker and internal vibration motor, and (4) finally the remote communicator 11 ( For example, see FIGS. 1, 3, 5, 7, 8, and 9) using its internal speaker and internal vibration motor to warn.

In some embodiments, if a communication fails between the monitoring client 2102 and the pump due to a failure either in the monitoring client 2102, in the communication channel between the monitoring client 2102 and the pump, or in the pump itself, Individual pumps can be programmed to allow continued operation at a given pump speed. In some embodiments, such independent functional options are enabled if the infused medication is pre-designated not to be interrupted or sustained in case of failure of other parts of the system. The In some embodiments, pumps programmed to operate independently in fail-safe mode may also be configured to receive information directly from the infusion detection device 2112 rather than through the monitoring client 2102. it can. With this option,
The pump, in some embodiments, can be programmed to stop infusion when the drip detection device 2112 detects an abnormal flow condition (eg, a free flow condition or a bubble present in the infusion line). it can. In some embodiments, pumps 2106, 21
One or more of 08 and 2110 can have an internal fluid flow meter and can operate independently as a stand-alone device.

FIG. 22 illustrates patient care devices 2106, 2108, 2110 according to embodiments of the present disclosure.
Tablet 21 docked in the dock for wireless communication with 2112, 2114
An electronic patient care system 2200 having 02 is shown. The monitoring client 2102 can be connected to the patient care device 2106 wirelessly or through a wireless transceiver on the dock 2120.
2108, 2110, 2112. For example, the monitoring client 2
102 can communicate with the transceiver in the dock 2104. In addition, or alternatively, the dock 2120 may monitor the client 21 to communicate with the dock 2104.
02 and / or patient care devices 2106, 2108, 2110, 2112
2114 for direct use via a wireless connection to 2114.

FIG. 23 illustrates an electronic patient care system 2300 having modular infusion pumps 2302, 2304, 2306, 2308 docked in a dock 2310 having a monitoring client 2312 with a retractable user interface, according to embodiments of the present disclosure. ing. The modular infusion pumps 2302, 2304, 2306, 2308 have standard connectors so that they can be snapped into the dock 2310. Each of the modular infusion pumps 2302, 2304, 2306, 2308 has a user interface. For example, the modular infusion pump 2302 includes a touch screen 2314, a start button 2316, a stop button 2316, an infusion rate increase button 2320, and an infusion rate decrease button 2322. FIG. 24 is a side view of the electronic patient care system 2300 of FIG. Thus, the outline of the cavity 2400 is shown in which the monitoring client 2312 can be stored.

FIG. 25 has modular infusion pumps 2502, 2504, 2506, 2508 docked in a dock 2510 having a monitoring client 2512 with staggered and retractable user interfaces according to another embodiment of the present disclosure. An electronic patient care system 2500 is shown. The system 2500 of FIG. 25 is the same as the system 25 of FIG.
00 in staggered modular infusion pumps 2502, 2504, 2506, 2
Other than having 508, it may be similar to the system 2300 of FIG. The staggered arrangement of modular infusion pumps 2502, 2504, 2506, 2508 can provide greater margin for pipe routing.

FIG. 26 shows an electronic patient care system 2600 having modular infusion pumps 2602, 2604, 2606 that dock into a dock 2608 along a common horizontal plane. The dock 2608 includes a monitoring client 2610 that can be stored in the dock 2608. The monitoring client 2610 can be stored entirely in the dock 2608 and / or some monitoring client 2610 circuitry can be stored in the dock 2608. As can be readily seen from FIG. 27, which shows a side view of the electronic patient care system 2600 of FIG.
Swivel along swivel axis 2700 to store monitoring client 2610 in 2.

FIG. 28 illustrates another embodiment of an electronic patient care system 2900 that includes a hub 2902 coupled to a device dock 2904. FIG. 29 shows a side view of the electronic patient care system 2900 of FIG. The monitoring client 2901 is integrated with the hub 2902. In an alternative embodiment, hub 2902 is a cradle for monitoring client 2901 and only provides electrical connection to dock 2904 and scanner 2912.
Modular infusion pumps 2906, 2908, 2910 are shown docked in device dock 2904. System 2900 also includes a scanner 2912 coupled to hub 2902. Each dock 2904 has a dock 2904
Simple attachment / detachment handles 2914 and 2916 are provided on the left and right sides. Also, each button 2918 that lights when the patient care device is the focus of interaction on the monitoring client 2901 (type of monitoring client, shown as a tablet) or has been selected for control by the user. , 2920, and 2922 are shown in the upper left corner of each modular infusion pump 2906, 2908, 2910. The tablet can select a particular modular infusion pump, or the user can select buttons 2918, 2920, and 292 on the modular infusion pumps 2906, 2908, and 2910.
Each of the two buttons can be pressed to select for operation on the monitoring client 2901.

30-32 illustrate several views illustrating a clutch system for mounting an electronic patient care system on a post according to an embodiment of the present disclosure. FIG. 30 shows the column 3104
A top view of a dock 3100 with a hole 3102 for receiving is shown. Clutch 31
10 and 3112 are shown in FIG. In some embodiments, the clutch 31
10 and 3112 are provided with cleats 3114 and 3116, respectively. Handles 3106 and 3
107 can be used individually or together to release clutches 3110 and 3112 from strut 3104 (eg, by pulling on a handle). Additionally or alternatively, handles 3106 and 3107 are used to connect clutches 3110 and 3112 to strut 310 (eg, by pushing handles 3106 and 3107).
4 can be locked. As can be easily seen from FIG. 31, for example, a downward force due to gravity further presses the clutches 3110 and 3112 against the column 3104. Although two clutches 3110, 3112 are shown in FIG. 31, one clutch can be used to push the strut 3104 against the friction surface. FIG. 32 shows an alternative strut mounting structure 3300 that uses two fasteners 3302 and 3304 to clamp the strut 3104.

FIG. 33 illustrates infusion pump 3400 and retractable connector 34 according to an embodiment of the present disclosure.
02 and 3406 are shown. 33-35, the hub 3401 is the retractable connector 3
Shown as having 402 and 3406. The hub 3401 has a docking connector and serves as a dock. Retractable connectors 3402 and 3406 are shown closed in FIG. However, in alternative embodiments, retractable connectors 3402 and 3406 can be directly connected to infusion pump 3400, infusion pump 3412, and / or additional infusion pumps. The hub 3401 can have a column attachment mechanism surrounded by the hub 3401 (see FIG. 36). The hub 3401 may be a dock or a cradle in some embodiments and may optionally include a handle coupled to the top thereof. The handle can be integrated into the post mounting mechanism, thereby lifting the handle to release the hub 3401 from the post. Alternatively, in some embodiments, the hub 3401 can support a cradle and attach it to a surveillance client, eg, a tablet, or attach the surveillance client to a separate post. Retractable connectors 3402 and 3
406 may have a support mechanism (eg, lip) on the bottom of retractable connectors 3402 and 3406 to support the infusion pump when attached, in some embodiments. In this exemplary embodiment, the lip may also be a mechanism for electrical connection.

In FIG. 34, retractable connector 3402 is shown open and connectors 3408 and 3410 are shown. Connectors 3408 and 3410 are retractable connectors 340
2, in other embodiments, connectors 3408 and 3410 are connected to hub 34.
01 or infusion pumps 3400 and 3402 are connected to connectors 3408 and 3
A cover for covering 410. The retractable connector 3406 has an 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 connected to hub 340.
1 are electrically connected together in FIG. FIG. 36 shows a top view of infusion pump 3400 and hub 3401 as attached to strut 3420 of FIGS.
Retractable connectors 3402 and 3406 are shown in an open configuration.

FIG. 37 illustrates a number of connectors 3703, 3705, 370 according to embodiments of the present disclosure.
A square hub 3701 having 7,3709 is shown. Each connector 3703, 370
5, 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 the modules attached thereto using a subset. In some embodiments, each connector 3703, 3705, 3707, and 3709 uses a subset of available pins that are specific to the device to be connected based on the type of device, eg, as determined from the signal. be able to. The column mounting mechanism is a square hub 3
701 can be disposed on the back surface. The square hub 3701 also has a front connector 37.
11 and a rear connector 3713. Each connector 3703, 3705
The mechanical fixture associated with 3707, 3709, 3711, 3712 may be a permanent fixture (eg, a screw) or a simple removable attachment point (eg, a latch).

FIG. 38 illustrates an electronic patient care system having a hub 3701 coupled to a post 3715 according to another embodiment of the present disclosure. FIG. 38 shows the articulated monitoring client 37 on the left side.
12, an extended battery / communication module 3717 at the top, a barcode scanner module 3719 at the bottom, and a pump dock 3723 on the right side of the hub 3701. The pump dock 3723 is detachable for transport, with all infusion pumps 3725, 3727, 3729 mounted so that they can all be transported as one unit. A simple attach / detach handle 3731 is placed on top of the pump dock 3727 to allow easy removal from the hub 3701. Alternatively, in other embodiments, the infusion pumps 3725, 3727, 3729 can be daisy chained together.
The articulated monitoring client 3721 (eg, tablet) can be permanently attached to the hub 3701 and is “zero channel pump” when the dock 3723 is removed.
Can produce. For example, the monitoring client 3721 can continue to operate and monitor various patient-care devices when the pump is not attached to the monitoring client 3721 and / or is not operatively communicating.

FIG. 39 illustrates a portable dock 3733 as a hub 3701 according to another embodiment of the present disclosure.
1 illustrates an electronic patient care system having a hub 3701 coupled to a post 3715 and a portable dock 3733 with a quick release handle 3731 for removal from the device. The hub 3701 allows the device to be connected thereto using an adapter plate 3735 as shown in FIG.

FIG. 40 illustrates an electronic patient care system having a hub 3701 coupled to a post 3715 and a dock 3735 coupled to the hub 3701 according to another embodiment of the present disclosure. The dock 3735 of FIG. 40 is shown as a connector plate. That is, the dock 3735 uses the generic connector provided by the hub 3701 to
It is shown as an adapter or connector plate adapted to facilitate connection of infusion pumps 3725, 3727, 3729 to 01. Dock 3701 is dock 37
Provide sufficient signal and sufficient mechanical alignment and orientation to connect to 35 and / or vice versa.

FIG. 41 illustrates an electronic patient care system 4101 having a hub 4103 coupled to a post 4105 according to another embodiment of the present disclosure. Hub 4103 is a connector 4 for receiving three respective infusion pumps, for example infusion pumps 4113 and / or 4115.
107, 4109, and 4111. The patient care system 4101 has a column 4
One side of 105 is a monitoring client 4117, such as a tablet, and a connector 410.
7, 4109, and 4111 are provided with an infusion pump attachable to the other side of the post 4105. Three connectors 4107, 4109, 4111 are shown,
Any arbitrary number of connectors can be used. The electronic patient care system 4101 includes a monitoring client 4117 and infusion pumps such as connectors 4107, 4109,
It makes it easier to see infusion pumps 4113 and 4115 attached to 4111.
In addition, the electronic patient care system 4101 facilitates tube routing. The tube can be inserted from the top to the bottom of the infusion pump, or from the side of the monitoring client 4117 at the side of the column 4105 (eg, using a tube organizer on the column 4105).
Can be routed. The monitoring client 4117 can be connected.
The post mount of the hub 4103 can be fixed to the post 4105 or can slide on a step in the post 4105 that is available with several adjustable posts. Although the post mount of hub 4103 is shown here as a tube shape, in other embodiments it may be rectangular and / or may comprise a power supply, handle, and / or hub hardware. . In some embodiments, the hub 4103 may be a cradle for routing electrical connections.

FIG. 42 illustrates a patient-care device, such as an infusion pump 471, according to another embodiment of the present disclosure.
3 shows an electronic patient care system 4201 having a monitoring client 4203 coupled to a hub 4205 having notches 4207, 4709, 4711 for receiving 3. The infusion pump 4713 includes a slide connector 4715 that slides within one of the notches 4207, 4709, 4711. Connector 4715 may be structurally sufficient and / or may add additional structural support. Monitoring client 42
03 may be folded, for example flattened by a dock 4205. The dock 4205 can include reliefs for routing the tube, eg, from left to right or from top to bottom.
In an alternative embodiment, the infusion pump 4713 can be attached to the dock 4205, which is lifted in front of the front of the dock 4205 to facilitate vertical routing of the tubes. FIG. 43 is an enlarged view of a T-shaped connector, such as connector 4715 of FIG. 42, for connection to notches 4207, 4709, 4711 of hub 4205 as shown.

FIG. 44 illustrates a stackable patient-care device 4403, according to another embodiment of the present disclosure.
4405 and an electronic patient care system 4401 having an infusion bag, eg, a stackable container 4407 for storing infusion bags 4411 and 4408 are shown. A stackable container 4407 has a lid 441 for securing the bags 4411, 4409 therein.
3 is provided. The electronic patient care system 4401 includes a monitoring client 4415 with a screen that can be folded and a handle 4417 that can be raised for portability.

Infusion bags 4411 and 4407 may be microbags and are embedded within having an integrated flow monitor and / or serial number or data (eg, patient data) associated with the contents of bags 4411 and / or 4407. RFID tags can be provided. In this particular embodiment, microbags 4411 and 440
7 can comprise an integrated flow meter, an infusion counter, an integrated infusion chamber, a communication link for communicating via a venous tube, on which a battery or A for powering electronic components
A power supply with or without a C / DC converter can be provided. Intravenous communication uses electrical waves embedded through or attached to a venous vessel, using electrical waves using fluid in the venous vessel as a conductive medium, using acoustic waves traveling through the venous vessel, or an optical waveguide As may occur optically by using the fluid in the tube. Intravenous communications can be encrypted using, for example, symmetric or asymmetric key cryptography. The microbag 4411 and / or 4407 may comprise an optical communicator that communicates data (via an infusion tube) to the infusion pump describing the flow rate and / or the contents of the liquid contained therein. The microbag 4411 and / or 4407 is a pigtail that can interface with an infusion counter that can be used by the reader to determine the content and / or amount of liquid inside the microbag 4411 and / or 4407. Can be equipped with RFID and / or NFC tags (e.g.
Information is encoded in). The microbag 4411 and / or 4407 may comprise a bubble sensor (capacity or ultrasound) that communicates bubble size estimates to the monitoring client and / or hub. The microbag 4411 and / or 4407 may be NFC and / or measured prior to operation (eg, opening a valve and / or activating an integrated flow meter, infusion counter or infusion chamber, communication link, power supply, etc.). It may be necessary to be within a predetermined distance from the patient as determined by the distance module.

FIG. 45 is a stackable patient-care device 4503, 4505, 4507, that can be stacked next to another stack of patient-care devices, according to yet another embodiment of the present disclosure.
Electronic patient care system 45 having 4509, 4511, 4513, 4515, 4517
01 is shown. The electronic patient care system 4501 includes a surveillance client 4519 that includes a screen that can be folded and a handle 4520 that can be raised for portability.

FIG. 46 shows a syringe with a single syringe 4609 according to another embodiment of the present disclosure.
Stackable patient care device 4603, 4 with pump patient care device 4607
1 shows an electronic patient care system 4601 having 605, 4607.

FIG. 47 is a stackable patient-care device 4 with a syringe-pump patient-care device 4707 having two syringes 4711, 4713 according to another embodiment of the present disclosure.
An electronic patient care system 4701 having 703, 4705, 4707, 4709 is shown.

FIG. 48 illustrates a display (ie, display 48) according to another embodiment of the present disclosure.
11, 4813, 4815, 4817) each showing an electronic patient care system 4801 having stackable patient care devices 4803, 4805, 4807, 4809. 49 is an enlarged view of the handle 4901 of the electronic patient care device of FIG. 50 is an enlarged view of the infusion line port 5001 showing the infusion line 5003 positioned therethrough of the electronic patient care system 4801 of FIG.

FIGS. 51-52 illustrate another embodiment of an electronic patient-care system 5101 showing a removable and stackable patient-care device 5102 according to another embodiment of the present disclosure. FIG. 52 shows the handle 5103 being moved in a transport configuration for transporting the electronic patient care system 5101 on the post 5105.

FIG. 53 is a stackable patient-care device 5307 coupled to a post 5317 and coupled to a hub 5303 via a dock connector 5305, according to another embodiment of the present disclosure.
An electronic patient care system 5301 having 5309, 5311, 5313, 5315 is shown. Hub 5303 is coupled to monitoring client 5305. Dock connector 5305 is connected to patient care devices 5311, 5313, via daisy chain connections.
And to patient care devices 5307 and 5309 connected to 5315.

FIG. 54 is an electronic patient-care system 54 having stackable patient-care devices 5403, 5405, 5407 that are stackable from the bottom according to another embodiment of the present disclosure.
01 is shown. FIG. 55 illustrates an electronic patient care system 5501 having stackable patient care devices 5503, 5505, 5507 that are stackable from top to bottom according to another embodiment of the present disclosure.

FIG. 56 shows a perspective view of a clutch system 5601 having a release handle 5603 for frictionally gripping the strut 5605 according to another embodiment of the present disclosure.
FIG. 57 shows a rear view of the clutch system 5601 of FIG. 56 showing a transparent rear surface to illustrate the use of the handle 5603 to engage the clutches 5607 and 5609. FIG. 58 shows a top cross-sectional view of the clutch system of FIG.

FIG. 59 is a block diagram of a system 3400 for controlling an infusion pump according to an embodiment of the present disclosure. System 3400 includes user interface component 3
402, a pump engine component 3404, a data management treatment layer component 3406, and a fluid measurement / safety monitor component 3408.

Components 3402, 3404, 3406, and 3408 may include one or more of, for example, hardware, software, running software, digital logic, firmware, bytecode, virtualization, using PLD, FPGA or PLA It can be implemented using a processor, or some combination thereof. For example, components 3402, 3404, 3406, and 3408 may be an operational set of processor-executable instructions configured to be executed by one or more processors on device 3401, for example, device 3401 may be a book The monitoring client disclosed in the specification may be used. Components 3402, 3404, 3406, and 3408 are 1
It can be stored on a non-transitory computer readable medium readable by one or more processors for execution by one or more processors. For example, one or more processors can be in operative communication with a non-transitory computer readable medium.

The user interface 3402 may be a touch screen (or processor executable code for controlling the touch screen) configured to receive user input, eg, infusion rate. User interface 3402 can be used by an operator to set treatment parameters and view treatment status. The user interface 3402 may be used to adjust patient treatment parameters during treatment for guidance on setting up the system 3400 and / or for post treatment decomposition of the system 3400. User interface 3402 may comprise a touch screen and buttons. User interface 3402 may be a resident software application on device 3401 or may be executed by a remote or another component such as a handheld device or a nurse station computer.
For example, user interface 3402 may be remote communicator 11 or FIG.
It can be implemented by 3, 5, 7, 8, or 9 other monitoring clients 1, 4, smart phones, tablets, PCs, tablet computers and the like.

The data management therapy component 3406 is one or more external data systems 3
410 can be communicated. For example, the data management therapy component 3406 may be configured such that the therapy (eg, infusion rate) entered via the user interface component 3402 is (1) safe for the patient, (2) the illness, condition, illness of the patient 3412. ,
And / or consistent with treatment plan, (3) not contraindicated by another drug or treatment, (
4) No need for specialists not determined to be in close proximity to patient 3412 (as determined by RFID tag, voice authentication, face recognition, username / password identification or authentication, secure signature, etc.) To determine whether the patient's 3412 ID and the electronic medical record 3410 can be compared.

The data management treatment component 3406 can include all treatment settings, can authenticate the settings with an external data system 3410, and can provide treatment history such as flow rate, drug settings, vital signs, etc. of the external data system 3410. Can be recorded in an electronic medical record. The data management therapy component 3406 can also set parameters for any safety monitor. If the data management therapy component 3406 confirms the therapy, the settings are sent to the pump engine component 3404.

The pump engine component 3404 sends patient treatment parameters, such as the infusion rate, to the infusion pump 3414. Infusion pump 3414 may be any infusion pump disclosed herein. In some embodiments of the present disclosure, only the pump engine component 3404 transmits the infusion rate to the pump 3414. The pump may have a fluid measurement capability that is redundant to the flow meter, or is the primary fluid measurement of the system 3406.

The fluid measurement / safety monitor component 3408 can act as a watchdog for other pump engine components 3404, can receive flow data from a flow meter (not shown), and can be a watchdog for the pump 3414. Can work as. The fluid measurement / safety monitor component 3408 can determine whether a fault or error condition exists, for example, whether the measured infusion rate is outside a predetermined range or exceeds a threshold, and communicates a stop command to the pump 3414 Thus, the pump 3414 can be stopped. Additionally or alternatively, the fluid measurement / safety monitor component 3408 can communicate with a mechanical occlusion device (not shown) to stop the flow of infusion fluid to the patient 3412.

In addition or as an alternative, the fluid measurement / safety monitor component 3408
Can receive feedback on flow rate and patient condition parameters such as heart rate, body temperature, vital signs, and the like. Fluid Measurement / Safety Monitor Component 34
If any of the parameters monitored by 08 are outside the predetermined range, an alert such as a text message or email may be sent to, for example, a monitoring device, remote communicator, other monitoring client, smart phone, tablet, PC , Emitted to tablets and computers. Additionally or alternatively, the mechanical fluid, fluid measurement / safety monitor component 3408 communicates with a mechanical occlusion device (not shown) to provide patient 3
The flow of injected fluid to 412 can be stopped.

FIG. 60 illustrates several electronic patient-care devices 3502, 35, according to embodiments of the present disclosure.
4 is a block diagram of a system 3500 for communicating with 04, 3506, 3508, 3510. FIG.

System 3500 includes a wireless or USB based dock or hub 3518. Dock 3518 is coupled to infusion counter 3502, infusion pump 3504, wearable system monitor 3506, pill dispenser 3508, and other devices 3510. Other devices may be various patient condition devices such as, for example, pulse oximeter devices, heart rate monitor devices, blood pressure devices, and body temperature devices. Devices 3502, 3504, 3506, 3508, 3510 communicate with a monitoring client, eg, tablet 3514, and then communicate with one or more servers 3516. One or more servers 3516 may be, for example, of the equipment service 8 of FIG. It may be a server.

Wireless or USB dock 3518 and devices 3502, 3504, 3506, 3508
, 3510, for example, WiFi, Bluetooth, low energy
Bluetooth, Zigbee, a communication link capable of ranging, short-range communication, RFID communication, and the like may be used.

The tablet 3514 may be a primary program and a monitoring interface in some embodiments of the present disclosure. Tablet 3514 can be configured for a single patient, or when docked in dock 3518, or tablet 35
14 can be configured when the patient is identified (eg, the patient ID is tablet 3
Tablet 3514 can download patient treatment parameters after being manually entered into 514 through an RFID reader, barcode reader, etc.).

The tablet 3514 can communicate patient condition parameters or patient treatment parameters to one or more servers 3516. One or more servers 3516 may store patient condition parameters or patient treatment parameters. Tablet 3514
Can communicate patient care parameters, such as patient condition parameters or patient treatment parameters, in real time (ie, with at least one time constraint such as a deadline).

The tablet 3514 can be connected to or docked to the dock 3518 wirelessly through a USB cable. Tablet 3514 receives power and data from dock 3518 through one or more wired communications in some embodiments.

Infusion pump 3504 can be a low flow infusion pump (eg, capable of delivering 0.1-10 milliliters per hour), a medium flow infusion pump (eg, capable of delivering 10-300 milliliters per hour), high It may be a flow infusion pump (e.g. capable of delivering 300-1000 milliliters per hour), an infusion pump that switches between various flow settings, or some combination thereof. Infusion pump 3504 is connected to hub 3 through the receiver.
518 can be inserted. That is, hub 3518 may also be a dock (not shown in FIG. 60). Infusion pump 3504 receives power and data from hub 3518 through one or more wired communications in some embodiments of the present disclosure. The infusion pump 3504 can be configured to undock from the hub 3518 and can continue to operate while the patient is holding it. Infusion pump 3504 can be sent to the pharmacy for configuration and / or attached to an infusion bag (also referred to as an intravenous bag). In some embodiments, the infusion pump 3504 can be configured to operate only on certain bags and / or certain patients.

The wearable system monitor 3506 may be the wearable system monitor 131 of FIG. 1, 3, 5, 7, 8, or 9. In some embodiments, the wearable system monitor 3506 can read patient identification information from the smart arm band, eg, via RFID, and other devices 3502, 3504, 350.
8, 3510 can provide watchdog function to track flow rate,
It may include a call button that detects air, monitors vitals, or is integrated thereon. The wearable system monitor 3506 can block the flow in response to an error condition. Wearable system monitor 3506 can communicate wirelessly with hub 3518 or infusion pump 3504.

FIG. 61 illustrates patient care devices 3704, 3 via USB connection, according to an embodiment of the present disclosure.
Electronic patient care system 370 having a dock 3702 connectable to 706A-3706C
It is a block diagram of 0. System 3700 includes a dock 370 that receives a tablet 3708.
2 is provided. The dock 3702 is coupled to a hub 3710 that includes a USB connection, and a USB
It can be connected to docks 3712 and 3714 through connections. Dock 3712 receives pill dispenser 3704. Dock 3714 includes infusion pumps 3706A-37.
Receive 06C. Docks 3712 and 3714 are the devices 3 docked there
Power is provided to 704, 3706A-3706C.

The dock 3702 supplies power to the internal battery of the tablet 3708 and charges it.
Dock 3702 is also coupled to USB hub 3710, and tablet 3708 is the host. Flow meter 3716, such as an infusion counter, and wearable system monitor 3
718 may wirelessly communicate with tablet 3708 via an antenna and transceiver on tablet 3708 and / or via a transceiver and antenna on dock 3702. As can be appreciated in view of this disclosure, flow meter 3716 and wearable system monitor 3718 includes transceivers and antennas such as communication module 124 and antenna 122 of FIG. 1 to facilitate wireless communication with tablet 3708. It can be operably coupled or can be integrated therein.

FIG. 62 is a process diagram 3800 illustrating several stages of electronic patient care according to an embodiment of the present disclosure. Process diagram 3800 may be, for example, an electronic patient care method for use in the exemplary systems of FIGS. 1, 3, 5, 7, 8, and 9. Process diagram 380
0 includes stages 3802-3810. In step 3802, the physician reviews the patient data and previous treatment history in the electronic medical record, and the computerized physician order entry server 3812.
A step of entering a prescription in the box.

Stage 3804 is where the pharmacist prepares the drug container and prints the printed label and / or RFID.
Identifying a container and selecting a delivery device. Stage 3806 includes transporting the container to a patient or surgical ward and tracking the container, eg, controlled substance. Stage 3
808 includes a nurse setting and adjusting the treatment and checking 5R (right patient, right drug, etc.). Stage 3810 includes delivering the medication, recording the treatment history in an electronic medical record, raising an alarm or alarm, and monitoring the patient, eg, monitoring the patient.

63 shows infusion pump 3902 docked in dock 3904, pill dispenser 3906 docked in dock 3908, and dock 3 via USB cable.
A system 3900 having a hub 3910 for interfacing with 904 and 3908 is shown. The hub 3910 also receives a tablet 3914
Interface with dock 3912. In addition or alternatively, the tablet 3914 is in wireless communication with the hub 3910. The tablet 3914 can issue an alarm and / or alarm when the mode or technology used for communication changes, for example, when it changes from wired to wireless or wireless to wired.

The hub 3910 includes a display 3916 and provides an interface between the tablet 3914 through the dock 3912. Hub 3910 provides display 391 for programs, setup guidance, status, display alarms, display alarms, etc.
6 (which may be a touch screen) can be supported.

In some embodiments of the present disclosure, the hub 3910 enables a patient safety circuit that allows the system 3900 to be completely fault tolerant to any failure or error that may occur in or related to the tablet 3914. The user interface required for patient safety is either on the hub 3910 or on the display of the patient care devices 3906 and 3902 (eg, infusion pump 390
2 is equipped with a display 3918, but not the device 3906 explicitly shown). For example, the hub 3910 may provide a user confirmation of the infusion rate and medication delivered before sending a request or command for the infusion rate to the infusion pump 3902 (eg, hub 3
Via a 910 touch screen) may be necessary. In addition or alternatively, in some embodiments, infusion pump 3902 may be (eg, infusion pump 3
Requires user confirmation of infusion rate and drug delivered prior to operation (via 902 touch screen).

Hub 3910 can sound audible indicators for help guidance, alarm prompts, alarm prompts, and can include an independent safety system to monitor safety critical tasks, resulting in alarm or alarm conditions A fail-safe system for bringing the patient-care device to a safe state in the event that it is in the case of a time-critical patient-care device, such as a real-time patient-care device Can be equipped with an independent time-based or real-time clock, and can be equipped with a battery backup to power the patient-care device through the USB cable, in which the circuit is charged to charge the internal battery Equipped with a battery Door can be.

The hub 3910 can include a power input module for an AC or DC power source and can receive power from a standard AC power outlet. Hub 3910 is an IEC-60
The requirements for insulation and electromagnetic compatibility according to 601 can be met. Hub 3
910 AC power to regulated DC power used to charge internal backup batteries, provide power to various circuits, or power patient care devices 3906, 3902 via respective USB cables Convert.

Hub 3910 is IEC-60601 compatible, selectable or programmable so that an attached patient-care device can request power parameters such as voltage, duty cycle, DC or AC power, etc. from hub 3910 A power supply can be provided. The hub 3910 can comprise one or more independent power sources independent of the primary as defined by IEC-60601.

The hub 3910 includes a backup battery that can be used to supply power via a USB cable or other cable (not explicitly shown). Hub 391
0 can have its own battery charging circuit, for example a constant voltage / constant current charging circuit.

The display 3916 of the hub 3910 is a patient care device 3902, 3906, 39
Based on the signal received from 20, an alarm or warning can be displayed. For example, if the hub 3910 can periodically query the patient-care device 3902, 3906, 3920 and the hub 3910 does not receive a response from one or more of the patient-care devices 3902, 3906, 3920 or the tablet 3914, Alternatively, if one or more of the patient-care devices 3902, 3906, 3920 or the tablet 3914 becomes unresponsive, the display 3914 displays an alarm or alarm. The alarm can indicate to the user that the patient-care device is unresponsive. The patient-care device is via visual mapping of the patient-care device on the monitoring device via the serial number, infusion pump path, drug being delivered by the infusion pump, letters or numbers displayed on the patient-care device. And the others can be identified by the monitoring client. For example, the monitoring client 3914 can display a layout diagram of the patient-care devices 3902, 3906, 3920 on its screen to provide a visual mapping of the device. The device, dock, or hub in question can then be shown as a red flash device that indicates to the user the device that is the subject of the alarm and / or alarm. The hub 3910 can also include status light, LEDs, speakers, vibrators, or other visual / audio indicators.

Hub 3910 may comprise other input devices such as buttons or switches, touch pen input, for example. In some embodiments of the present disclosure, only the hub 3910 is
Issue alarms and / or alarms to patient-care devices, but in other embodiments,
The patient-care device 3902, 3906, 3920 or tablet 3914 issues an alarm and / or alarm.

Hub 3910 may comprise two separate processors, each being a watchdog for each other. The hub 3910 can also include various sensors such as an atmospheric temperature sensor, a pressure sensor, and a humidity sensor. The sensor of the hub 3910 may be redundant to the sensor on the patient-care device 3902, 3906, 3920 or tablet 3914, or the hub 3910 may be connected to the patient-care device 3902, 3906, 3920 or tablet 3914 of the hub 3910. Access to measurements made by the sensor can be provided.

Hub 3910 may include, for example, WiFi capability, Zigbee, Bluetooth, low energy Bluetooth, Xbee, near field communication, ranging devices, and the like. The hub 3910 can also include various wired interfaces such as RS-232, SPI, CAN, USB, Ethernet connectivity, for example.

The hub 3910 may also include a patient-care device 3902,
3906, 3920 or tablet dock 3912, or one on patient care device 3902, 3906, 3920 or tablet dock 3912 that can cause a particular device that has failed to enter fail-safe mode Or a plurality of failsafe lines can be included. For example, an electrical conductor (ie, a wire or line) may be present between one or more coupled to a voltage source through a hub 3910 and a resistor (ie, the line is “high”); This circuit can couple the conductor to ground (the conductor can be so-called “pull down”). In some but not all of the present disclosure, patient care devices 3902, 3906, 3
When a patient-care device disclosed herein, such as one or more of 920 or a monitoring client such as tablet 3914, enters fail-safe mode, the software
Only important ones (predetermined set) of the routine are enabled and / or only important circuits (predetermined set) are powered. In some but not all embodiments, all circuits except the infusion pump motor driver circuit, such as a radio, display, display driver, or other circuit, can be disabled. In addition, or as an alternative, in some, but not all, disabling some software routines or functions that are not required when a particular fail-safe mode is entered. Software that displays configuration information can be disabled, such as in an infusion pump.

The hub 3910 can also be used to identify a patient, nurse, or drug to allow access to the system 3900 or using facial recognition software or by reading a barcode (2D or 3D). A camera 3922 can be provided that can be used. The camera 3922 of the hub 3910 can also read drug information and check the accuracy against one or more servers 3926 to ensure that the drug is being delivered to the correct patient. Additionally or alternatively, the hub 3910 can also include a microphone 3924 for identifying a patient, nurse, or caregiver using voice recognition software.

The hub 3910 can also be a bar code reader, RFID reader, or magnetic strip
A scanner 3928 which is a reader can be provided. The scanner 3928 can be used to allow access to the system 3900 or to identify a patient, nurse or drug. The scanner 3928 of the hub 3910 can also read drug information and check the accuracy against one or more servers 3926 to ensure that the drug is being delivered to the correct patient.

The hub 3910 also includes one for execution by one or more processors therein.
One or more components can be provided. The hub 3910 is at a given interval
If the patient-care device receives a communication query (e.g., a call and answer challenge to each patient-care device every 5 seconds or other appropriate interval, hub 3910 receives no response, hub 3
910 monitors the health of various power supply voltages, and monitors the voltage level to authenticate that it is responding to "pull" the safety line (indicating that an error condition exists) A watchdog circuit for checking and authenticating that the data being transmitted through the hub 3910 is not corrupted, and internal and route packets sent to the tablet 3914 or patient care device disclosed herein. A data integrity check to check and a range checker that allows checking of the programmed threshold can be provided. The hub 3910 can use data integrity checks.

The hub 3910 can monitor the tablet 3914 and can separately alert if an error occurs in the patient-care device. In some embodiments of the present disclosure, the hub 3910 can include all of the safety critical circuitry and software, such that the system 3900 is completely fault tolerant to a tablet 3914 failure, and / or Fully fault tolerant for all failure modes of tablet 3514.

The hub 3910 can include an application programming interface (API) to display data on the display 3916 or tablet 3914. The API can include a secure data class. The patient-care device can be displayed on the display 3916 of the hub 3910 using an API.
The patient-care device can send a message to the tablet 3914 that instructs the tablet 3914 how to display the interface to the patient-care device. Additionally or alternatively, the hub 3910 sends a message to the tablet 3914 instructing the tablet 3914 to download the application from one or more servers 3926 to display the user interface on the tablet 3914. The hub 3910 can be connected via a USB cable or wirelessly (eg,
Any of the patient care devices (using the pairing described herein)
This message can be sent when first connected to 10. In addition to it,
Or alternatively, the hub 3910 sends instructions to the tablet 3914 to display a user interface for interfacing with the identified patient-care device.

FIG. 64 illustrates the use of a scanner 4006 and / or infusion pumps 4004A-40.
For confirmation using one or more interfaces of 04C, the electronic medical record server of one or more servers 4002 inputs a prescription and sends the prescription to infusion pumps 4004A-
A system 4000 is shown that allows transmission to one infusion pump at 4004C. The prescription is sent to the infusion pumps 4004A to 4004C via the application server 4
It can be transmitted from the EMR record on 002. The application may be on a bedside computer 4008 that can be used to determine clinician compliance with a prescription. In some embodiments, the application is on a monitoring client. Bedside computer 4008 includes infusion pumps 4004A-400.
An application that interfaces with the EMR server of one or more servers 4002 through a standard API for downloading prescriptions and / or treatment plans for use on 4C. The API can include a secure data class. In some additional embodiments, the hub communicates with the server 4001 through middleware as described above. Additionally or alternatively, referring to FIG. 65, an application for interfacing with an EMR server may be on a tablet 4102 as shown in FIG. Although the scanner 4104 is shown as being coupled to the hub 4106, it can also be attached to a patient-care device 4108A-4108C, or a tablet hub 4110. Scanner 41 to identify medication
Rather than using 04, the camera 4112 can be used to identify the drug by reading a 2D or 3D barcode on the drug, eg, on an infusion bag or pill container.

In FIG. 66, a system 4200 is shown. Patient care devices 4202A-420
One patient-care device of 2C can broadcast patient-care parameters, eg patient treatment parameters such as infusion rate, to approved or paired devices (see FIG. 67). For example, infusion pump 4202A, hub 4204, remote communicator 4206, nurse station 4208, or bedside computer 4
210 can receive a signal broadcast from a temperature probe or the like (eg, infusion pump 4202A is licensed for the temperature probe). Data can have different levels of encryption, so that not all data is accessible to all clients (eg, a device registered with another device has a minimum level of security priority) May need). The broadcast signal may be the same signal received by the tablet 4212 or a subset thereof. Broadcast messages can use cross-platform protocols such as http, https, etc.

FIG. 67 shows a timing diagram 4300 of communications for the system 4200 of FIG. 66 according to an embodiment of the present disclosure. Timing diagram 4300 illustrates communication using an electronic medical record application programming interface running on tablet 4212. In some embodiments of the present disclosure, the missed drug reduction system and / or guardrail (or its cached version) is the hub 4204 or infusion pump 420.
Provide redundant patient safety when present on one of the infusion pumps 2A-4202C and the system 4200 is not in operative communication with the electronic medical record on one or more servers 4214. Can do.

Timing diagram 4300 includes operations 4302-4354. During operation 4302, the user updates a prescription for an application (app) in a computer or monitoring client, eg, a tablet. In operation 4304, the updated prescription is communicated to one or more servers in the EMR. Action 4306 checks the prescription in the DERS and
For example, predetermined criteria are used to determine whether it is safe for any patient or a particular patient. Act 4308 communicates safety information from the DERS system to an application on the monitoring client or computer application. Action 4310 is
Receive safety information. Act 4312 communicates the prescription from the tablet or computer application to the hub API in act 4314 via the hub's EMR application programming interface (API). The API can include a secure data class. Act 4316 communicates the prescription to the pump in act 4318 and then communicates the prescription to the pump in act 4320. Action 432
2 requests user confirmation of the prescription on the pump user interface, for example via a touch screen. After confirmation, the confirmation is communicated to the pump at operation 4324 and received at operation 4326. During action 4326, treatment is initiated and the status information is
28 to the pump status UI and displayed to the user at operation 4330.

Status information is also communicated in operations 4332 and 4334. In act 4326, the status information is received by the hub broadcasting the status via WiFi in act 4338. The tablet application displays the status information in operation 4340 in operation 4342.
Receive from communication in the middle state. During operation 4346, status information is interfaced via EMR API, communicated to the tablet or computer app via operation 4348, and received at operation 4350. The status information is EMR in action 4352.
Communicated to the database and updates the EMR database in operation 4354. In some embodiments, communication between the EMR and the Allscript tablet / computer app or hub is through middleware (eg, middleware on the monitoring server 3 of FIG. 1).

68A-68B are a method 43 illustrating the timing diagram of FIG. 67 according to an embodiment of the present disclosure.
The flowchart figure of 35 is shown. Method 4335 includes acts 4301-4333.

Act 4301 updates the patient prescription in the application. Act 4303 queries the electronic medical record on the server from the application to determine the safety of the updated prescription for the patient. Act 4305 communicates the determined safety of the updated prescription for the patient from the server to the application. Act 4307 communicates the updated prescription from the application to the hub API. The API can include a secure data class. In some embodiments, the communication of operation 4307 is a middleware (eg, FIG. 1).
Middleware on the monitoring server 3). Act 4309 determines the safety of the updated prescription within the hub (eg, in some embodiments, a DERS check and / or a prescription check). In some embodiments, operation 4309 is optional. In some embodiments, operation 4311 communicates the updated prescription from the hub to the pump. In some embodiments, operation 4311 is optional.

Act 4313 displays an updated prescription confirmation request on the pump user interface. Act 4315 confirms the updated prescription on the pump user interface. Act 4317 pumps fluid in accordance with the updated prescription. Act 4319 displays the parameters on the pump user interface. Act 4321 communicates parameters from the pump to the hub. Act 4323 wirelessly broadcasts the parameters from the hub. Act 4325 communicates the parameters from the hub to a monitoring client, eg, a tablet. Act 4327 displays the parameters on the user interface of the monitoring client. Act 4329 communicates parameters and / or updated prescriptions from the hub to the application using the hub API. Act 4331 communicates parameters and / or updated prescriptions from the application to the server. Act 4333 updates the parameters and / or the updated prescription in the electronic medical record in the server. In some embodiments, operation 4333 includes middleware (eg,
(Middleware on the monitoring server 3 in FIG. 1).

FIG. 69 shows an electronic patient care system 4400, and FIG. 70 shows an electronic patient care system 4500. In some embodiments, the electronic medical record application may reside on the tablet 4402 as shown in FIG. 69 and / or on the bedside computer 4502 in FIG. Additionally or alternatively, in some embodiments, the electronic medical record application resides in a hub, infusion pump, tablet, patient care device, some other device or apparatus, some combination thereof May or may not be utilized. The scanner 4404 can be used to determine whether a medication, eg, an infusion bag, matches the prescription prescribed for the identified patient, for example, the scanner 4404 can be used to identify the patient.

FIG. 71 illustrates that infusion pump 4408A and / or hub 4406 is replaced by tablet 4402.
Illustrates a timing diagram 4600 illustrating, in accordance with some embodiments of the present disclosure, how to request which prescription was prescribed to a patient by querying an electronic medical record application running on the tablet 4402. ing. The user can enter patient identification information or the patient identification information is scanned using the scanner 4404. An electronic medical record application running on the tablet 4402 can request a prescribed medication from one or more servers 4410. The tablet application may request the user to select from a list of available prescriptions when there are a large number of prescriptions, eg, a number of infusion pump-based prescriptions.

Timing diagram 4600 illustrates operations 4602-4652. Act 4602 uses the monitoring client during act 4604 to request a list of prescriptions for the patient after identifying the patient. Action 4602 “pulls” prescription information from the monitoring client.
. Patients can be identified using barcode scanners, RFID interrogators, voice or facial recognition, or by manual input. The tablet communicates the patient's ID during operation 4606 to the 4608 tablet or computer application using the EMR API. The API can include a secure data class. The patient identification information is communicated to the EMR database at operation 4610 and at operation 4612 E
The MR API communicates the list of prescriptions during operation 4614 and is received by the EMR program running on the monitoring client or computer application at operation 4616 and then communicates them to the monitoring client application at operation 4618. Communication between the EMR tablet / computer application and the EMR database may be via middleware (eg, middleware on the monitoring server 3 of FIG. 1).

A monitoring client, such as a tablet, may display various prescriptions for the patient for user selection at operation 4620. The selected prescription is communicated to the hub at operation 4622 and the prescription can be checked at operation 4624 and the operation 46
At 26, the prescription can be communicated to the pump. The pump is enabled at operation 4628 either automatically by ensuring that the prescription is within predetermined criteria using, for example, DERS, or by requesting user authentication. In addition or alternatively, the user can validate the prescription using the pump UI.

The validated prescription of act 4628 is communicated to the hub in act 4630 and act 4
At 632, this is communicated to the monitoring client application at operation 4634. At act 4636, the user can approve the prescription and then communicated to the hub at act 4638. Approved prescription communication occurs at operation 4640 and is communicated to the pump at operation 4642. In operation 4644, the pump communicates the prescription to the pump UI in operation 4646, and the user can confirm the prescription in operation 4642. A confirmation is sent to the pump at operation 4650. Act 4652 performs the therapy.

72A-72B show a flowchart diagram of a method 4653 illustrating the timing diagram of FIG. 71 according to an embodiment of the present disclosure. Method 4653 includes acts 4655-4691.

Act 4655 determines patient identification using a monitoring client application in a monitoring client, eg, a tablet. Act 4657 communicates patient identification information from the monitoring client application to the API. Act 4659 queries the API for an electronic medical record on the server to determine at least one prescription for the patient.
In some embodiments, operation 4659 is middleware (eg, monitoring server 3 of FIG. 1).
Refer to the electronic medical record through the middleware above. Act 4661 communicates the determined at least one prescription for the patient from the server to the API. Act 4663 communicates the determined at least one prescription for the patient from the API to the monitoring client application in the monitoring client. Act 4665 optionally displays a user-selectable list of at least one prescription on the user display of the monitoring client. Act 4667 optionally selects a prescription for at least one prescription using a display on the monitoring client. Act 4669 communicates the prescription selected from the monitoring client and / or at least one prescription to the hub.

Act 4671 communicates the selected prescription and / or at least one prescription from the hub to the pump. Act 4673 validates the selected prescription and / or at least one prescription. Act 4675 communicates the selected prescription and / or at least one prescription from the pump to the hub. Act 4677 communicates the prescription selected from the hub and / or at least one prescription to the monitoring client application of the monitoring client. Act 4679 displays the validated prescription confirmation request on the monitoring client user interface. Act 4681 verifies the prescription enabled on the user interface of the monitoring client. Act 4683 communicates the validated prescription from the monitoring client application of the monitoring client to the hub. Act 4585 communicates the validated prescription from the hub to the pump. Action 4687
Displays a validated prescription confirmation request on the pump user interface. Act 4689 confirms the validated prescription on the pump user interface. Act 4691 pumps fluid in accordance with the validated prescription.

FIG. 73 shows a timing diagram 4700 when a prescription is pushed to the infusion pump 4408A. Additionally or alternatively, the electronic medical record application can also be placed on a device hub 4406 that maintains an electronic medical record application programming interface across multiple devices. The method 4700 is an operation 470.
2-4726. In some embodiments, middleware (eg, monitoring server 3 of FIG. 1) between the EMR database and the EMR tablet / computer application.
(Middleware above) can be used.

In operation 4702, the user updates the prescription within an EMR application on a monitoring client, eg, a tablet or computer. The update may be a new prescription for the modified prescription. The updated prescription is communicated to the application at operation 4704. The application processes the update at operation 4706 and communicates it to the EMR database at operation 4719. In operation 4708, DERS checks the updated prescription. The updated prescription is communicated to the EMR monitoring client or computer application at operation 4710 and processed at operation 4712. After processing, in operation 4714, the updated prescription is communicated to the monitoring client application via the EMR API and processed in operation 4721. The monitoring client communicates this to the pump in operation 4716. The pump operates 471
Process the updated prescription at 8 and communicate it to the pump at operation 4720.
The user confirms the updated prescription at operation 4722 and is communicated to the pump at operation 4724. In operation 4726, therapy is performed.

FIG. 74 shows a flowchart diagram of a method 4701 illustrating the timing diagram of FIG. 73 according to an embodiment of the present disclosure. Method 4701 includes acts 4703-4717.

Act 4703 updates the patient's prescription within the application. Action 4705 is
To confirm the safety of the updated prescription for the patient, the electronic medical record on the server is queried from the application. Act 4707 communicates the determined safety of the updated prescription for the patient from the server to the application. Operation 4709 is the API of the monitoring client
Communicate the updated prescription from the application. Act 4711 communicates the updated prescription from the monitoring client to the pump. Act 4713 displays an updated prescription confirmation request on the pump user interface. Act 4715 confirms the updated prescription on the pump user interface. Act 4717 pumps fluid in accordance with the updated prescription.

FIG. 75 shows a timing diagram 4800 where the hub 4406 communicates to the infusion pump 4408A for prescription user confirmation. That is, method 4800 of FIG. 75 is similar to method 4700 of FIG. 73, but the hub includes an EMR API, which is processed in operation 4802.

FIG. 76 shows a flowchart diagram of a method 4801 illustrating the timing diagram of FIG. 75 according to an embodiment of the present disclosure. Method 4801 includes acts 4803-4817.

Act 4803 updates the patient prescription within the application. Action 4805 is
To confirm the safety of the updated prescription for the patient, the electronic medical record on the server is queried from the application. Act 4807 communicates the determined safety of the updated prescription for the patient from the server to the application. Act 4809 communicates the updated prescription from the application to the hub API. Act 4811 communicates the updated prescription from the hub to the pump. Act 4813 displays an updated prescription confirmation request on the pump user interface. Act 4815 confirms the updated prescription on the pump user interface. Act 4817 pumps fluid in accordance with the updated prescription.

77 and 78 illustrate an embodiment in which the hub 4406 communicates with one or more servers 4410, for example, to determine whether a prescription is safe for a patient or the like.

FIG. 79 shows a timing diagram 5100 for user confirmation of a prescription on the user interface of pump 4408A. Timing diagram 5100 illustrates operations 5102-51.
A method comprising 30 is performed. Action 5102 uses the monitoring client app to
A prescription is requested from R, communicated in operation 5104 and processed in operation 5106. Request 5102 can be made via patient identification. The tablet communicates the request to the EMR database via the EMR API at operation 5108. Act 5110 processes the request and returns it via the EMR API in act 5112. The monitoring client processes the prescription received from the EMR database in operation 5114.

The monitoring client communicates the prescription to the pump at operation 5116, validates the prescription at operation 5118, and communicates it to the monitoring client application at operation 5120. The user can approve the prescription in action 5122 and action 5122
At 124, the pump and pump UI are communicated. In operation 5126, the user can confirm the prescription on the pump. The confirmation is communicated to the pump at operation 5128 and then performed at operation 5130.

80A-80B show a flowchart diagram of a method 5101 illustrating the timing diagram of FIG. 79, according to an embodiment of the present disclosure. Method 5105 may be performed by operations 5103-51512.
8 is included.

Act 5103 determines patient identification using a monitoring client application in a monitoring client, eg, a tablet. Act 5105 queries an electronic medical record on the server from the API to determine at least one prescription for the patient. Action 51
07 communicates the determined at least one prescription for the patient from the server to the monitoring client application. Act 5109 optionally displays a user-selectable list of at least one prescription on the user display of the monitoring client. Act 5111 optionally selects a prescription for at least one prescription using a display on the monitoring client. Act 5113 communicates the prescription selected from the monitoring client and / or at least one prescription to the pump. Act 5115 validates the selected prescription and / or at least one prescription. Act 5117 communicates the validated prescription from the pump to the monitoring client. Act 5119 displays the validated prescription confirmation request on the monitoring client user interface.

Act 5121 verifies the prescription enabled on the monitoring client user interface. Act 5123 communicates the validated prescription from the monitoring client to the pump. Act 5125 displays the validated prescription confirmation request on the pump user interface. Act 5127 confirms the validated prescription on the pump user interface. Act 5129 pumps fluid in accordance with the validated prescription.

FIG. 81 shows a timing diagram 5200 in which the hub 4406 communicates with one or more servers 4410 to communicate with an electronic medical record. The method implemented by timing diagram 5200 includes acts 5202-5238. In some embodiments, middleware (e.g., between the EMR database and the EMR tablet / computer application)
Middleware on the monitoring server 3 of FIG. 1 can be used.

In operation 5202, the user requests a prescription from the EMR via the monitoring client application, communicated in operation 5204, and processed by operation 5206. The monitoring client application sends the hub EMR AP in operation 5208.
Interfacing with I and processed by operation 5210. The EMR API requests a prescription at operation 5212 and is processed at operation 5214.

The prescriptions are communicated to the hub at operation 5216, processed at operation 5218, and communicated to the monitoring client application at operation 5220 and processed at operation 5222. The prescription is communicated to the pump in operation 5224 and the operation 52
At 26. The activation is communicated at act 5228 to act 5230.
The user is approved at, and communicated to the pump at operation 5232. The user operates 5
The prescription can be verified at 234 and communicated at act 5236 to act 5238.
The treatment is started in the pump.

82A-82B show a flowchart diagram of a method 5201 illustrating the timing diagram of FIG. 81 according to an embodiment of the present disclosure. Method 5201 includes acts 5203-5233.

Act 5203 determines patient identification information using a monitoring client application in a monitoring client, eg, a tablet. Act 5205 communicates patient identification information from the monitoring client application to the API on the hub. Act 5207 queries an electronic medical record on the server from the API to determine at least one prescription for the patient. The operation 5205 and / or 5207 can use middleware (for example, middleware on the monitoring server 3 in FIG. 1). Act 5209 communicates the determined at least one prescription for the patient from the server to the hub API. Act 5211 communicates at least one prescription determined from the hub API to the monitoring client application. Act 5213 optionally displays a user-selectable list of at least one prescription on the user display of the monitoring client. Act 5215 optionally selects a prescription for at least one prescription using a display on the monitoring client. Act 5217 communicates the prescription selected from the monitoring client and / or at least one prescription to the pump. Act 5219 validates the selected prescription and / or at least one prescription. Act 5221 communicates the validated prescription from the pump to the monitoring client. Act 5223 displays the validated prescription confirmation request on the monitoring client user interface.

Act 5225 verifies the prescription enabled on the monitoring client user interface. Act 5227 communicates the validated prescription from the monitoring client to the pump. Act 5229 displays the validated prescription confirmation request on the pump user interface. Act 5231 confirms the validated prescription on the pump user interface. Act 5233 pumps fluid in accordance with the validated prescription.

FIGS. 83-89 illustrate some additional embodiments of an electronic patient care system according to some embodiments of the present disclosure. 83 shows the tablet 3514 and / or the hub 3
To display some of the patient's electronic medical records on the 804 user interface,
System 5300 is shown in which an electronic medical record application interfaces with an electronic medical record on one or more servers 3516. A subset of data from an electronic medical record received from one or more servers 3516 (eg, medication being delivered by infusion pump 3504) can be displayed on a display on infusion pump 3504. Additionally or alternatively, in some embodiments, a subset of data from the electronic medical record can be cached on the hub. In some embodiments, the hub can communicate with the medical IT system through middleware (eg, middleware on the monitoring server 3 of FIG. 1).

FIG. 84 illustrates an electronic medical record application running on one or more servers 4410 to display some of the patient's electronic medical records on the user interface of the bedside computer 4204 and / or the hub 4406. A system 5400 for interfacing with a recording is shown. A subset of data from an electronic medical record received from one or more servers 4410 (eg, medication being delivered by infusion pump 4408A) can be displayed on a display on infusion pump 4408A. Additionally or alternatively, in some embodiments, a subset of data from the electronic medical record can be cached on the hub and / or bedside computer.
In some embodiments, the hub can communicate with the medical IT system through middleware (eg, middleware on the monitoring server 3 of FIG. 1).

FIG. 85 illustrates a system 5500 that may be an independent system or the system 5400 of FIG. 84 when communication with one or more servers 4410 is interrupted. FIG. 86 illustrates a system 5600 that may be an independent system or the system 5400 of FIG. 84 when communication with one or more servers 4410 is interrupted. 85-86, a prescription can be programmed into systems 5500, 5600 without access to the electronic medical record server of one or more servers 4410. The prescription can be adjusted on tablet 4402, bedside computer 4502, or infusion pump 4408A. Hub 5804 is a scanner, bedside
The computer 4502 and / or the infusion pumps 4408A-4408C can communicate wirelessly and / or via a wired connection. In some specific embodiments, the monitoring client 4402, hub, and / or bedside computer may be an EMR.
It can be programmed without data, but it can also be compared to a local version of the guardrail.

Referring to the drawings, FIG. 87 shows a system 5700 for electronically treating a patient. Hub 5702 communicates with one or more servers 5704 using a networking API or local API to a resident electronic medical record application that handles communication to one or more servers. Pump 5706 to program and execute therapy
A-5706C is used. The hub 5702 can communicate with the scanner and / or medical IT system 5704 wirelessly and / or via a wired connection.

FIG. 88 shows a system 5 having no tablet or bedside computer.
800 is shown. System 5800 may be system 5700 of FIG. 87 when communication 5704 to one or more servers 5704 is not available. Infusion pump 5802A is programmed using the user interface on pump 5802A, and a cached set of predetermined safety standards (eg, guardrails) is stored in hub 58.
04 or in pumps 5802A-5802C. The predetermined safety criteria can be based on the delivered drug, patient, allergy, or memorized drug contraindications, and can prevent unsafe treatment settings from being delivered to the patient. Hub 5804 is a scanner and / or
Or, can communicate with infusion pumps 5802A, 5802B, and / or 5802C wirelessly and / or via a wired connection.

FIG. 89 shows a system 5900 with several infusion pumps. System 5
900 may be the system 5800 of FIG. 88 when communication with the hub is not available. Infusion pumps 5902A-5902C can be controlled directly using each respective user interface on the pump, and a predetermined set of criteria (eg, to ensure that the drug is not delivered outside of the predetermined criteria) DERS) can be cached in, in some embodiments, DERS is not cached in infusion pumps 5902A-5902C, and / or permanent DERS data is stored within non-volatile memory.

FIG. 90 shows a block diagram of the hub circuit 6000 disclosed herein. Additionally or alternatively, the circuit 6000 can be used in a dock, communication module, or pump disclosed elsewhere herein. The circuit 6000 can interface with a bus or hub to communicate with and / or provide power to a number of devices via a device module interface. Circuit 6000 includes a first failsafe line 6002 that can be activated by device processor subsystem 6004 and a second failsafe line that can be activated by interface processor subsystem 6008.
Includes line 6006. The first and second failsafe lines 6002, 6006 are provided in an OR gate 6010 having an output for the output failsafe line 6012. If either the device processor subsystem 6004 or the interface processor subsystem 6008 detects a failure or error, the first or second failsafe line 6002, 6006 is the output failsafe line 6
012 can be activated. Failsafe line 6012 is responsive to an output occlusion device that can automatically prevent fluid flow through the venous line when receiving a signal from output failsafe line 6012, eg, output failsafe line 6012. In some embodiments, the patient-care device coupled to the device module interface can be a buck, boost, or buck-boost power source, respectively, One or more voltages may be requested from a regulated power supply.

FIG. 91 is a block diagram of a circuit 6100 for interfacing with an infusion pump. Additionally or alternatively, circuit 6100 may be in a dock or hub disclosed herein that connects to a pump, and / or circuit 6100 may be attached to an infusion pump, eg, a communication module. It can be an attachable module. The circuit 6100 can interface with a bus or hub to communicate with and / or provide power to some devices via a device module interface. In some embodiments, the interface
The processor subsystem can communicate with devices coupled to the device hub interface using wireless links and / or near field communication.

FIG. 92 illustrates a tablet dock 6202, infusion pumps 6204A-6204D, a dock 6206 for receiving infusion pumps 6204A-6204D, and a tablet 6208.
FIG. 6 shows a block diagram of an electronic patient care system 6200 comprising In an alternative embodiment,
The tablet 6208 is integrated within the tablet dock 6202. In additional embodiments, docks 6202 and 6206 are integrated with each other. In yet additional alternative embodiments, dock 6202, dock 6206, and tablet 6208 are integrated with each other. Tablet 6208 uses display 6210 to provide a primary user interface. Dock 6202 may include a memory for caching or storing user interface templates, or a user interface program for displaying a user interface on display 6210 for a patient-care device, eg, infusion pump 6204A-6204D. I have. The tablet 6208 can be used to direct a prescription or validate a prescription using one or more servers 6212 having a false medicine reduction system, for example using a scanner 6214. In some embodiments, medical IT system 6212 and dock 6206
There may be middleware (for example, middleware on the monitoring server 3 in FIG. 1).
A user interface template or user interface program is configured to display aggregate data from infusion pumps 6204A-6204D on display 6210, and backs up if one or more of infusion pumps 6204A-6204D fails.・ Work as an alarm. In addition or as an alternative, dock 6
206 alerts using an internal speaker and / or an internal vibration motor if one or more of infusion pumps 6204A-6204D fails.

Dock 6206 can collect data from infusion pumps 6204A-6204D and pass the collected data to tablet 6208. Each infusion pump 62
04A-6204D are provided with respective displays 6216A-6216D.
Displays 6216A-6216D can be used to adjust the flow rate during infusion (predetermined safety criteria can be loaded while the prescription is programmed through tablet 6208). By adjusting the flow rate from zero on the user interface displayed on displays 6216A-6216D, the infusion can be initiated without the prescribed safety standards of the drug error reduction system. The displays 6216A-6216D can also display alarms and alarms, both visually or audibly.

The dock 6206 includes a power input module, a medical grade power supply, and a backup battery. The dock 6206 also includes all of the communication hardware for interfacing with the tablet 6208 and with the medical IT system, ie, one or more servers 6212. The dock 6206 can include movement hardware such as struts, and strut mounting hardware.

In the prescription program, the personal error medicine reduction system setting, for example, the predetermined safety standard is 1
Received directly from one or more servers 6212. The tablet 6208 can be used to facilitate entry of patient ID and medication. Communication between tablet 6208 and one or more servers 6212 can occur through dock 6206. Predetermined safety criteria from the common drug error reduction system are cached on the dock 6206 or in one or more of the infusion pumps 6204A-6204D. If the missed drug reduction system is not available from one or more servers 6212, the locally cached predetermined safety criteria from the missed drug reduction system will be relocated to the network (e.g., WiFi). Updated through.

Dock 6206 includes hub dock 6206 and infusion pumps 6114A-6114.
Has enough batteries to support D's 8-hour operation. The tablet 6110 may or may not have its own battery. In some embodiments, infusion pumps 6204A-6204D may have sufficient batteries (or other backup power) to support data storage and to alert when pulled from dock 6206. it can. This warning capability and a separate battery are also
You can also move to 06.

The pump UI display on one of the displays 6216A-6216D may be small. For example, in some embodiments, displays 6216A-
6216D may be just large enough that only the flow rate can be adjusted. This makes it possible to start the injection without entering any other information. The patient ID and / or drug name can be entered prior to accessing the EMR, so one or more servers 621 can be used if infusion is initiated without the tablet 6208.
Data from the false medicine reduction system or guardrail from 2 is limited. If the infusion is programmed on the tablet and then the tablet is removed from the system, the pump can continue to enforce the guardrail characteristics for the current prescription.

FIG. 93 shows a block diagram of a circuit 6300 for the hub 6206 of FIG. 92 or for the communication modules 124A-124K of FIG. 1, 3, 5, 7, 8, or 9. Additionally or alternatively, the circuit 6300 can be used with the pumps or docks described herein. The circuit 6300 can interface with a bus or hub to communicate with and / or provide power to some devices via a device module interface. A tablet (not shown) coupled to the tablet UI interface 6302 can have its own power supply (not explicitly shown). In some embodiments of the present disclosure, the circuit 6300 can supply power to the tablet.

FIG. 94 shows a block diagram of a circuit 6400 for the hub 6206 of FIG. 92 or for the communication modules 124A-124K of FIG. 1, 3, 5, 7, 8, or 9. Additionally or alternatively, circuit 6400 can be used with the docks or pumps described herein. The circuit 6400 can interface with a bus or hub to communicate with and / or provide power to some devices via a disposable interface. In some embodiments of the present disclosure, the circuit 6400 can supply power to the tablet.

FIG. 95 shows a system 6500 having an extended battery 6502, an infusion pump 6504, and a power adapter 6506. System 6500 can operate without a missed drug reduction system from the server. Display 6508 on infusion pump 6504 can be used to enter drug information and control the infusion rate. In some embodiments, the medication error reduction system data is cached in the memory of the infusion pump 6504 and updated by docking.

FIG. 96 shows a system 6600 having an infusion pump 6504 coupled to a device hub 6602. Infusion pump 6504 has the ability to initiate delivery. The emergency mode with a limited generic error reduction system based on a subset of drugs easily selected from the list can be cached on the device hub 6602 and / or the infusion pump 6504. Infusion pump 6504 can be started without data from the false medicine reduction system.

FIG. 97 shows a system 6700 having a tablet 6702 that allows access to the infusion pump 6504 through the tablet 6702 interface. The tablet 6702 user interface may reside in the device hub 6602. The DERS can reside on the tablet 6702, on the device hub, and / or on the infusion pump 6504. The power adapter 6506 is a tablet 6702
, Device hub 6602, and / or infusion pump 6504.

Device hub 6602 can have physical or wireless communication to tablet 6702. Device hub 6602 can include a cradle (not shown) for tablet 6702. The tablet 6702 is optionally a device hub 6602.
It can be firmly attached to.

Referring to the drawings, FIG. 98 illustrates a dock 6804 (which may be a cradle in some embodiments), pump modules 6802A-6802C, device hub 660.
2 and system 6800 with tablet 6702 plugged into the backplane of dock 6804 (or cradle in some embodiments). In addition, the power module 6804 includes a power input and a reserve battery that can be plugged into or integrated into the dock 6806. Device hub 6602
A master for communication between all other modules and the IT system via one or more servers (not shown). Infusion pumps 6802A-6802C are removable in the embodiment shown in FIG. 98, but other components may be modular or integrated in other embodiments.

Infusion pumps 3802A-3802C typically include a pump mechanism and electronic components that can implement the pump mechanism. In one particular embodiment, the device hub 6602 includes backup power for one or more infusion pumps 3802A-3802C, a processor that collects data and hosts a UI model (eg, user interface template) of the tablet 6702, And modular communication hardware.

The tablet 6702 can include a touch screen 6808. The power adapter 6506 performs AC to DC conversion and includes all power input modules and AC / DC
Coupled to a power module 6804 including a power supply. The power adapter 6506 is optional and / or AC to DC conversion can be incorporated into the power module 6804. The power module 6804 can also include an extended battery for running multiple pump modules. The dock 6806 includes a backplane that connects the various components together.

FIG. 99 illustrates electronic circuitry 6900 of a device hub, eg, device hub 6602 of FIG. 96, according to one embodiment of the present disclosure. In addition or as an alternative, the circuit 6
900 can be used with the pumps, docks, or communication modules described herein. Circuit 6900 can interface with a bus or hub to communicate with and / or provide power to a number of devices via device patient care interface 6916. Circuit 6900 includes various power supplies, user
Interfaces, communications, sensors, and actuators are provided. The circuit 6900 includes an AC main 6902, DC power 6904, eg, induction, wireless power 6906, and an external battery connection 6908.

AC main 6902 may be a direct connection to the main, such as through an AC outlet. AC main 6902 rectifies the AC signal from AC main 6902 and D
Coupled to a power input and charging circuit 6910 that can be converted to a C signal. The DC signal from the power input AC / DC universal supply 6910 is supplied to the DC power input and charging circuit 6912.

DC power 6904 receives DC power from a DC power source, such as power adapter 6506 in FIG. 95, or from a backplane or another external battery (not explicitly shown).

Wireless power 6906 can receive energy wirelessly. For example, wireless power 69
06 can comprise a coil that undergoes a time-varying magnetic field, whereby a voltage across the coil is induced, and the induced AC signal is rectified and smoothed through a smoothing circuit to DC power input / charge circuit 6910. Are combined.

Circuit 6900 also includes a primary battery 6914, an external battery 6908, and a secondary battery 6920.
It has. Primary battery 6914 includes one or more patient-care devices coupled to patient-care device interface 6916 and tablet interface 69.
18 is used to supply power to a tablet (not shown) coupled to 18. Interface 6916 may or may not be connected to the patient-care device through one or more communication technologies, or may be connected to one or more of the patient-care devices.
The tablet interface 6918 can be coupled directly to the tablet or is coupled to the tablet user interface. External battery connection 6908 may be an electrical connector (not explicitly shown) that is adapted to electrically couple with one or more battery cells located within a separate housing of electronic circuit 6900. . The external battery 6908 can supplement or replace the primary battery 6914 when the primary battery 6914 fails. The secondary battery 6920 includes a super capacitor 692.
0 may be sufficient. In some embodiments, the secondary battery 6920 is in a failure mode where power is not otherwise available, eg, the AC main 6902 has failed and the external battery 6908 has been removed or has failed. Can only be used. Secondary battery 69
20 provides sufficient power to the device processor subsystem 6922 to alert through the secondary buzzer 6824.

The circuit consists of a hub regulated power supply 6926, a gated independent power supply from the regulated device power supply 6928,
And various power sources such as a tablet adjustment power source 6930.

Hub conditioning power supply 6926 is used to power the electrical sensor of circuit 6900. For example, the hub conditioning power supply 6926 includes an interface processor subsystem 69.
32 is used to provide a voltage.

The conditioning device power supply 6928 can be gated and can provide one or more independent regulated voltage sources that are routed to one or more patient-care devices coupled to the patient-care device interface 6916. Patient Care Device Interface 6
One or more regulating device power supplies 6928 that are sent via 916 to one or more patient-care devices are monitored by the current sensor 6934 and enabled by the device processor subsystem 6922. In addition or alternatively, the conditioning device power supply 6928 is programmable so that the patient-care device requests a voltage from the device processor subsystem 6922 and then sends the requested voltage to the patient-care device. Program conditioning device power supply 6928 to supply.

Tablet adjustment power supply 6930 provides DC power to the tablet coupled to tablet interface 6918. In addition or alternatively, the circuit 6900 may include
AC main 69 for use by the tablet's internal power supply (not shown in FIG. 99)
The AC signal is passed through 02.

The circuit 6900 also includes a user interface 6936 with a battery indicator 6938, status indicator light 6940, and an LCD touch screen 6942. Battery indicator 6
Reference numeral 938 denotes the charge state and battery state of the primary battery 6914. Status indicator light 6940 indicates the status of the hub, tablet, and any patient-care device coupled to patient-care device interface 6916. The status indicator light 6940 is a patient care device
One or more lights, eg, LEDs, for each patient-care device coupled to interface 6916 can be included. For example, the status indicator light 6940 can include an LED for indicating an alarm condition and another LED for indicating an execution condition.

In some embodiments of the present disclosure, the LCD touch screen 6942 may be the main display and input method for a patient-care device coupled to a patient-care device interface 6916 that does not include a display. In addition or as an alternative, LC
The D-touch screen 6942 displays detailed information regarding the hub, hub circuitry 6900, and / or patient-care device coupled to the patient-care device interface 6916. In addition, the LCD touch screen 6942 can be configured to passively output status information to a large display such as an external TV screen.

Using the primary speaker 6944, the tablet is connected to the tablet interface 691.
Providing voice guidance to a patient-care device coupled to a patient-care device interface 6916 that is not connected to 8 and / or otherwise not available Can do. Secondary buzzer 6
924 is a backup buzzer, primary speaker 6944 is not available or damaged, and / or interface processor subsystem 693
2 provides safety when not available or damaged.

In some embodiments of the present disclosure, hardware button 6946 is used for additional safety input to stop a patient-care device that does not have its own display and a tablet is not available. Or input can be provided.

The tablet interface 6918 is coupled to the interface 6932 and the interface processor subsystem 6932 is connected to the tablet interface 6
A tablet coupled to 918 can communicate. The tablet interface 6918 is coupled to a USB interface 6947 and a Bluetooth interface 6948 (the Bluetooth interface 6948 may be a Bluetooth low energy interface).

Patient Care Device Interface 6916 is SPI, I2C, RS232, RS
The interface is provided to a patient-care device that includes a serial interface 6949, which may be 485, or any other serial protocol. Patient care device interface 6916 also provides a CAN interface 6950, a USB interface 6951, an Ethernet interface 6952, a WiFi wireless interface 6953, and a Bluetooth interface 6954.

Patient care device interface 6916 is a wired device ID 6955 that facilitates patient care device discovery of patient care device type, serial number, class, or performance characteristics, and location within a multi-channel cradle, dock, and / or hub. Can be included. The wired device ID 6955 can be used to determine the optimal or preferred communication protocol based on predetermined criteria. Additionally or alternatively, the method of providing power can be selected as a function of the wired device ID 6955 based on predetermined criteria. The wired device ID 6955 can be determined by communicating with a patient-care device attached to the patient-care device interface 6916 using a “1-wire” device. In addition or alternatively, the patient-care device interface 6916 may also include the patient-care device type, serial number,
Utilize RFID interrogators, near field communication, or other wireless communication links to facilitate class, or performance characteristics, and patient care device discovery of locations within a multi-channel cradle, dock, and / or hub It includes a wireless device ID 6958 that facilitates patient care device discovery that can be done.

Patient care device interface 6916 also includes a digital I / O interface 6956. The digital I / O interface 6956 triggers actuators, enables pins as part of the safety system, or patient care device interface that can be used for use with status light on a hub or cradle 69
Multiple lines can be included for each patient-care device coupled to 16.

The patient care device also includes a failsafe line 6957. Either the interface processor subsystem 6932 or the device processor subsystem 6922 is a failsafe line 6957 that is fed to a logical OR 6977.
Can be triggered. The output of the logical OR 6977 can be coupled to an electromechanical occlusion device (not shown) that is coupled to the patient-care device interface 6916. In an alternative embodiment, a logical AND is used in place of a logical OR 6977 so that both the interface processor subsystem 6932 or the device process subsystem 6922 have a “true” signal as a failsafe line. Before being sent to the patient-care device interface 6916, certain embodiments must match (ie, both are logically true).

Circuit 6900 includes a number of communication links to an IT system or one or more servers 6967. Circuit 6900 includes a WiFi interface 6960, a 3G / 4G interface 6961, and an Ethernet hub or switch interface 6956. The 3G / 4G interface 6961 is connected to the circuit 6900 in the home environment.
To facilitate the operation of the hub. The 3G / 4G interface 6961 can be any portable technology or long-distance communication transceiver, such as code division multiple access (CDMA).
, Time division multiplexing (TDM), WiMax, evolution data optimization (EVDO), orthogonal frequency division multiplexing (OFDM), space division multiple access (SDMA)
, Time division duplex (TDD), time division multiple access (TDMA), frequency division duplex (
FDD) or the like.

The circuit 6900 can be used for patient authentication, clinician authentication, and / or solution / drug authentication (eg, by using a camera to read 2D barcodes), a barcode reader or camera 6962. It has.

The circuit 6900 also includes a transceiver 6963 for RFID, NFC, or other communication protocol for patient authentication, clinician authentication, and / or solution / drug authentication, or to determine the location of a patient-care device. Can be provided.

The circuit 6900 can also include a communication expansion slot 6964, whereby future wired or wireless technology can be modularly inserted into the slot 6964. The slot 6964 can include one or more expansion connectors and is internal to the case of the hub that can be externally connected thereto. Additionally or alternatively, the expansion slot 6964 may be a connection to additional modules that have multiple functions, eg, wireless communication functions, wired communication, and the like.

The circuit 6900 can also include a hub sensor 6965 such as a temperature sensor, a pressure sensor, a humidity sensor, and an accelerometer. Circuit 6900 can also be, for example, a tablet
A vibration motor 6966 for haptic feedback may be provided when a user is warned or instructed to select via a GUI on the tablet coupled to interface 6918.

FIG. 100 shows a block diagram of a circuit 7000 illustrating one embodiment of a mechanism that can be used with a patient-care device such as a pump. That is, the device module interface can interface with, for example, the infusion pump 7 of FIG.
Additionally or alternatively, in some embodiments, the circuit 7000 may be on a hub, communication module, dock, or infusion pump as described herein. Circuit 7
000 can interface with a bus or hub to communicate with and / or provide power to some devices via a device module interface. The circuit 7000 also includes various safety systems. Circuit 7000 provides power backup power and communication methods to tablets and IT systems. Circuit 7000 receives power from an external power adapter (not shown) power supply for the hub and tablet. In some embodiments, the device hub processor subsystem includes an Ethernet connection to the IT system. In some embodiments, the device hub processor subsystem communicates with the monitoring client interface using Ethernet, WiFi, Bluetooth, Bluetooth low energy, near field communication, and the like.

FIG. 101 shows a block diagram of the circuit 7100. The circuit 7100 may be on a hub. Also, the device module interface can interface with, for example, the infusion pump 7 of FIG. In addition or alternatively, in some embodiments, the circuit 7100 may be on a hub, communication module, dock, or infusion pump as described herein. The circuit 7100 can interface with a bus or hub to communicate with and / or provide power to some devices via a device module interface. Circuit 710
0 comprises a WiFi circuit 7102 and an Ethernet connection 7104 for communicating with an IT system (eg, as described herein) for flexibility according to one embodiment of the present disclosure. The speaker 7106 may also be useful to clearly describe problems with drop connections to hubs and IT systems. Tablet adjustment power supply
The use of only one external power supply can be facilitated. In some embodiments, the device hub processor subsystem is Bluetooth, WiFi, Bluetooth,
Communicate via surveillance client interface using low energy, near field communication, etc. In some embodiments, the device hub processor subsystem communicates with the patient-care device interface using Bluetooth, Bluetooth Low Energy, USB, near field communication, and the like. FIG. 102 shows a battery-only version, ie the extended battery described previously. That is, the circuit 7200 in FIG.
The extended battery 6502 of FIG. 95 may be used. For example, the system 6500 can be made wearable. The extended batteries 6502 of FIG. 95 may be stackable with each other (eg, the circuit 7200 includes a transceiver such as SPI or CAN), thereby allowing the FIG.
Multiple expansion batteries 6502 can be stacked on top of each other to provide power to the infusion pump 6504. The circuit 7200 can be interfaced within a bus or hub to provide power to some devices (eg, patient-care devices) via a device module interface.

FIG. 103 is a circuit 730 that controls multiple infusion pumps with flexibility for expansion.
A block diagram of 0 is shown. For example, the device module interface may interface with multiple infusion pumps, one infusion pump, or may not interface with an infusion pump. Additionally or alternatively, in some embodiments, the circuit 7300 can be used in a dock, infusion pump, communication module, and / or hub as described herein. The circuit 7300 can interface with a bus or hub to communicate with and / or provide power to some devices via a device module interface. In some embodiments, the monitoring client interface may utilize Bluetooth, Bluetooth low energy, or other communication technology. In some embodiments, the device module interface (ie, patient care device interface) may couple to the patient care device via Bluetooth, Bluetooth Low Energy, WiFi, and / or near field communication. it can. As can be seen in this example, CAN communication can be used as a wired protocol to communicate with the infusion pump. Some digital is IO utilized to add some functionality to the pump cradle as needed. The power input and AC / DC supply 7302 is inside the hub (ie, inside circuit 7300) and provides power to the tablet, hub, and one or more infusion pumps. The infusion pump coupled to circuit 7300 may be “independent” safe. An RFID reader 7304 and a barcode reader / camera 7306 are included to authenticate the patient or provider. Communication expansion slot 7308 is included to expand communication functions (eg, peanuts for authentication and location) when other methods are developed.

FIG. 104 shows a failsafe line 7402 and two processors 7404, 74.
A circuit 7400 for a hub as described herein with 06 is shown. In addition to it,
Or alternatively, in some embodiments, the circuit 7400 can be used in a dock, infusion pump, and / or communication module, as described herein. The circuit 7400 is connected to several devices (via the device module interface).
For example, to communicate with a patient care device) and / or to provide power thereto, it may be interfaced with a bus or hub. The processor 7406 may be a safety processor. The failsafe line 7402 can be activated by either of the two processors 7404, 7406. In some embodiments, the WiFi radio may be an Ethernet interface. In some embodiments, the CAN interface may be Bluetooth, Bluetooth Low Energy, WiFi, or other communication technology.

Additional safety is provided by the failsafe line 7402. For example, a pulse oximeter monitor can clamp a line when the pulse is elevated or too high. That is, the failsafe line output can be coupled to an electromechanical occluder. The hub circuit 7400 can act as a watchdog and also monitor the output for range checking and to trigger a clamp if the process in the pulse oximeter is in error or is in a fault condition A fail-safe signal can be transmitted to. Communication with the tablet may be wireless via the tablet UI interface 7408. The circuit 7400 can be charged wirelessly via wireless power 7410. A vibration motor can be added to give liver feedback if there is an alarm. The circuit 7400 optionally includes two processors 7404, 740 that implement a method for alerting the user when an alarm or alert is issued.
6 is provided. The secondary battery or super capacitor 7412 can provide backup power in the event of a power failure. Circuit 7400 includes a pump module, eg,
It may be a communication module and / or a hub for attachment to a cradle.

FIG. 105 is a system 7500 for electronic patient care according to yet another embodiment of the present disclosure.
Is shown. The system 7500 includes a monitoring client, more specifically a stackable monitoring client 7502, and a stackable patient-care device, such as stackable infusion pumps 7504A-7504D. The stackable monitoring client 7502 includes a display 7506 that pivots about a pivot axis 7508. Display 7506 may be a touch screen. The stackable surveillance client 7502 can include a tilt sensor, such as an accelerometer, to orient the display 7506 so that it is always viewable by the user. Similarly, each stackable infusion pump 7504A-7504D has its own display 75 oriented based on its tilt.
For example, the display can show characters in a vertical position regardless of whether the stackable infusion pumps 7504A-7504D are positioned in a horizontal or vertical orientation. In addition, or alternatively, each stackable infusion pump 7504A-7504D can include a tilt sensor, such as an accelerometer.

The displays 7510A to 7510D may be touch screens. Each display, or displays 7510A-7510D, may include one or more buttons that are oriented based on tilt, as indicated by the internal tilt. For example, FIG.
As shown at 05, button 7512 is shown in an upright position relative to the elongated length of stackable infusion pump 7504A. Referring to FIG. 106, system 7500
Is shown as tilted so that button 7512 is shown in an upright position relative to the length of stackable infusion pump 7504A. Display 7
Note also that 507 is further pivoted about pivot axis 7508. FIG.
Shown is a display 7506 pivoted relative to a monitoring client 7502. FIG.
Reference numeral 08 denotes vein holes 7807A to 7807D. FIG. 109 shows an additional range of turning along the turning axis 7408. FIG. 110 shows an infusion pump 7504B that can slide into the stack.

111-112 show that stackable infusion pumps 8102A-8102D are respectively a top connector (eg, connector 81004) and a bottom connector (not explicitly shown).
Infusion pumps 8102A-8102 that are connected to each other and thereby stackable
Stackable electronic patient care system 810 where D is daisy chained together
0 additional embodiments are shown. FIG. 111 shows one configuration of the system 8100. 112 shows that infusion pump 8102D is removable from system 8100. FIG. The infusion pump 8102D can have its own internal battery to continue operation, for example, the infusion pump 8102D can have sufficient battery power to continue to deliver infusion fluid into the patient for a predetermined time. it can.

FIG. 113 shows that the monitoring client 8106 can include a connector to receive the infusion pump 8102D. The monitoring client 8106 can have an attachable / detachable display 8110. FIG. 114 shows that another monitoring client 8108 can be stacked on top of the stackable infusion pump 8102D. The monitoring clients 8106 and 8108 can adjust their operations.
For example, the monitoring client 8106, 8108 can regulate the power supply to the infusion pump so that both batteries of the infusion pump 8106, 8106 are in the system 8
Supply power to 000.

FIG. 115 shows stackable infusion pumps 8422, 8424 and monitoring client 8
Connections 8402-84 that allow 426 to be coupled together in a daisy chain configuration
20 is shown. FIG. 116 shows slidable connections 8502, 8504, 8506, 8508 such that stackable infusion pumps 8422, 8424 and monitoring client 8426 are daisy chained together. Slide connection 850
2, 8504, 8506, 8508 may include electrical connectors that allow stackable infusion pumps 8422, 8424 and monitoring client 8426 to communicate with each other.

FIG. 117 shows a system 8600 of a stackable monitoring client 8602 with a stackable infusion pump 8604 that connects to each other via backplane panels 8606, 8608. The backplane panel 8606 includes a connector 8610 that mates and engages with a connector 8612 on the backplane panel 8608. Additional backplane panels (not shown) can be added to illustrate the backplane according to the number of monitoring clients 8602 or infusion pumps 8604 added thereto. 118 shows a cross-sectional view of the backplane panel 8608 of FIG.

FIG. 119 illustrates a monitoring client, and more particularly, a stackable monitoring client 88.
06, and stackable patient care devices such as stackable infusion pump 880
A system 8800 with 2 is shown. Stackable infusion pump 8802 slides in direction “A” within dock 8804.

FIG. 120 shows a system 8900 in which the stackable infusion pump 8902B engages the dock 8904 via the connector 8509 when moved in the direction “B”.

FIG. 121 shows a communication module 9000 according to an embodiment of the present disclosure. The communication module 9000 includes a connector 9002, an LED state ring 9004, and an RF antenna 900.
4, snap-on connector 9006, wireless charging coil 9008, battery charging and safety processor 9010, wireless communication and sensor processor 9012, and battery 901
4 is provided. The communication module 9000 of FIG. 121 may be the communication modules 124A to 124K of FIG. 122 shows a patient care device 91
A communication module 9000 coupled to 00 is shown. FIG. 123 shows a diagram of an electronic circuit 9200 of the communication module 9000 of FIG. 121, according to an embodiment of the present disclosure.

FIG. 124 shows that the short range interrogator (eg, operating at about 13.56 MHz) is 900M.
An electronic circuit 9300 is shown that allows reading a Hz UHF RFID tag. The electronic circuit 9300 includes a heterodyne transfer oscillator. Circuit 93000 converts the short distance inquiry signal into an RFID inquiry signal. The electronic circuit 9300 includes the communication module 9000 of FIG. 90 and / or the communication module 1 of FIG. 1, 3, 5, 7, or 8.
24A-124K, allowing the near field communication circuit to query the RFID tag. Each antenna can be replaced with an RF circuit, allowing the circuit to be used on an interrogator or receiver. In addition or alternatively, in another embodiment, an electronic circuit can be arranged to communicate with a near field communication device using a UHF RFID interrogator.

125-127 illustrate several antennas according to additional embodiments of the present disclosure. FIGS. 125 and 126 show two split ring resonators 12500, 12600 that can be used in a scanner, eg, placed in front of an RFID or short range interrogator and / or antenna (for transmitting and receiving). . The resonators 12500 and 12600 are formed as follows.
Made using a 0.028 inch thick FR-4 single side board with 5 ounces of copper. Trimming can be used to tune the resonator (as shown).

FIG. 127 shows a short range antenna 12700 for a UHF reader (eg, a 915 MHZ RFID reader) that focuses on a short range pattern with a reader chip. Without a power amplifier, a reading range of about 1.5 inches is achieved. Antenna 12700 is made of 0.028 inch thick FR-4 with a copper backing. Antenna 1270
0 can be used with a 10 pF shunt matching element.

FIG. 128 illustrates a patient wrist band 12800 with an RFID tag 12802 attached according to an embodiment of the present disclosure. Since the capacity is observed when the RFID tag 12802 is attached to the patient wristband, a split ring resonator (SRR) 12804, such as 0.01 inches away from the patient, can be used. Inductive loading from the patient's volume reduces the frequency of the RFID tag 12802, thereby causing the SRR 1280
4 is coupled to the RFID tag 12802 closer to the antenna,
Help pacing tag 12802. The resonant frequency of the SRR 12804 should be slightly above the operating frequency of the RFID tag 12802. FIG. 129 shows an expanded view of split ring resonator 12804 for use on the wrist band of FIG.

The RFID tag 12802 of the patient wristband 12800 is writable. Hubs, docks, patient care devices, and / or monitoring clients can: (1) treatment history such as flow rate, drug settings, vital signs, etc. (2) usage statistics (patient care parameters, patient treatment parameters, patient care device operating parameters , docks, etc. diagnostic information from the hub and monitoring client), (3) the venous pump flow parameters, ECG parameters, blood pressure parameter, a pulse oximeter parameters, CO ₂ capnometers parameters, intravenous bag parameters, and infusion flow rate Meter parameters, (4) patient parameters including at least one of treatment course of infusion pump, electrocardiogram signal, blood pressure signal, pulse oximeter signal, CO ₂ capnometer signal, and temperature signal, (5) infusion rate or pressure Includes patient treatment parameters such as infusion settings Patient related data can be written into the RFID tag 12802 from which, for example, the presence of air in the infusion line, the amount of solution remaining in the connected intravenous bag, or in the infusion line Various operating parameters such as fluid pressure can be received. In some embodiments, the RFID tag 12802 only has a predetermined elapsed time (ie, rolling history) in its memory, eg, in some specific embodiments, the RFID tag 12802 has 32 kilobytes or 56 kilobytes. Includes a 6 to 14 hour history on memory. In yet additional embodiments, the RFID tag 12
802 may include a near field communication receiver for receiving a patient ID and / or data.

FIG. 130 shows a split ring resonator 13000 according to an embodiment of the present disclosure. The high Q split ring resonator 13000 includes a capacitor 13002 that operates instead of an air gap. The SRR 13000 has 13 dB to improve the loop antenna by 10 dB.
. It can be placed about 8 inches away from the 56 MHZ NFC loop antenna. S
The RR 13000 can be specified to operate at 13.8 MHZ to reduce the group delay distortion to a 13.56 MHZ digital modulation signal. FIG. 131 shows an equivalent circuit 13100 for the SRR 13000 of FIG. 130 according to an embodiment of the present disclosure.

FIG. 132 can be displayed on any display disclosed herein.
The R check list is shown. FIG. 133 illustrates an occlusion checklist that can be disclosed on any display disclosed herein. FIG. 134 shows a display that is in operative communication with several infusion pumps, such as the monitoring client 1 or 11 of FIG. 1, 3, 5, 7, 8, or 9.

FIG. 135 is an illustration of a display on a healthcare provider's portable monitoring client showing a list of patients that the provider can access to that information, according to an embodiment of the present disclosure.

FIG. 136 illustrates a health care device showing a device associated with a particular patient with one-touch access to current data from the device and some of the patient's medical information according to an embodiment of the present disclosure. It is a figure which shows the display on the portable monitoring client of a provider. FIG. 137 is a diagram illustrating a display on a healthcare provider's portable monitoring client showing a data entry area for a pharmaceutical prescription for use with an intravenous infusion pump according to an embodiment of the present disclosure. FIG. 138 is a healthcare provider's portable monitoring client showing the risk profile associated with the indicated medication and the proposed operational process as generated by the monitoring client according to an embodiment of the present disclosure. It is a figure which shows the upper display. FIG. 139 is a diagram illustrating a display on a healthcare provider's portable monitoring client showing a medication prescription ready for presentation by an instruction provider, according to an embodiment of the present disclosure. FIG. 140 is a diagram of a health care provider's portable monitoring client showing how the monitoring system can display to the instruction provider a confirmation that the prescription has been communicated to the pharmacist, according to an embodiment of the present disclosure. It is a figure which shows a display.

Example of Monitoring Assist Instruction Input The function of the patient monitoring system can be illustrated by an example in which the instruction provider inputs a new medication prescription for the patient. In this scenario, the physician can see a list of allowed patients on his handheld device after entering the appropriate security pass code. In this example, the physician's patient has limited user-selectable information 26 about each patient, such as age, diagnosis, and medical record number, as shown in FIG.
Can be listed. For example, if the instruction to patient 2 is incomplete and the nurse flags the patient for attention, or the monitoring client 1 enters an input that exceeds a predetermined threshold for physician notification, When received from the patient monitoring devices 14-17, the warning symbol 27 can be transmitted to the physician's device 11 by the monitoring client 1.

After the physician selects the patient for further review, a display such as that shown in FIG. 135 can be communicated to the physician's device 11. The physician is the monitor 1 to which the patient is connected
User selectable data resulting from 4-17 can be seen and the physician can have one-touch access to several databases 19-21, 23 containing patient specific information. In an embodiment, the monitoring client 1 can be connected or docked to an infusion pump 7 that is available for use with the patient 2. In the scenario shown in FIG. 136, the physician can press an icon indicating the infusion pump 7 to instruct the patient 2 to administer intravenous medication.

FIG. 137 shows one of several possible prescription ordering screens where a physician can order medications remotely. In the illustrated embodiment, the physician enters the drug intravenous nitroglycerin 28, which can be entered via typing or a drop-down display added by the hospital pharmacy prescription book 22, and the monitoring server 3 can be accessed by the monitoring client 1. The “PDR” button 29 may indicate a one-touch access of the physician to the hospital 22 or dedicated drug database 9 for detailed drug information. The physician can indicate the dose of the drug either directly or by allowing the default standard starting dosage 30 provided by the monitoring client 1 via the monitoring server 3. The physician can also specify a maximum fluid infusion rate 31 for the infusion pump 7 to help the pharmacist prepare the appropriate concentration of drug in the bag for infusion.

FIG. 138 shows an example of how the patient monitoring system detects the risk of side effects after a physician inputs a prescription. The monitoring client 1 sends a new medicine 28 to E
It can be compared with the list of existing drugs and drug allergies of patients downloaded from HR19. The monitoring server 3 preferably adds appropriate patient specific data within the monitoring client 1, which is programmed to retrieve this information after a new medication instruction is entered. The monitoring client 1 can be programmed to request a list of significant side effects and drug interactions associated with each patient's medication and new medication 28 from the monitoring server 3. Server 3 can then access pharmacy database 22 or external database 9 for this information. If a potential drug interaction or side effect common to an existing drug or a new drug 28 is detected, the monitoring client 1 issues a warning 32 and communicates it to the instructing physician as shown in FIG. Can do. If the potential side effects are due to effects common to both new and existing drugs, the monitoring client 1 classifies this as a potential additional side effect and suggests reducing the initial drug dose by, for example, 50% 33 can be issued.

As shown in FIG. 139, the instructing physician has the option to accept proposal 33 or edit the suggested dose to another value. In either case, the monitoring client 1
Is a report 34 of a warning 32, and any corrective action 33 performed by the physician,
The report can be generated and recorded with the option to further edit the report before the physician records or enters the patient's EHR 19.

Once the drug dose is finally determined, the monitoring client 1 can forward the instructions to the communication devices of both the hospital pharmacist 6 and the patient nurse 5. As shown in FIG. 140, the report of achievement of this task can then be communicated again to the instructing physician 11. The pharmacist can use the information provided by the instructing physician to mix the appropriate concentration of drug in the solution bag. Both the drug bottle and the solution bag can be read into the pharmacist's monitoring client 6 and can be authenticated by the monitoring client 1 (using a pharmacy database 22 as accessed by the monitoring server 3) as correct. For example, having an identification tag such as a bar code identifier. The pharmacist can then generate a unique identification label, such as a bar code label that is permanently attached to the drug bag, with the code uniquely linked to the patient 2 from whom the drug 28 was prepared. The identification code on the label can be communicated to the monitoring client 1 for later re-regulation when the nurse attempts to administer the medication 28.

After the prepared medication 28 arrives at the patient's floor, the nurse can then prepare to administer it to the patient 2. In this exemplary scenario, the monitoring client 1 may be used by a nurse to verify that the identification code on the medication bag matches the identification information of the prescribed patient 2, such as a barcode reader Input devices. If the identification information matches the information entered in the monitoring client 1 by the pharmacist, the nurse can leave the device 1 and hang the drug bag and start infusion via the infusion pump 7. In an embodiment, the monitoring client 1 determines the dosage, the maximum fluid velocity for the patient, the concentration of the drug in the bag, and the infusion rate for the pump (optionally
The prescription is displayed to the nurse, which can be calculated by the processor in the monitoring client 1). With this information, the nurse has the ability to manually calculate and verify that the infusion rate set by the monitoring client 1 for the pump 7 is correct.

FIG. 141 shows an apparatus 14100 formed by a microinfusion pump 14104 coupled to an adapter 14102 according to an embodiment of the present disclosure. The adapter 14102 includes a touch screen 14106 that can be used to control the operation of the microinfusion pump 14104. The microinfusion pump 14104 pumps fluid from the tube 14108.

The adapter 14102 includes the monitoring client 1 shown in FIGS. 3, 5, 7, and 8, the monitoring client 902 shown in FIG. 9, the dock 102 or 104 shown in FIG. 1, the dock 102 or 104 shown in FIG.
Dock 502, hub 802 of FIG. 8, docks 804, 806, or 102 of FIG. 8, FIG.
Three, five, or seven dongles 133 or any patient care device disclosed herein may be in wireless communication.

The adapter 14102 can include various electrical connectors so that the microinfusion pump 14104 can be docked to the adapter 4102. The adapter 14102 can include an electrical connector on the back side to interface with the patient-care device dock 104. For example, the adapter 14102 can comprise a connector so that the adapter 14102 can be docked.

The touch screen 4106 can be used to set the infusion rate, bolus amount, extended bolus settings, or the like. In addition or as an alternative, the touch screen 4
106 can be used to estimate the amount of liquid drug remaining in the microinfusion pump 14104.

142 illustrates a perspective view of a wireless hub device 14200 that wirelessly relays data from a patient-care device to a monitoring client, another hub, or dock, according to an embodiment of the present disclosure.

The wireless hub device 14200 includes a body 14 coupled to a touch screen 14204.
02 and a holder 14206. The wireless hub device 1420 can communicate data from another patient-care device to the patient-care device to a monitoring client, another hub, a dock, and the like. For example, the wireless hub device 14200 can communicate data with a patient-care device according to a first wireless protocol and relay information to another monitoring client, another hub, dock, etc. via another wireless protocol. For example, the wireless hub device 14200 can communicate with a patient-care device via Bluetooth and relay data to a dock (eg, the dock 104 of FIG. 1) via near field communication. In this particular embodiment, the holder 14206 can be shaped such that the holder 14206 is within a dock, eg, the dock 104 of FIG.

FIG. 143 illustrates a modular patient-care device 14304 coupled to a monitoring client 1430 via an adapter 14316 and a dock 14314 according to an embodiment of the present disclosure.
, 14306, 14308, and 14310 show a front perspective view of an electronic patient care system 14300. Dock 14314 is coupled to post 14312. Adapter 14316 includes a dock 14314 and patient care devices 14304, 14306, 14
An electrical connection is provided between 308 and 14310. That is, the adapter 14316 is
Variations can be made based on the type of patient-care device 14304, 14306, 14308, and 14310 used.

144 illustrates a side perspective view of the electronic patient care system of FIG. 143, according to an embodiment of the present disclosure. Referring to FIGS. 143-144, patient care device 14306 slides over adapter 14316 via rails 14318 and 14320. The infusion pump 14304 can be snapped onto the spring loaded flange 14322. The flange on the back side of the adapter 14316 can be pulled to pull the flange away from the infusion pump 14304.

145 shows an enlarged perspective view of one interface of the patient-care device shown in FIG. 143 according to an embodiment of the present disclosure. Referring now to FIGS. 144 and 145, rail 14318 engages track 14502 and rail 14320 engages rail 14504. The space 14506 receives a flange 14322, whereby the infusion pump 143
04 snaps into place in adapter 14316.

FIG. 146 shows a top view of the electronic patient care system 14300 of FIG. 143 according to an embodiment of the present disclosure. Dock 14314 has two adapters 14602 and 14316
Is bound to. The dock 14314 is coupled to the column 14312 via a clamp 14606. Pump 14304 is shown with pump door 14604 open.

FIG. 147 shows a diagram of a system 14700 for electronic patient care according to an embodiment of the present disclosure. The system 14700 includes a central server 14702, a central server client 1
4703, a hospital server 14704, one or more medical IT systems 14705, dock / hubs 14707, 14708 and 14709, and a hospital server client 14706.

Central server 14702 may be an enterprise level server, a hospital level server, or a global server (eg, a cloud server). Central server 14702 may provide software updates, firmware updates, and / or configuration files. For example, the central server 14702 includes a hospital server 14704, a dock / hub 1470.
7, 14708 and 14709, dock / hub 14707, 14708 and 1470
Patient care device coupled to 9 or dock / hub 1470 based on device ID
7, 14708 and 14709 can provide updates to monitoring clients in operative communication. In addition, or alternatively, the central server 14702 can provide software for downloading to the sandbox as described below (see FIG. 148). In addition or as an alternative, the central server 14702
Can receive usage statistics (patient care parameters, patient treatment parameters, patient care device operating parameters, diagnostic information from docks, hubs and monitoring clients, etc.). The central server 14702 can record data in a database, such as an SQL database, an associated database, and the like.

The central server client 14703 is connected to the central server 14702 as described above.
Communicate with and monitor the operation of the central server 14702, view the log files in it,
Or you can view data on drug effectiveness. In some embodiments of the present disclosure, the central server client 1403 is a nurse station software that allows the nurse to monitor the dock / hub, patient, and / or patient care device.

The hospital server 14704 is a hospital, a hospital treatment room (for example, a neonatal intensive care treatment room (NI).
CU), intensive care unit (ICU), etc.), in a hospital floor, or in a hospital group (eg, a hospital management group).

The hospital server 14704 can include (1) a custom set of DERS and can track a patient-care device, dock / hub or monitoring client, and (2) a non-compliant patient-care device, dock / hub and / or Or the monitoring client can be identified and recorded, and / or (3) a dock / hub, monitoring client, and / or (eg, via an update software file, configuration file, or firmware file from the central server 14702) A patient-care device can be configured or updated.

One or more medical IT systems 14705 communicate with the hospital server 14704 and provide functionality thereto. The medical IT system 14705 can provide a computerized provider instruction entry (CPOE), drug library, electronic medical record (EMR), computerized maintenance management system (CMMS), or other database or computerized system.

Dock / hubs 14707, 14708 and 14709 communicate with hospital server 14704. There may be one or more of dock / hubs 14707, 14708 and 14709 in the patient's room.

The hospital server client 14706 allows a user or technician to enter the hospital server 14
704 can be interfaced to help facilitate software updates, monitor internal log files, or facilitate continuous quality improvement (CQI).

FIG. 148 shows a block diagram of an electronic patient care system 14802 according to an embodiment of the present disclosure. The system 14802 includes an enterprise server system 14804, an application store 14806, a device manager 14808, one or more hubs 14
26, one or more tablets 14810, one or more infusion pumps 14814,
And one or more wireless sensors 14816. Between tablet and dock / hub 14812, between dock / hub 14816 and wireless sensor 14816, dock / hub 1
4812 and infusion pump 14814, between dock / hub 14812 and device manager 14808, device manager 14808 and application store 1480
6 and / or communication between the device manager 14840 and the enterprise server (s) 14804 can be WiFi, Ethernet, Bluetooth, USB, 3G
4G, HALO, SOAP, using XML data, self-describing data, HL7, TC
This can be done using P / IP, Bluetooth templates, dedicated and / or non-dedicated communication links.

Enterprise server system 14804 may, in some embodiments, be a CMMS database 14832, CPOE 14834, EMR 14836, and / or billing server 148.
38 can be provided. The corporate server system 14804 is
Device health information including data, battery life, etc. can be received by CMMS14832.

Application store 14806 may include one or more device applications (or programs) 14850, 14851, 14852, and / or 148.
53, one or more patient-care devices, one or more sensors,
One or more infusion pumps 14814 can be controlled or programmed to provide patient diagnostic functions and the like. The application store 14806 can provide encrypted communication to facilitate one or more downloads of the device applications 14850-14853.

Device manager 14808 is responsible for global DERS 14840 and local
It may be a hospital level server that provides policy 14842. The local policy 14842 may include additional hard or soft limits (eg, for drugs) based on the location of a particular dock / hub 14812 within a hospital (eg, ER, NICU, ICU, etc.), for example. it can.

The dock / hub 14812 can be coupled to one or more wired or wireless sensors 14816, one or more infusion pumps 14814, and / or can be connected to other patient-care devices. Dock / Hub 14812 can be connected to WiFi, Ethernet, Bluetooth, Bluetooth Low Energy, USB, 3G, 4G, HL7, TCP / IP, Bluetooth template via dedicated or non-dedicated communication links.
Alternatively, other protocols can be used to communicate with one or more wireless sensors 14816 and may use self-describing data. The wireless sensor can use one of the communication modules described above (eg, wireless sensor 14914 can be coupled to the communication module via a serial link such as an SPI). Tablet 1481
0 can interface with the dock / hub 14812. The dock / hub 14812 can include a local copy of DERS 14826 that can be periodically updated by DERS 14840 from the device manager 14808. In addition or alternatively, the dock / hub may include a local copy of the local policy 14828 that can be periodically updated by the device manager 14808.

The tablet 14810 can provide a care flow sheet that provides the caregiver or patient with a checklist of the day's activities, including scales, vital monitors, bathing data, changing clothes, meal information from the patient care device. Can be recorded, recorded, or manually entered into the tablet 14810, and the patient's E in EMR14836
It can be updated and stored in the MR file. The tablet 14810 provides guidance to the home patient or caregiver to act as a reminder for certain care actions, such as how and when to change clothes, measure urine output, or take a blood glucose reading be able to. In addition, or alternatively, the tablet 14810 can instruct the caregiver, patient, or user how to eliminate the cause of the soft and / or hard alarm.

A patient-care device, such as infusion pump 14814, can be
The infusion pump 14 is in close contact with the hub 14812, eg, for a patient pairing device, passing configuration data, or a dock / hub 14812 associated with it.
When setting 814 parameters, near field communication (N
FC). After NFC communication, infusion pump 14814 is connected to dock / hub 1
4812 can be communicated wirelessly or via a wireless link. For example, infusion pump 14814 can be in intimate contact (or contact) with dock / hub 14812 and uses NFC communication to pair infusion pump 14814 with dock / hub 14812 using a Bluetooth communication link.

The dock / hub 14812 can execute device applications 14820-14824 within the sandbox 14814. Sandbox 14814 may need to write applications on a predetermined basis. In some embodiments,
The sandbox 14814 can include an API with a secure data class. In yet another embodiment, the sandbox 14814 is a monitoring client 148.
10 may be present. The sandbox 14814 may be a virtual machine and is a program that controls resources (for example, hardware or software resources available through the API) that can be used by the device application 14820-14824. Alternatively, it can have global variables accessible by device applications 14820-14824 and may be interpreter based. That is, the sandbox 14812 is a device application 14.
820-14824 are protected areas that allow execution in a controlled and restricted resource environment. Sandbox 14812 is a device manager 14808
Or it can be downloaded from the application store 14806. The sandbox 14812 includes, for example, a version number, serial number, lot number, hardware version number, software version number, operating system number,
Any one of type, operating system service pack, other identifiers, etc.
One or a combination can be preconfigured for a particular dock / hub type.

For example, the dock / hub identifies the infusion pump 14814 by serial number and docks the device application 14850 from the application store.
12 (eg, device application 14820). Device application 14820-14824 may control and / or communicate with infusion pump 14814 to relay information about infusion pump 14814 to tablet 14810 for display (eg, via XML). . In addition or alternatively, one or more of the device applications 14820-14824 may display data from the device and use complex heuristics to combine data from several sources, etc. it can. Sandbox 14818 can also control access to various resources such as memory, non-volatile memory, hard drives, network interfaces, input devices, output devices, buzzers and the like. In some embodiments, the sandbox 14818 may limit or prohibit device applications 14820-14824 from reading and / or writing to certain files, such as system files. Sandbox 14
818 may provide temporary and / or protected resources to device applications 14820-14824, such as “notepad” memory space and / or notepad hard disk space.

Any attempt to thwart DERS 14826, local policy 14828 by device application 14820, or prevent dock / hub 14812 from performing its primary function (eg, a specified high priority function) Other software running on hub 14812 (eg, an Android operating system that controls sandbox execution through one or more process blocks or one or more threads from a thread pool , IOS, Linux,
Windows, or an operating system such as Windows CE).

The sandbox 14818 may control the start of one or more of the device applications 14820-14824. For example, the sandbox 14818 is
The device application 14820-14824 designated to execute does not have any broken links and the sandbox 1481
Rules or links (eg, dynamic link library calls) can be checked to ensure that certain criteria controlled by 8 are met.
For example, the sandbox 14818 indicates that all of the references from the device application 14850 to the shared library in the dock / hub 14812 software are in a specific “safe” shared library, a specific function or variable in the library. And that variables and data types requested by device application 14820-14824 and communicated by device application 14820-14824 match or exist in the library. .

In some embodiments of the present disclosure, sandbox 14818 prioritizes access to resources. For example, a number of device applications 14820-1482
4 requests access to an alarm device (eg, speaker) or variable that indicates an alarm condition, the sandbox 14812 prioritizes the source of the request and displays a priority list of alarm causes on the tablet 14810 Thus, a caregiver can override a particular alarm condition, address multiple alarm causes, and / or evaluate a patient condition.

In some embodiments of the present disclosure, the dock / hub 14812 comprises a processor having two cores, whereby one of the cores executes the sandbox 14818,
Another core runs an operating system that controls the allocation of resources used by the sandbox 14818 via one of the device applications 14820-14824.

In some embodiments of the present disclosure, the dock / hub 14812 includes two processors so that one of the processors executes the sandbox 14818 and another processor is one of the device applications 14820-14824. Operating resources that control the allocation of resources used by the sandbox 14818 via
Run the system.

In some embodiments of the present disclosure, the dock / hub 14812 includes two processors so that one of the processors executes the sandbox 14818 and another processor is one of the device applications 14820-14824. A watchdog function is implemented that ensures safe operation of the resources used by the sandbox 14818 via

In some embodiments of the present disclosure, the dock / hub 14812 includes two processors, whereby one of the processors executes a real-time safety processor, another processor includes a sandbox 14818, and a device application. 1482
Run an operating system that controls the allocation of resources used by the sandbox 14818 through one of 0-14824.

In some embodiments of the present disclosure, the dock / hub 14812 includes one or more processors each having one or more cores, whereby at least one process control block executes the sandbox 14818. , At least another process control block executes an operating system that controls allocation of resources used by the sandbox 14818 via one of the device applications 14820-14824.

The dock / hub 14812 can de-identify data from patient-care devices and upload the data to a database 14830 (eg, a cloud-based database), which is a disease epidemic within a hospital or hospital system. It may be real-time data collected at the national level to facilitate discovery, resource planning, and deployment planning.

149 shows a block diagram 14900 of the bedside portion of the electronic patient system of FIGS. 147 and / or 148, according to an embodiment of the present disclosure. 14900 shows a monitoring client 14902 (which may be a tablet 148120), a monitoring client 1
4902 includes a monitoring client adapter 14904 that can interface with a dock / hub 14906 (which may be a dock / hub 14812), and several infusion pumps 14910. Dock / hub 14906 is WiFi,
Zigbee, Bluetooth, Mesh Network, Point to Point,
It can communicate with infusion pump 14910 via a protocol (eg, based on WiFi) or the like. Infusion pump 14910 may receive power directly through AC outlet 14908 (not shown) and / or directly from dock / hub 14906. Dock / hub 14906 connects to wireless sensor 14814 (wireless or wired), and U
The SB sensor 14912 is coupled via a USB cable.

In some embodiments of the present disclosure, for example, over a dedicated or non-dedicated communication link, Wi
Dock / Fi via Fi, Ethernet, Bluetooth, USB, or other protocols
There may be other in-room displays such as a hub, surveillance client, computer, etc. that can communicate with the hub 14812 and / or tablet 14810.

150 shows a block diagram of the dock / hub 15000 of FIGS. 147, 148, and / or 149, according to an embodiment of the present disclosure. The dock / hub 15000 includes a primary processor 15003 and a safety processor 15002 (one or both may be a processor, a microprocessor, or a microcontroller, such as a snapdragon processor).

Safety processor 15002 is coupled to a speaker driver 15011 that controls backup speaker 15012. Safety processor 15002 is also coupled to a 2X CAN bus connected to the patient-care device via device connector 15014. In some embodiments, the device connector 15014 is a Zigbee.
Communicate with the patient-care device via Bluetooth, WiFi, CAN bus, or SPI communication link.

Safety processor 15002 is coupled to voltage regulator 15010 that receives power from backup battery 15017 and / or battery charger 15009. Safety processor 15002 is coupled to an enable switch 15016 that can disable power to a patient-care device coupled to device connector 15014. Current limiter 15015 can also limit current to a patient-care device coupled to device connector 15014.

The safety processor 15002 also enables / disables a 5 volt power supply to a patient-care device coupled via the device connector 15014.
It is bound to zero. The 5V signal to the patient-care device is received from a voltage regulator 15010 that receives its power from the primary battery cell 15018 and / or battery charger 15009. The battery charger is an AC / DC converter 1500 coupled to an AC outlet 15007.
8 to receive power.

Primary processor 15003 includes camera 15024, WiFi transceiver 15025, Bluetooth transceiver 15026, RFID interrogator 15027, LED status light 15029,
Coupled to button 15028 and near field communication transceiver 15030.

The primary processor 15003 is connected to the USB port 1502 via the UI connector 15022.
3 and / or a USB cable that couples to a monitoring client. In some embodiments, the primary processor 15003 can communicate with a tablet via WiFi or other wireless communication link. Primary processor 15003 has USB connection 1
The patient care device can be communicated via the 5023 and / or the monitoring client via the UI connector 15022 via the USB port. Primary processor 1500
3 communicates a signal to a speaker driver 15006 that drives the primary speaker 150005.

151 is a block diagram illustrating the infusion pump circuit 15100 of FIGS. 148 and / or 149 according to an embodiment of the present disclosure. The circuit 15100 includes a pump display 151
And a UI / safety processor 15102 for recording data in the non-volatile memory 15105. The UI / safety processor 15102 is connected to the device connector 1
Communicate with the hub / dock via a CAN bus coupled to 5108. In some embodiments, real-time processor 151102 and / or UI / safety processor 1
5102 communicates with the hub / dock via device connector 15108 using a Bluetooth, wireless, or wired communication link. The UI / safety processor 15102 can comprise an image processing library for processing images from the camera. Additionally or alternatively, the UI / safety processor 15102 can comprise a library for displaying a GUI interface on the pump display 15104 (which can be a touch screen).

The UI / safety processor 15102 includes a home position occluder sensor 15116, a latch sensor 15117, an in-line air sensor 15118, a motor hall sensor 15119,
Coupled to button 15120 and status light 15112. Safety processor 151
02 can provide a watchdog function to the real-time processor 15103 (which can be a processor, microprocessor, or microcontroller, eg, a snapdragon processor), and can enable the motor drive 15107.

A real-time processor 15103 (one or both of which may be a processor, a microprocessor, or a microcontroller, such as a snapdragon processor), controls the operation of the pump motor 15106 via a motor drive 15107. Real-time processor 15103 communicates with UI / safety processor 15102 via a serial interface (eg, to receive pump settings). Real-time processor 15103 loads pump calibration data from non-volatile memory 15122. The nonvolatile memory 15122 and / or the nonvolatile memory 15105 may be an SD card and / or an RFID tag.

Real-time processor 15103 includes motor current sensor 15109, motor housing temperature 15110, blockage pressure sensor 15111, camshaft position sensor 1511.
2. Receive data about the infusion pump from the cam follower position sensor 1513 and / or the accelerometer 15114.

151 and 152 are US patent application Ser. No. 12 / 249,600 filed Oct. 10, 2008, entitled Multi-Language / Multi-Processor Infusion Pump Assembly, and subsequently published on Apr. 15, 2010. US Patent Application Publication No. 2010-000942
Using two processors to verify the instruction (s) in the same and / or similar manner as disclosed in No. 21 (Attorney Docket No. F54) Other functions (eg, user confirmation of patient treatment parameters) can be performed and are incorporated herein by reference.

152 is for use with the infusion pump circuit of FIG. 151 according to an embodiment of the present disclosure.
FIG. 6B is a block diagram 1500 illustrating a sensor coupled to an infusion pump mechanism. Infusion pump
Pump fluid through tube 15207. The motor 15204 includes a motor / Hall effect sensor 15205, a motor / housing temperature sensor 15206, and a slide / clamp mechanism 15.
Hall effect sensors 15201 and 15202 for detecting the operation of 220, Hall effect sensor 15211 for the outlet valve, Hall effect sensor 15 for the plunger position
212 and 15213, Hall effect sensor 15214 for the inlet valve, and Hall effect rotational position sensor 15208.

Various alternatives and modifications can be devised by those skilled in the art without departing from the disclosure. Accordingly, the present disclosure is intended to embrace all such alternatives, modifications and variations. In addition, although some embodiments of the present disclosure are shown in the drawings and / or discussed herein, the disclosure is allowed by the art and the specification is broadly readable. The disclosure is not intended to be limited thereto. Therefore, the above description should not be construed as limiting, but merely as exemplifications of particular embodiments. Those skilled in the art will envision other modifications within the scope and spirit of the claims appended hereto. Other elements, steps, methods, and techniques not substantially different from that described above and / or in the appended claims are also intended to be within the scope of the disclosure.

The embodiments shown in the drawings are presented only to demonstrate certain examples of the disclosure.
Moreover, the drawings described are merely illustrative and are not limiting. In the drawings, for the purposes of illustration, some sizes of elements may be emphasized and are not drawn to scale. In addition, the elements shown in the drawings having the same numbers may be the same elements or similar elements depending on the contents.

The term “comprising” is used in the present description and claims, but does not exclude other elements or steps. Where an indefinite or definite article is used when referring to a singular noun, such as “a”, “an” or “the”, this also includes the plural of that noun unless specifically stated otherwise . Accordingly, the term “comprising” should not be construed as limited to the items listed below, nor does it exclude other elements or steps. Thus, the scope of the expression “device with items A and B” should not be limited to devices consisting solely of components A and B. Such an expression simply means that the relevant components of the device are A and B in the context of the present invention.

Further, terms such as “first”, “second”, “third” and the like are used to distinguish between similar elements, whether used in the specification or the claims. It is not necessarily given to describe sequential or chronological order. The terms so used are interchangeable in appropriate situations (unless otherwise explicitly disclosed), and embodiments of the invention described herein are described or illustrated herein. It is possible to operate in other orders and / or arrangements.

Claims (38)

An electronic patient care system,
A hub configured to monitor a patient-care device, the hub comprising:
An operating system component configured to access at least one of the hub's hardware resources and the hub's software resources;
A sandbox component configured to control the access to the at least one of the hardware resource and the software resource;
The hub is further configured to execute an application to identify the patient-care device and monitor the patient-care device;
The hub executes the application within the sandbox component, whereby the application accesses the at least one of the hardware resource and the software resource through the sandbox component ;
The system, wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource.   The system of claim 1, wherein the hub is further configured to control the patient-care device.   The patient care device is selected from the group consisting 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, an infusion flow meter. The system described in.   The system of claim 1, wherein the hub is further configured to receive identification information from the patient-care device and download the application from a server associated with the identification information.   The system of claim 1, wherein the hub is further configured to receive identification information from the patient-care device and update the application from a server associated with the identification information.   The system of claim 1, wherein the hardware resource is one of a disk drive, memory, buzzer, microphone, speaker, and camera.   The system of claim 1, wherein the software resource is one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component. An electronic patient care system,
A hub configured to monitor a patient-care device, the hub comprising:
A sandbox component configured to control access to at least one of a hardware resource and a software resource;
The hub is further configured to execute an application to identify the patient-care device and monitor the patient-care device;
The hub executes the application within the sandbox component, whereby the application accesses the at least one of the hardware resource and the software resource through the sandbox component ;
The system, wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource .   The system of claim 8, wherein the hub is further configured to control the patient-care device.   9. The patient-care device is selected from the group consisting 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 infusion flow meter. The system described in.   The system of claim 8, wherein the hub is further configured to receive identification information from the patient-care device and download the application from a server associated with the identification information.   The system of claim 8, wherein the hub is further configured to receive identification information from the patient-care device and update the application from a server associated with the identification information.   The system of claim 8, wherein the hardware resource is one of a disk drive, memory, buzzer, microphone, speaker, and camera.   The system of claim 8, wherein the software resource is one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component. An electronic patient care system,
A monitoring client configured to monitor a patient-care device, the monitoring client comprising:
An operating system component configured to access at least one of the monitoring client hardware resource and the monitoring client software resource;
A sandbox component configured to control the access to the at least one of the hardware resource and the software resource;
The monitoring client is further configured to identify the patient-care device and execute an application to monitor the patient-care device, the monitoring client executing the application within the sandbox component; The application thereby accesses the at least one of the hardware resource and the software resource through the sandbox component ;
The system, wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource .   The system of claim 15, wherein the monitoring client is further configured to control the patient-care device.   16. The patient-care device is selected from the group consisting 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, an infusion flow meter. The system described in.   The system of claim 15, wherein the monitoring client is further configured to receive identification information from the patient-care device and download the application from a server associated with the identification information.   The system of claim 15, wherein the monitoring client is further configured to receive identification information from the patient-care device and update the application from a server associated with the identification information.   The system of claim 15, wherein the hardware resource is one of a disk drive, memory, buzzer, microphone, speaker, and camera.   The system of claim 15, wherein the software resource is one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component. An electronic patient care system,
A monitoring client configured to monitor a patient-care device, the monitoring client comprising:
A sandbox component configured to control access to at least one of a hardware resource and a software resource;
The monitoring client is further configured to identify the patient-care device and execute an application to monitor the patient-care device, the monitoring client executing the application within the sandbox component; The application thereby accesses the at least one of the hardware resource and the software resource through the sandbox component ;
The system, wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource .   24. The system of claim 22, wherein the monitoring client is further configured to control the patient-care device.   23. The patient-care device is selected from the group consisting 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 infusion flow meter. The system described in.   23. The system of claim 22, wherein the monitoring client is further configured to receive identification information from the patient-care device and download the application from a server associated with the identification information.   23. The system of claim 22, wherein the monitoring client is further configured to receive identification information from the patient-care device and update the application from a server associated with the identification information.   23. The system of claim 22, wherein the hardware resource is one of a disk drive, memory, buzzer, microphone, speaker, and camera.   The system of claim 22, wherein the software resource is one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component. An electronic patient care system,
A hub configured to communicate with an electronic medical record;
A patient care device,
The hub is configured to identify a patient and the patient-care device;
The hub is configured to download at least one treatment parameter from the electronic medical record and program the patient-care device with the at least one treatment parameter ;
The system, wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource .   The hub reads RFID using an RFID interrogator, voice using speech recognition software coupled using a microphone, face using face recognition software coupled to a camera, biometric reading 30. The system of claim 29, wherein the patient is identified according to at least one of biometric parameters, identification information, and barcode reading by a barcode reader. An electronic patient care system,
A monitoring client configured to communicate with an electronic medical record;
A patient care device,
The monitoring client is configured to identify a patient and the patient-care device, wherein the monitoring client downloads at least one treatment parameter from the electronic medical record, and uses the at least one treatment parameter to configure the patient-care device. Configured to program ,
The system, wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource .   The surveillance client reads RFID using an RFID interrogator, voice using speech recognition software coupled using a microphone, face using face recognition software coupled to a camera, biometric reading 32. The system of claim 31, wherein the patient is identified according to at least one of: biometric parameters, identification information, barcode reading by a barcode reader. An electronic patient care system,
  A hub configured to monitor a patient-care device, the hub comprising:
  An operating system component configured to access at least one of the hub's hardware resources and the hub's software resources;
  A sandbox component configured to control the access to the at least one of the hardware resource and the software resource;
  The hub is further configured to execute an application to identify the patient-care device and monitor the patient-care device;
The hub executes the application within the sandbox component, whereby the application accesses the at least one of the hardware resource and the software resource through the sandbox component;
The hub is further configured to receive an identification from the patient-care device and download an application from a server associated with the identification;
If multiple applications request access to an alarm device or a variable indicating an alarm condition, the sandbox component prioritizes the source of the request and generates a priority list that generates an alarm Being the system. 34. The system of claim 33, wherein the hub is further configured to control the patient-care device.  34. The patient-care device is selected from the group consisting of an infusion pump, pill dispenser, microinfusion pump, ECG monitor, blood pressure monitor, pulse oximeter, CO2 capnometer, intravenous bag, infusion flow meter. The system described in. 34. The system of claim 33, wherein the hub is further configured to receive identification information from the patient-care device and update the application from a server associated with the identification information. 34. The system of claim 33, wherein the hardware resource is one of a disk drive, memory, buzzer, microphone, speaker, and camera.  34. The system of claim 33, wherein the software resource is one of a variable, a secure data object, a secure variable, a protected API, an API, and a software representation of a hardware component.

Images