JP2020038683A - System, method, and apparatus for electronic patient care - Google Patents

Abstract

To provide a system for electronic patient care which has a hub configured to monitor a patient care device.SOLUTION: An electronic patient care system 100 comprises: one or a plurality of monitor clients 1, 4 capable of being allocated to individual patients 2 physically closely; and a remote monitor server 3 uploading information from several various monitor clients 1, 4 and downloading information and indications from various sources to the monitor clients 1, 4. In a patient's room, a health care provider can interact directly with the monitor client 1 so as to obtain information associated with a patient 2 or to input indications associated with the patient 2. Many monitor clients 1 can interact with a single monitor server 3. The monitor server 3 can comprise middleware.SELECTED DRAWING: Figure 1

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is related to US Provisional Patent Application No. 61 / 297,544 (Attorney Docket No. H53), filed January 22, 2010, entitled Electronic Instruction Intermediary System for Medical Equipment. Which is a continuation-in-part of U.S. patent application Ser. No. 13 / 011,543 (Attorney Docket No. I52), filed Jan. 21, 2011, claiming priority and designated as Electronic Patient Monitoring System. Are both incorporated herein by reference in their entirety.

The present disclosure relates to patient care. More particularly, the present disclosure relates to a system for electronic patient care,
Method and apparatus.

Providing patient care in hospitals is generally a requirement for many professionals and caregivers (eg, doctors, nurses, pharmacists, technicians, nurse practitioners, etc.) and the treatment of a given patient. Any number of medical device / system interactions are required.

Despite the presence of systems intended to facilitate the caregiving process, such as those incorporating electronic medical records (EMR) and computerized provider instruction entries (CPOEs), directing and delivering medical treatments such as medications The process of providing comprehensive care to patients, including
Several important issues are relevant.

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

In other embodiments, the electronic patient care system can provide the user with editable default values derived from standard medication and dosing guidelines obtained from the drug information database, and the patient's current and existing The user can be alerted of changes that can be indicated based on the 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 or other module of the electronic patient care system is used to indicate directed delivery to the patient's bedside (eg, through a barcode and reader, or an RFID tag and scanner). The drug can also be identified and verified that the appropriate drug and dosage has 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 to provide therapy, 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, signaling a mechanical occlusion to occlude the venous line. Alert the healthcare provider or the like, either directly, by changing the infusion rate, and / or by an alarm built into the first module, or by transmitting an alarm to the second module. It can be configured as follows. In another embodiment, the first module also monitors the condition of the patient, for example, a blood pressure monitor, E
It can be configured to communicate with various patient care devices used to determine patient status parameters, such as CG monitors, pulse oximetry monitors, temperature monitors, and the like. The various parameters measured can be monitored and / or recorded by the mobile device and / or in the EMR. In some cases, the first module can be programmed to alert the patient or other person if 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 healthcare providers at various locations and, in embodiments, can notify the patient to whom the first module has been assigned an abnormality, for example,
Corrective action may be suggested by an audible alert or a recorded message.

In one embodiment, a system for preparing a microinfusion pump comprises a monitoring client, a pharmacy computer, a compound robot, a microinfusion pump, and a data download device. The monitoring client is configured to communicate the prescription instructions via a user interface. Pharmacy computer
Operatively communicates with a monitoring client to receive a prescription order. 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 a prescription instruction. The data download device is configured to download the prescription instructions into the memory of the microinfusion pump.

In some embodiments, the complex robot fills the microinfusion pump with at least one liquid. The compound robot can be in operable communication 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 may receive the prescription instructions from the complex robot and / or the pharmacy computer. In some embodiments, the composite robot receives a prescription order from a pharmacy computer.

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

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 identify the patient-care device and execute the application to monitor the patient-care device. The hub can execute the application in a sandbox component, whereby the application accesses at least one of hardware resources and software resources through the sandbox component.

The hub may be further configured to control the patient care device. Patient care devices, infusion pumps, pills dispenser, micro infusion pump, ECG monitor, blood pressure monitor, a pulse oximeter, CO ₂ capnometers, intravenous bags, and /
Alternatively, one or more of the infusion flow meters may be used.

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

Hardware resources include disk drive, memory, buzzer
, A microphone, a speaker, and a camera. Software resources include variables, secure data objects, secure variables, protected APIs, APIs,
And one of a software representation of hardware components.

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

Hardware resources include disk drives, memory, buzzers, microphones,
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 resources and the monitoring client software resources. The sandbox component is
It is configured to control access to at least one of a hardware resource and a software resource. The monitoring client may be further configured to identify the patient-care device and execute the application to monitor the patient-care device. The monitoring client executes the application in a sandbox component, whereby the application accesses at least one of hardware resources and software resources through the sandbox component. The monitoring client is further configured to control the patient-care device.

Patient care devices, infusion pumps, pills dispenser, micro infusion pump, ECG monitor, blood pressure monitor, a pulse oximeter, and / or CO ₂ capnometers, may be an 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 drives, memory, buzzers, microphones,
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, a system for electronic patient care comprises a monitoring client configured to monitor a patient care device. The monitoring client is a 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 identify the patient-care device and execute the application to monitor the patient-care device. The monitoring client executes the application in a sandbox component, whereby the application accesses at least one of hardware resources and software resources through the sandbox component. The monitoring client may be further configured to control the patient care device.

Patient care devices, infusion pumps, pills dispenser, micro infusion pump, ECG monitor, blood pressure monitor, a pulse oximeter, and / or CO ₂ capnometers, may be an 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 drives, memory, buzzers, microphones,
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, a system for electronic patient care comprises a hub configured to communicate with an electronic medical record and a patient care device. The hub connects the patient and the patient care device (
(E.g., infusion pump). The hub is also configured to download at least one treatment parameter (e.g., infused medication, and / or infusion rate or rate profile, etc.) from the electronic medical record and program the patient-care device with the at least one treatment parameter. I have. The hub uses an RFID interrogator to
Reading ID tags, voice using voice recognition software coupled using a microphone, face using face recognition software coupled to a camera, biometric reading biometric parameters, identification information, barcode Identify the patient according to at least one of the barcode readings by the reader. In one particular embodiment, the hub may download at least one treatment parameter using one or more of the identification techniques described herein.

In another embodiment, a system for electronic patient care comprises a monitoring client configured to communicate with an electronic medical record and a patient care device. The monitoring client is configured to identify a patient and a patient-care device (eg, an infusion pump). The monitoring client is also configured to download at least one treatment parameter (e.g., infused medication, and / or infusion rate or rate profile, etc.) from the electronic medical record and program the patient-care device with the at least one treatment parameter. ing.
The surveillance client reads RFID tags using an RFID interrogator, voice using voice recognition software coupled using a microphone, face using face recognition software coupled to a camera, biometric reading The patient according to at least one of the following biometric parameters, identification information, and 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 for docking the monitoring client thereto. The patient care device is configured to communicate at least one patient care parameter. The device dock is configured to receive the patient-care device for docking the patient-care device therein.

In embodiments, the monitoring client dock and the device dock are configured to communicate wirelessly and while through a cable operatively coupled to the monitoring client dock and the device dock.

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

In another embodiment, the monitoring client dock is configured to wirelessly communicate with the monitoring client, wherein the monitoring client wirelessly communicates at least one patient care parameter with the monitoring client dock to the dock through a cable. Also, operable communication with the patient-care device by communicating with the docked patient-care device.

In another embodiment, the monitoring client does not have communication over the cable available,
And activating at least one patient-care parameter using wireless communication with the monitoring client dock when the monitoring client determines that the monitoring client is undocked from the monitoring client dock. connect.

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

In another embodiment, the monitoring client does not have communication over the cable available,
Communication with the device dock when the communication between the monitoring client and the monitoring client dock is not available and the monitoring client determines that the monitoring client is at least one undocked from the monitoring client dock; Using wireless communication,
The at least one patient care parameter is operatively communicated.

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

In another embodiment, the monitoring client does not have communication over the cable available,
At least one communication between the monitoring client and the monitoring client dock is not available, no communication between the device dock and the patient care device is available, and the monitoring client is undocked from the monitoring client dock. And operably communicate the at least one patient-care parameter wirelessly with the patient-care device if the monitoring client determines one.

In another embodiment, the monitoring client dock and the dock are configured to wirelessly communicate at least one patient parameter. The system further comprises a cable operably coupled to the monitoring client dock and the device dock, wherein the monitoring client dock and the dock include the device dock, the monitoring client dock,
And at least one of the monitoring clients is configured to communicate wirelessly if 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 the plurality of communication links, and the monitoring client communicates via the operable one of the plurality of communication links. .

In another embodiment, the patient care devices, infusion pumps, pills dispenser, micro infusion pump, ECG monitor, blood pressure monitor, one of the pulse oximeter, CO ₂ capnometers, intravenous bags, and 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 status parameter and / or a patient treatment parameter.

In another embodiment, the patient-care device is configured to wirelessly communicate 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 the monitoring device is docked to the device dock, and the monitoring client is docked to the monitoring client dock when 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 the 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 thereto and to receive the monitoring client to dock the monitoring client thereto.

In yet another embodiment, an electronic patient care system comprises 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 the monitoring client are integrated together.

In yet another embodiment, a system for electronic patient care comprises a stackable monitoring client configured to communicate at least one patient care parameter;
A stackable patient care device configured to communicate the two patient care parameters. 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 a patient care device for docking the patient care device therewith. The hub can be plugged into the device dock to establish a communication link therebetween. The system can further include a monitoring client in operative communication with the hub to receive at least one patient care parameter. The 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 transmitting 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 transmitting patient treatment parameters through the hub to the patient-care device.

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

The hub may be configured to monitor the patient care device. In certain embodiments, a hub may include a sandbox component configured to control access to at least one of a hardware resource and a software resource.

The hub may be further configured to identify the patient-care device and execute an application to monitor the patient-care device. The hub can execute the application in a sandbox component, whereby the application accesses at least one of hardware resources 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 monitor configured to receive at least one patient parameter therefrom. A monitoring client in operable communication with the patient monitor and a monitoring server in operable communication with the monitoring client to receive at least one patient parameter from the monitoring client.

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

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

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

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

In another embodiment, a system can include telecommunications operable to communicate with at least one of a monitoring client and a monitoring server.

In another embodiment, the monitoring client may be one of a desk-based device, a portable device, a hand-held 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, wherein 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 dock the monitoring client to the infusion pump.

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

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

In another embodiment, the monitoring server is adapted to format data from multiple databases for downloading the data to the monitoring client. Optionally, and in some specific embodiments, the monitoring client can communicate at least one patient parameter to the monitoring server. In certain embodiments, the patient parameters, treatment progress of the infusion pump, an electrocardiogram signal is one or more of the pressure signal, a pulse oximeter signal, CO ₂ capnometers signals, and / or temperature signal, and / 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 a monitoring device to receive patient parameters.

In another embodiment, the system can further comprise a portable monitoring client. The portable surveillance client can operatively communicate with the surveillance client to communicate directly with the patient information, thereby bypassing the surveillance server. The portable monitoring client may 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 in patient instructions presented via the 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 may further comprise another monitoring client adapted to receive information from a patient-specific database.

The information may 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 may be further configured to input a predetermined set of information to the monitoring client according to the patient information.

A given set of information includes patient age, height, weight, diagnosis, current medication, medication category,
It can 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 include 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 of the plurality of patients on the display. Displaying at least one alert associated with the patient on a display; and selecting a patient from the plurality of patients.

The method may further include, in some particular embodiments, transmitting an alert from the 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; a patient care device configured to communicate at least one patient care parameter; Facilitating communication between the monitoring client and the at least one patient-care device by discovering the presence of at least one patient-care device and converting a communication signal from the device to 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 detect the presence of additional other patient care devices that are different from each other and to convert communication signals from these devices to a communication protocol associated with the monitoring client. I have.

In another particular embodiment, the communication interface is further configured to provide power appropriate for each device. In yet another specific embodiment, the system further comprises a monitoring client that enables at least one of a central storage of patient information and / or 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 particular embodiment, the communication interface further performs a fault check on at least one of the access data integrity of the communication with the patient-care device to evaluate whether the monitoring client is functioning properly, The care device is configured to evaluate whether it is functioning properly and / or to evaluate 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. Discovering the presence of at least one patient-care device and converting communication signals from the device to a communication protocol associated with the hub to facilitate communication between the hub and the at least one patient-care device. And a communication interface configured.

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

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

In yet another particular embodiment, the communication interface further performs a fault check on at least one of the access data integrity of the communication with the patient-care device to evaluate whether the monitoring client is functioning properly, The care device is configured to evaluate whether it is functioning properly and / or to evaluate 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; a patient care device configured to communicate at least one patient care parameter; To facilitate communication between a 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 the device to a communication protocol associated with the dock And a configured communication interface.

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

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

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

In an embodiment, a patient care device includes a body, a track in the body configured to receive the post, and a track coupled to the body and configured to functionally lock the body to the post in the track. And two functional members.

In embodiments, the hub includes a patient care device interface and a patient care device interface.
A power supply coupled to the interface and configured to supply power to the patient care device; a processor; and a patient care device interface configured to enable communication between the processor and the patient care device. And a transceiver. The processor, in some particular embodiments, can be configured to disable the patient-care device when in an alarm condition.

In an embodiment, the dock includes a patient-care device interface, a power supply coupled to the patient-care device interface, and configured to supply power to the patient-care device, a processor, and a processor between the processor and the patient-care device. A transceiver coupled to the patient-care device interface configured to enable communication. The processor, in some particular embodiments, can be configured to disable the patient-care device when in an alarm condition.

In an embodiment, a communication module includes a patient care device interface, a power supply coupled to the patient care device interface, and configured to supply power to the patient care device, a processor, and a patient care device and another device. A transceiver coupled to the patient-care device interface configured to allow communication with the transceiver. The processor, in some particular embodiments, can be configured to disable the patient-care device 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 a monitoring client. The modular patient-care device can interface with the dock alternately or via a connector along a horizontal plane.

In yet another embodiment, an electronic patient care system is a first module configured to receive and store information about a patient, wherein the information is measured by a device connected to the patient. A first module including data related to a first parameter and data related to a second parameter of the patient received from a first database including information about the patient, and a user interface associated with the second module And a second module configured to receive the medication instruction from the user via the first module, the second module configured to communicate the treatment instruction to a first module, the first module further comprising: , A) drug information relating to said drug or other drug from the second database, wherein such drug is commonly 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 determining whether a confirmation must be made by the second module based on the value of the second parameter and c) confirming or accepting the acceptability of the medication indication for display on a user interface. It is configured to communicate a pre-established message to warn 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, and the first parameter or the second parameter is a patient parameter. Includes 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 may include an alert regarding a potential effect of the indicated medication, wherein the alert may be measured data for the first parameter, received data for the second parameter, or by the first module. The obtained drug information is included.

The first module processes a drug indication or a modified drug indication upon receipt of a confirmation signal from a second module triggered by an input signal from a user interface after a pre-established message has been transmitted. Can be configured to generate a signal to be generated.

In another embodiment, a patient-care device includes a first communication link and a second communication link, and the dock includes a first communication link and a second communication link. If the patient care device is within a predetermined range at the dock, the patient care device and the dock
Are paired using the second communication link, and remain in communication using the second communication link after the pairing. Pairing that occurs using the first communication link can pair the patient-care device and the dock with the second communication link. The first communication link may be a short-range wireless communication, and the second communication link may be a Bluetooth, Bluetooth Low Energy, WiFi, or other communication link.

In another embodiment, the patient-care device includes a first communication link and a second communication link, and the monitoring client includes a first communication link and a second communication link. If the patient-care device is within a predetermined range of the monitoring client, the patient-care device and the monitoring client are paired using the first communication link and, after pairing, using the second communication link. Stays in communication. Pairing that occurs using the first communication link can pair the patient-care device and the monitoring client with the second communication link. The first communication link may be a short-range wireless 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 having a user interface template stored therein. The user interface template may 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 may be configured to display one or more patient care parameters received from the patient care device (eg, in real time).

In yet another embodiment, an infusion pump includes attachable electronic components. The attachable electronic component comprises 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 supply for providing at least one of communication capability and power to the patient-care device.
One or more.

In yet another embodiment, a wearable system monitor includes a watchdog component and a transceiver. The wearable system monitor may include a processor coupled to the watchdog component and the transceiver to perform a watchdog function on at least one paired device. The paired device may be at least one of a dock, a hub, a monitoring client, and / or a 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 parameters to the monitoring server, de-identifying the patient-care parameters, and / or Storing one or more of the de-identified patient care parameters in the monitoring server.

In yet another embodiment, a method includes establishing a communication link between a monitoring server and a plurality of patient-care devices associated with a plurality of patients, transmitting a plurality of patient-care parameters from the plurality of patient-care devices to the monitoring server. Communicating, de-identifying the patient-care parameters, storing the patient-care parameters in the monitoring server, treating the plurality of patients, and associating the plurality of patients to determine the effectiveness of the treatment. Analyzing one or more subsets of the determined plurality of 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, the non-volatile memory of the patient-care device Storing one or more patient-care parameters in the memory, loading one or more patient-care parameters in an operating memory, and resuming operation of the patient-care device.
One or more. The method may 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, such as an infusion pump, comprises calculating one or more operating parameters associated with the patient-care device; Storing one or more operating parameters into the operating memory, loading one or more operating parameters into the operating memory, and resuming operation of the patient-care device. The method may include, in additional embodiments, determining that operation of the patient-care device can resume.

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

In yet another embodiment, a method includes docking a patient-care device in a dock, identifying a patient-care device, querying a 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, a method includes arranging a patient care device in operable communication with a 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, a method includes positioning a patient-care device in operable communication with a dock. The dock can identify the patient-care device, query the server for an application for controlling the patient-care device, download the application into the dock, run the application, The application can be used to control a patient-care device.

In yet another embodiment, a method includes arranging a patient care device in operable communication with a monitoring client. The monitoring client can identify the patient care device, can query the server for an application for controlling the patient care device, can download the application to the monitoring client, and can execute the application , The patient care device can be controlled using the application.

In yet another embodiment, a method includes presenting a request on a user interface of a communication device, confirming the request, sending the request, receiving the request with a check value, and transmitting the check value. A step may be included to confirm that a previous request has been followed.

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

In yet another embodiment, the hub includes at least one of an electronic medical record, DERS, CPOE, and / or the Internet to control and / or monitor the patient care device.
And operably communicate with one another.

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

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

In an embodiment, a patient-care device includes 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 post. The adapter can be coupled to the dock. The adapter can include at least one electronic coupler to position the patient-care device in operable 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 fault tolerant for 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. 2 is a flowchart 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. 6 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 illustrating a method for maintaining communication between the monitoring client of FIG. 3 and a patient-care device according to an embodiment of the present disclosure. FIG. 10 is a block diagram of an electronic patient care system having a dock for docking a monitoring client and a patient care device together, according to yet another embodiment of the present disclosure. FIG. 6 is a flow chart 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. 10 is a block diagram of an electronic patient care system having a monitoring client with an integrated dock for docking a patient care device thereto according to yet another embodiment of the present disclosure. FIG. 7 is a block diagram of an electronic patient care system having a hub according to yet another embodiment of the present disclosure. FIG. 10 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. 4 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. 4 is a flowchart diagram of a method for collecting patient care parameters of a number of patients in a monitoring server according to an embodiment of the present disclosure; FIG. 5 is a flowchart 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. 5 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. 4 is a flowchart diagram of a method for monitoring operation of a patient care device using a wearable system monitor paired with the patient care device according to an embodiment of the present disclosure; FIG. 4 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. 6 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. 4 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. FIG. 6 is a block diagram of an electronic patient care system according to another embodiment of the present disclosure. 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. FIG. 3 illustrates an electronic patient care system having a tablet docked in a dock having a cable electrically coupled to a patient care device, according to an embodiment of the present disclosure. FIG. 4 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. 2 illustrates an electronic patient care system having a modular infusion pump docked in a dock having a monitoring client with a retractable user interface, according to an embodiment of the present disclosure. FIG. 24 is a side view of the electronic patient care system of FIG. 23, according to an embodiment of the present disclosure. FIG. 9 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. 8 illustrates an electronic patient care system having a modular infusion pump docked in a dock along a common horizontal plane, including a monitoring client with a retractable user interface, according to yet another embodiment of the present disclosure. FIG. 27 is a side view of the electronic patient care system of FIG. 26, according to another embodiment of the present disclosure. According to yet another embodiment of the present disclosure, there is provided a modular infusion pump docked in a dock along a common horizontal plane, including a monitoring client with a retractable user interface, and a hub coupled to the scanner and the dock. It is a figure which shows the electronic patient care system which has. 29 is a side view of the electronic patient care system of FIG. 28, according to another embodiment of the present disclosure. FIGS. 7A and 7B are several views illustrating a clutch system for mounting an electronic patient care system on a post, according to an embodiment of the present disclosure. FIGS. FIG. 4 illustrates an infusion pump and a dock coupled to a post, according to an embodiment of the present disclosure. FIG. 7 illustrates 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 coupled to the open connectors, respectively, according to 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. 4 illustrates a square hub with several connectors, according to an embodiment of the present disclosure. FIG. 6 illustrates an electronic patient care system having a hub coupled to a post, according to another embodiment of the present disclosure. FIG. 4 illustrates an electronic patient care system having a post and a hub coupled to the portable dock with a quick release handle for removing the portable dock from the hub, according to another embodiment of the present disclosure. FIG. 9 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. 6 illustrates an electronic patient care system having a hub coupled to a post, according to another embodiment of the present disclosure. FIG. 4 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 mating with a notch in a hub as shown in FIG. 42, according to another embodiment of the present disclosure. FIG. 4 illustrates a stackable patient care device and an electronic patient care system having a stackable container for storing an infusion bag, according to another embodiment of the present disclosure. FIG. 7 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. 4 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. 4 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. 6 illustrates another embodiment of an electronic patient care system illustrating removal of a stackable patient care device, according to another embodiment of the present disclosure. FIG. 4 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 stackable patient care devices according to another embodiment of the present disclosure. FIG. 3 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. 6 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 on a strut, according to another embodiment of the present disclosure. FIG. 57 is a rear view of the clutch system of FIG. 56 showing a transparent back, 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. 1 is a block diagram of an electronic patient care system having a hub to communicate with some electronic patient care devices according to embodiments of the present disclosure. 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. 4 is a process diagram illustrating some stages of electronic patient care according to an embodiment of the present disclosure. FIG. 4 illustrates several arrangements of an electronic patient care system according to embodiments of the present disclosure. FIG. 4 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 showing the timing diagram of FIG. 67, according to an embodiment of the present disclosure. FIG. 4 illustrates an additional arrangement of an electronic patient care system according to an embodiment of the present disclosure. FIG. 4 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 showing the timing diagram of FIG. 71 according to an embodiment of the present disclosure; FIG. 9 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 showing the timing diagram of FIG. 73, according to an embodiment of the present disclosure. FIG. 9 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 showing the timing diagram of FIG. 75, according to an embodiment of the present disclosure. FIG. 4 illustrates several arrangements of an electronic patient care system according to embodiments of the present disclosure. FIG. 9 is another timing diagram for electronic patient care using an infusion pump, according to another embodiment of the present disclosure. FIG. 81 is a flowchart diagram of a method showing the timing diagram of FIG. 79, according to an embodiment of the present disclosure; FIG. 9 is another timing diagram for electronic patient care using an infusion pump, according to another embodiment of the present disclosure. FIG. 81 is a flowchart diagram of a method showing the timing diagram of FIG. 81, according to an embodiment of the present disclosure. FIG. 6 illustrates some additional embodiments of an electronic patient care system, according to some embodiments of the present disclosure. FIG. 3 is a block diagram of the electronics of the hub embodiment, according to an embodiment of the present disclosure. FIG. 2 is a block diagram of an electronic circuit for interfacing with an infusion pump, according to an embodiment of the present disclosure. FIG. 7 illustrates another embodiment of an electronic patient care system having vertically arranged patient care devices docked in a dock, according to an embodiment of the present disclosure. FIG. 3 is a block diagram of the electronics of the hub embodiment, according to an embodiment of the present disclosure. 1 is a block diagram of an electronic circuit of a communication module according to an embodiment of the present disclosure. 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 some of the electronic circuitry of the dock, according to some embodiments of the present disclosure. FIG. 2 is a block diagram of a battery pack according to an embodiment of the present disclosure. FIG. 9 illustrates an additional embodiment of a dock electronic circuit according to additional embodiments of the present disclosure. FIG. 4 illustrates some embodiments of a mountable pump mounted on a monitoring client, according to additional embodiments of the present disclosure. FIG. 4 illustrates a backplane for use with an infusion pump, according to an embodiment of the present disclosure. FIG. 117 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 a mountable pump mounted on a monitoring client, according to additional embodiments of the present disclosure. FIG. 4 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. 2 is a diagram of an electronic circuit that converts short-range wireless communication to UHF according to an embodiment of the present disclosure. FIG. 4 illustrates some antennas according to additional embodiments of the present disclosure. FIG. 4 illustrates a patient wristband with an RFID tag attached thereto, according to an embodiment of the present disclosure. FIG. 128 illustrates a split ring resonant circuit for use on the wrist band of FIG. 128, according to an embodiment of the present disclosure. FIG. 4 illustrates a near-field antenna according to an embodiment of the present disclosure. FIG. 130 illustrates an equivalent circuit of the split ring resonant circuit of FIG. 130, according to an embodiment of the present disclosure. FIG. 5 illustrates a 5R checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. FIG. 4 illustrates a blockade checklist that can be displayed on a monitoring client according to an embodiment of the present disclosure. FIG. 4 illustrates a display of a monitoring client in operative communication with a number of infusion pumps, according to an embodiment of the present disclosure. FIG. 4 is an illustration of a display on a healthcare provider's portable monitoring client showing a list of patients whose information the provider can access, according to an embodiment of the present disclosure. A 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 showing the above display. FIG. 7 illustrates a display on a healthcare provider's portable monitoring client showing a data entry area for a medication prescription for use with an intravenous infusion pump, according to an embodiment of the present disclosure. FIG. 5 illustrates a display on a healthcare provider's portable monitoring client showing a risk profile associated with the indicated medication and a proposed course of action as generated by the monitoring client, according to embodiments 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. 7 illustrates a display on a healthcare provider's portable monitoring client, showing how the monitoring system can display to the indicating provider a confirmation that the prescription has been communicated to the pharmacist, in accordance with 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. FIG. 2 is a perspective view of a wireless hub device wirelessly relaying data from a patient-care device to a monitoring client, another hub, or a dock, according to an embodiment of the present disclosure. 1 is a front perspective view of an electronic patient care system having a modular patient care device coupled to a monitoring client via an adapter and a dock, according to an embodiment of the present disclosure. FIG. 145 is a side perspective view of the electronic patient care system of FIG. 143, according to an embodiment of the present disclosure; FIG. 145 is an enlarged perspective view of one interface of the patient care device shown in FIG. 143, according to an embodiment of the present disclosure. FIG. 145 is a top view of the electronic patient care system of FIG. 143, according to an embodiment of the present disclosure. 1 illustrates a system for an electronic patient care system according to an embodiment of the present disclosure. 1 is a block diagram of an electronic patient care system according to an embodiment of the present disclosure. FIG. 148 is a block diagram of a bedside portion of the electronic patient care system of FIGS. 147 and / or 148, according to an embodiment of the present disclosure. FIG. 147 is a block diagram of the dock / hub of FIGS. 147, 148, and / or 149, in accordance with an embodiment of the present disclosure. FIG. 149 is a block diagram illustrating the infusion pump circuit of FIGS. 148 and / or 149, according to an embodiment of the present disclosure. FIG. 4 is a block diagram illustrating a sensor coupled to an infusion pump mechanism, according to an embodiment of the present disclosure.

Techniques for facilitating patient care have been disclosed. The techniques may be implemented, for example, in a system having one or more patient-care devices communicatively coupled to a monitoring client, according to one exemplary embodiment. A patient-care device can include any number of a variety of 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 is discovery and protocol conversion and various interfaces such as, for example, power delivery, compliance with various standards, and user interfaces. And other functions. Patient care devices include infusion pumps, microinfusion pumps, insulin pumps, syringe pumps, pill dispensers, dialysis machines, ventilators, ultrasound diagnostics, ECG monitors, blood pressure monitors, pulse oximeters, CO ₂ A capnometer, an infusion counter, an infusion flow meter, an optical Doppler device, a heart rate monitor, an intravenous bag, a hemodialyzer, a peritoneal dialysis machine, an intestinal dialysis machine, a patient thermometer, and / or another bedside patient care device Is also good. US patent application Ser. No. 11 / 704,899, filed Feb. 9, 2007, entitled Fluid Delivery Systems and Methods, and subsequently published U.S. Patent Application Publication No. 2007-0228071-A1, published Oct. 4, 2007. No. (Attorney Docket No. E70), 2007
U.S. Patent Application No. 11 / 704,896, filed February 9, 2007, entitled "Using Pump Fluid Delivery System and Force Applying Assembly," and subsequently published on September 20, 2007. Publication No. 2007-0219496 (Attorney Reference Number E71
U.S. Patent Application Publication No. 11 / 704,886, filed February 9, 2007, entitled Patch Size Fluid Delivery Systems and Methods, and subsequently published on September 20, 2007. No. 2007-0219481 (Attorney Reference Number 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 Sep. 20, 2007. Publication No. 2007-0219597 (Attorney Reference Number E73),
U.S. Patent Application No. 12 filed December 31, 2008, entitled Infusion Pump Assembly
U.S. Patent Application Publication No. 2009-0299277 (Attorney Docket No. G75), which was subsequently published on December 3, 2009, filed on December 31, 2008, and filed on Dec. 31, 2008. US patent application Ser. No. 12 / 347,9 entitled Assembly
No. 82, then U.S. Patent Application Publication No.
No. 0281497 (Attorney Docket No. G76), filed December 31, 2008, and US patent application Ser. No. 12 / 347,981, entitled Infusion Pump Assembly, which was subsequently published on November 5, 2009. U.S. Patent Application Publication No. 2009-0275896 (Attorney Docket No. G77), filed December 31, 2008, and in U.S. Patent Application No. 12 / 347,984, entitled Pump Assembly With Switch. U.S. Patent Application Publication No. 2009-0299289 (Attorney Docket No. G79), subsequently published December 3, 2009, filed October 10, 2008, United States Patent Application entitled Infusion Pump Assembly No. 12 / 249,882, which was subsequently published on Apr. 15, 2010, U.S. Pat. No. 0094222 (Attorney Docket No. F51), 200
US patent application Ser. No. 12 / 249,636, filed Oct. 10, 2008, entitled Systems and Methods for Administering Injectable Fluids, and subsequently published on Apr. 15, 2010. No. 2010-0094261 (Attorney Reference Number F52), 20
U.S. Patent Application No. 12 filed October 10, 2008, entitled Occlusion Detection System and Method
U.S. Patent Application Publication No. 2010-0090843 (Attorney Docket No. F53), filed Oct. 10, 2008, Multilingual / Multi U.S. Patent Application Serial No. 12 / 249,600 entitled Processor Infusion Pump Assembly, which was subsequently published on April 15, 2010, U.S. Patent Application Publication No. 2010-0094221 (Attorney Docket No. F54) ), 2011 11
U.S. Patent No. 8,066,672 (Attorney Docket No. F55), issued September 29, 2011, issued September 29, 2011, entitled Infusion Pump Assembly with Backup Power Supply. US Patent No. 8,016,789 (Attorney Docket No. F56) entitled Pump Assembly with Assembly, issued December 11, 2007, US Patent No. 7 entitled Load Mechanism for Infusion Pump No., 306,578 (Attorney Docket No. C54), all of which are incorporated herein 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 earlier, the process of providing comprehensive care to patients, such as directing and delivering medical treatment, involves several important issues. For example, great potential for important information being miscommunicated, treatment decisions being made without preparing for access to complete information, and / or delays in prescription implementation due to unnecessary redundant and inadequate procedures. There is.

More specifically, medication errors can cause hundreds of deaths, and every year in the United States alone,
It can hurt thousands or even millions. Hospitals that are under financial pressure may have experienced many medication error accidents. Medications associated with many dangerous mistakes include insulin, narcotics, heparin, and chemotherapy. Medication errors can be caused by administering the wrong drug, dispensing the wrong concentration of the drug, delivering the drug at the wrong rate, or delivering the drug by the wrong route ( Can be administered intravenously, intramuscularly, subcutaneously, intrarectally, topically to the skin, eyes or ears, intrathecally, intraperitoneally, or even intravesically). Can be Even with the proper sequence and proper labeling, unreadable handwriting, incorrect transmission of drug prescriptions, and incorrect pronunciation of drugs with similar names can still cause drugs to be improperly administered. is there. There has been a trend to use barcode systems for electronic medical records (EMR) and medications to reduce medication accidents. The EMR system may include, for example, a computer provider indication input (C) that does not match the patient's diagnosis, allergy, weight, and / or age.
POE) and flag prescriptions 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 one-third) of all medication errors that result in significant damage. The wrong drug is suspended, incorrect parameters (eg drug concentration or infusion rate) are entered,
Or existing injection parameters may be inappropriately changed. 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 monitor and arbitrate at any stage of the drug ordering and administration process to minimize any of several adverse events that may be due to 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 medication prescription is written or entered, when the medication is retrieved or mixed into solution, or when the medication 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 a communication signal from the device to a communication protocol associated with the monitoring client. An electronic patient care system having 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 a communication module described below. The communication interface may further detect the presence of other additional patient care devices that differ from each other (eg, various manufacturers, features, and / or communication protocols, etc.) and communicate communication signals from these devices to a monitoring client or hub. It can be configured to convert to an associated communication protocol. Therefore,
The communication interface effectively uses a surveillance client, such as a tablet computer, as a common generic user interface that healthcare providers can use in providing treatment to patients associated with the surveillance client It becomes possible. One or more databases accessible by the monitoring client provide central storage of patient information (in any format and database structure desired by the healthcare facility or database maintenance provider) and treatment of the patient associated with the monitoring client. Allows the downloading of information that can be used by healthcare providers during The communication interface can be implemented in several ways, using wired and / or wireless technologies, to enable seamless communication and fail-safe operation of multiple patient-care devices. Some patient-care devices, hubs, docks, and / or surveillance clients may 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 portablely used, for example, by including batteries and sufficient circuitry for mobile operation of the patient-care device, such as an infusion pump. Additionally or alternatively, the patient wristband can include a battery that can be plugged into a 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, in some embodiments, real-time parameters) 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, each of which can be assigned in close physical proximity to an individual patient 2, and a number of different The remote monitoring server 3 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's room, the healthcare provider can interact directly with the monitoring client 1 to get information about the patient 2 or to enter instructions about 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). Additionally or alternatively, a provider at a remote location (eg, a doctor's office, a nurse's station 5, a hospital pharmacy 6) may connect each monitoring client 1, 4 via a communication link with the monitoring server 3 or. It can interact directly with the individual monitoring client 1 via the hospital local area network it has as a node.

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

Pharmacy 6 may include one or more computers connected to a network, for example, the Internet, to receive and queue the prescriptions in one or more computers. The pharmacy uses (1) (e.g., an automated compounding device capable of compounding fluids or producing pills coupled to one or more computers, or a queue of one or more computers). Dispensing the drug (manually by a pharmacist who monitors), (2) pre-filling the fluid reservoir of the syringe pump 126, (
3) Program the syringe pump 126 (eg, if the treatment plan is syringe pump 1
26), (4) prefill microinfusion pump 130, (5) program microinfusion pump 130, (6) prefill intravenous bag 170, (7) Program infusion pump 7, (8) prefill 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 may be a syringe pump 126, an intravenous bag 170 or a microinfusion pump 1
One or more of the 30 may be automatically filled with fluid and / or the pill dispenser 128 may be automatically filled with pills. The automated compounding device can generate barcodes, RFID tags, and / or data. Barcode, RF
The information in the ID tag and / or data can include a treatment plan, a prescription, and / or patient information.

The automatic compounding device includes (1) attaching the barcode to the infusion pump 7, the syringe pump 126, the microinfusion pump 130, the pill dispenser 128, or the intravenous bag 170, and (2) attaching the RFID tag to the infusion pump 7, the syringe. -Attach 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, pill with information or data. Dispenser 128,
Alternatively, an RFID tag or memory in the intravenous bag 170 can be programmed. The data or information can be obtained, for example, by using a barcode, RFID tag, or serial number or other identifying information in memory to inject the prescription into the infusion pump 7, syringe pump 126,
It can be sent to a database (e.g., the patient's EHR 19 or the patient's 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,
Alternatively, the pill dispenser 128 may be (1) syringe pump 126 or intravenous bag 1
70 has the correct fluid, (2) microinfusion pump 130 has the correct fluid, (3) pill dispenser 128 has the correct pill, (4) infusion pump 7, syringe pump 126, the microinfusion pump 130, or the therapy programmed into the intravenous bag 170
26, whether the fluid in micro infusion pump 130, or intravenous bag 170 is compatible, (5) whether the treatment programmed in pill dispenser 128 is compatible with the pill in pill dispenser 128 And / or (6) a therapy programmed into the infusion pump 7, syringe pump 126, microinfusion pump 130, or pill dispenser 128 (eg, a patient barcode, RFI).
A scanner (e.g., an RFID interrogator or barcode scanner) may be provided to determine if it is correct for a particular patient (as determined from D or other patient identification information). That is, in some particular embodiments, the infusion pump 7, the syringe pump 126, the microinfusion pump 130, and / or the pill dispenser 128 read one or more serial numbers from an RFID tag or barcode. , Match the value as found in the internal memory (eg, downloaded via an automatic compounding device), or the value was stored (eg, in the patient's EHR 19 or the patient's personal EHR 19 ′). (E.g., via the patient's serial number as determined by scanning the patient's RFID tag or scanning the barcode by the patient) to ensure that it matches the value found in the patient's electronic medical record it can.

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

Additionally or alternatively, the monitoring client 6 includes (1) the syringe pump 1
26 or intravenous bag 170 has the correct fluid, (2) microinfusion pump 130 has the correct fluid, (3) pill dispenser 128
Whether the patient has the correct pills, (4) the therapy programmed in the infusion pump 7, syringe pump 126, microinfusion pump 130, or intravenous bag 170 is the same as the syringe pump 126, microinfusion pump. Whether the treatment programmed in the pill dispenser 128 corresponds to the pill in the pill dispenser 128, and / or (6) whether the treatment programmed in the pill dispenser 128 corresponds to the fluid in the iv. Infusion pump 7, syringe pump 126, microinfusion
Therapy programmed into the pump 130 or pill dispenser 128 (eg,
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) The pump 130 or the intravenous bag 170 can be scanned. Additionally or alternatively, 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
, A microinfusion pump 130, a pill dispenser 128, or a barcode serial number on an intravenous bag 170 to verify or download a prescription using an electronic medical record database 19 or 19 'and And / or to the pharmacy 22.

Optionally, providing instructions or requests to the patient-care device 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148 to transmit the bolus volume, infusion flow, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile, for example, to infusion pump 7, syringe Monitoring client 1, other monitoring clients 4, and / or remote communicator 11 can be used to send to pump 126 and / or microinfusion pump 130. In some embodiments, the monitoring is performed to send instructions or requests to the pill dispenser 7, such as, for example, pill dispensing instructions, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills. 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 on demand (ie, as needed), but if overdose, the drug may not be safe, and the maximum pill distribution criteria is It can be prevented from being taken at an unsafe level, for example 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 raised or transmitted, determine whether a treatment or condition is safe for the patient,
0 monitors the data to determine if it is operating properly or at predetermined boundaries and / or display the data on the display of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. A reply can be sent to the client 1, the other monitoring client 4, and / or the remote communicator 11. For example, optionally, the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 may include an upstream pressure, an upstream pressure change, a downstream pressure for the patient 2, a downstream pressure for the patient 2. Changes, the presence or absence of air in the infusion line, the actual bolus volume delivered, the actual infusion flow rate, the actual total fluid delivered, the actual start time of drug delivery, the actual stop time of drug delivery, or the actual The delivery flow profile can be communicated (if applicable) to one or more of monitoring client 1, other monitoring clients 4, and / or 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 whether a maximum pill dispensing threshold has been exceeded. Such as data,
Monitoring client 1, other monitoring clients 4, and / or remote communicator 11
You 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 generate an alarm and / or an alarm. For example, one or more of the monitoring clients 1, 4, 11 may be downstream due to material such as excessive coagulation, penetration, occlusion or bending of the tubing to the patient, or contamination found in, for example, intravenous bag 170. One indication of the resulting blockage, an increase in pressure downstream of the infusion pump 7, the syringe pump 126 and / or the microinfusion pump 130, may be used. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly alert or alert the user. These alarms and / or alerts may also inform the nurse of other appropriate actions, such as occlusion (eg, caused by coagulation) when downstream pressure on the patient rises above a predetermined threshold. A suggestion may be made to make a suggestion to change the needle, or to check for kinks in the line if the downstream pressure on the patient rises above a predetermined threshold.

Additionally or alternatively, the sharp drop in downstream pressure on the patient 2 is an indication that the tubing has disconnected from the needle and / or that the needle is now disconnected from the patient, and, accordingly, One or more of the monitoring clients 1, 4, 11 may visually or audibly alert or alert the user to reattach tubing to a needle or insert a new needle for continuous infusion. Can be. The alarm may also indicate that the patient is bleeding, for example, when the tubing is disconnected from the needle, and that the patient is bleeding due to an unattached needle coupler, requiring rapid action. It may indicate that

In some embodiments, additionally or alternatively, the upstream pressure on one or more infusion pumps 7 can be monitored for any upstream occlusion. For example, contamination in the intravenous bag 170 can block tubing upstream of the infusion pump 7. Each time infusion pump 7 attempts to pump fluid from intravenous bag 170,
The upstream pressure on the infusion pump 7 can be lower than would occur without upstream obstruction. Thus, one or more of the monitoring clients 1, 4, 11 may issue an alarm or alarm when the upstream pressure drops below a predetermined threshold, for example, by a caregiver replacing a plumbing or intravenous bag 170. May suggest or require relief of the obstruction.

One or more of the monitoring clients 1, 4, 11 is optionally provided with an infusion pump 7, a syringe, Pump 126 and / or microinfusion pump 1
An indication can be sent to one or more of the 30.

As shown in FIG. 1, and similar to 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
Although 4 is shown as capable of receiving a number of patient-care devices, in other embodiments, device dock 104 may include one patient-care device, multiple patient-care devices, or any patient-care device. Any number of patient care devices can be received. in addition,
Although the monitoring client dock 102 is shown as capable of receiving one monitoring client 1, in other embodiments, the monitoring client dock 102 has two monitoring clients 1, three or more monitoring clients 1. It is possible to receive a client 1, or any 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
Or can be permanently attached to one or both of the two. Additionally or alternatively, cable 110 may include one or more connectors (not explicitly shown) for plugging the cable into one or both docks 102, 104.

In some embodiments, docks 102, 104 can communicate with one another using one or more wires and / or waveguides within cable 110. For example, in an embodiment of the present disclosure, cable 110 comprises a fiber optic waveguide to provide an optical communication link between docks 102,104. In other embodiments, as will be appreciated in light of the present disclosure, cable 110 may be replaced with one or more wireless communication links (eg, Bluetooth, etc.) if desired. Still another embodiment is a dock 1
02 and 104, a combination of wired and wireless communication channels 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 may be any known communication link, such as serial, parallel, synchronous, asynchronous, packet-based, virtual circuit-based, etc. Can be used. Additionally or alternatively, in some embodiments, the communication link established between docks 102, 104 may be a wireless communication, a wired communication, a connectionless protocol, such as the 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 may be universal serial bus standard, 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 the communication between the docks 102,104. For example, in some embodiments of the present disclosure, monitoring client 1 may communicate with electronic circuitry, such as memory, in device dock 104 via a communication link provided by cable 110. Additionally or alternatively, the monitoring client 1 may communicate with any device docked to the device dock 104 via a communication link provided by the cable 110 and / or one or more wireless communication links. (Described in more detail below).

With further reference to the exemplary embodiment shown in FIG. 1, the device dock 104 can include various accessories, such as an optional attachable display 134, a camera 136, and a microphone 138, each of which is optional. Similarly, surveillance client dock 102 can include various accessories, such as camera 140 and 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 facial recognition software, for example, to authenticate or identify the presence of a provider (eg, a nurse, nurse practitioner, doctor, 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 seen in light of the present disclosure, cameras 136, 140,
144 and microphones 138, 142, 146 may allow a patient to communicate with a telecare provider before commencing treatment, for example, to ensure that the correct patient receives the correct treatment, and / or
Alternatively, it can be used to allow the identification of the patient (eg, using voice and / or face recognition techniques, retinal scans, etc.).

As shown in FIG. 1, in some embodiments, monitoring client 1, monitoring client dock 102, and device dock 104 each include an antenna 11 for wireless communication.
2, 106, and 108 (each antenna 112, 106, and / or 108
Is optional). Cable 110 is unplugged or dock 10 via cable 110
If the communication between the two 104 is otherwise interrupted or compromised, the monitoring client dock 102 and the device dock 104 communicate with each other using the wireless communication link established through the antennas 106, 108. You can continue to do. In addition to it,
If the monitoring client 1 is detached from the monitoring client dock 102, the monitoring client 1 can communicate directly with the device dock 104, for example, and / or the monitoring client 1 can connect 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, which relays the communication over the wireless communication link between the devices. As previously described, the 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 to 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 two electrical contacts on the connector of the monitoring client 1 used for docking to the monitoring client 02 and for providing electrical communication between the monitoring client dock 102 and the monitoring client 1 To electrically 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 monitoring client 1 determines that monitoring client 1 is not electrically coupled to cable 110, monitoring client 1 may determine that cable 110 is not available. Additionally or alternatively, in some embodiments, a magnet in dock 102 engages a Hall effect sensor in monitoring client 1, after which cable 110 is disconnected if monitoring client 1 is undocked. The monitoring client 1 uses this to determine if it is docked as if it were not available as a communication link. Additionally or alternatively, circuitry within the monitoring client dock 102 can signal the monitoring client 1 if a cable is not available as a communication link. In some embodiments, the monitoring client 1 periodically “connects” the device dock 104 to the device dock 104 via the cable 110.
"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 raise an alarm or alarm using a speaker and / or a vibration motor. 11 to alert or alert the remote communicator using speakers and / or vibration motors, and / or the monitoring client 1 to communicate with the patient-care device via another communication link. You can try. The term "alarm" as used herein is intended to include "soft" alerts, such as, for example, an alert that does not alert a person after a predetermined period of time has passed and the cause of the alert remains. are doing.

In some embodiments of the present disclosure, surveillance client dock 102 includes one or more wires or waveguides from surveillance client 1 to cable 110 with or without minimal circuitry. For example, in some embodiments of the present disclosure, monitoring client dock 102 is a cradle that provides a direct electrical connection from monitoring client 1 to cable 110. Additionally or alternatively, in some embodiments of the present disclosure, device dock 104 may include a variety of docked devices via monitoring client dock 102, with or without minimal circuitry. And / or includes one or more wires or waveguides that facilitate communication between monitoring clients 1.
Device dock 104 may be a cradle in some embodiments.

In embodiments of the present disclosure, each monitoring client 1 is assigned to a particular patient 2 and may be desk-based, portable or hand-held, and may have display and user input capabilities. The monitoring client 1 may be portable and facilitate efficient data browsing and data entry, and the monitoring client 1 may be a notebook PC, a netbook PC with or without a touch screen. , Tablet PC, or “smart phone”. Additionally or alternatively, in some embodiments, the monitoring client 1 and / or the remote communicator 11
Docked or coupled to a cable connected to a much larger display, so that a much larger display (eg, a 24-inch display) can be the display of the monitoring client 1 and / or the remote communicator 11, The large display may have input capabilities such as touch screen capabilities, touch pen input capabilities, keyboard input capabilities, remote control input capabilities, etc., that are communicated to the monitoring client 1 and / or the remote communicator 11. For example, viewing x-ray or patient imaging files can be facilitated by docking the monitoring client 1 and / or the remote communicator 11 to a monitoring dock coupled to a larger display, thereby providing a caregiver. Can view patient imaging files using a larger display. The viewing 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, an iOS,
It can execute an iPad OS, an iPhone OS, or the like. 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 a bar code 114 embedded in a wristband 118 or an RFID tag 116, for example. This can be done using any of several methods, including: Device dock 104 includes a scanner 120 to determine the unique patient identifier of barcode 114 or RFID tag 116. Scanner 120 may be a laser barcode scanner, CCD-based barcode scanner, short-range communicator or interrogator, RF
It may be an ID reader or the like. In other embodiments, the unique patient identifier can be based on the patient's biometric data. In one such example case, biometric capabilities (eg, face and / or voice recognition, retinal scan, blood type monitor, fingerprint scan, etc.) can be embedded or associated within the monitoring client 1. . The device dock 104 monitors the unique patient identifier to facilitate treatment of the patient 2.
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 includes a microprocessor, a microcontroller, a
One or more of a logic device, a digital circuit, an analog circuit, and the like 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 status parameter of blood pressure, body temperature, heart rate, pulse oximeter, CO ₂ levels, blood oxygen levels, patient awakening, the patient's consciousness, a measure such as the patient's response. Some exemplary patient treatment parameters include the drug, drug or liquid flow to be administered, drug administration schedule, 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 installed, can be installed, can be removed therefrom, or can be installed. Can be removed. This can be achieved by a docking interface between two devices, for example, a monitoring client dock 102 and a device dock 104. In one such embodiment, the monitoring client 1 may connect to the docks 102, 104 through electrical connectors, for example, via electrical connectors.
Or communicate with the pump 7 (or other patient-care device) in a number of ways, including wirelessly by a transceiver on each device using respective antennas 112, 122A.
Additionally or alternatively, the infusion pump may include pre-programmed therapy data indicative of 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
0 and / or with a healthcare provider using the portable communicator 11 (including, for example, physicians, nurses, and pharmacists). This may be by 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.). In one embodiment, access to the intra and extra equipment databases is brokered 13 (e.g., using middleware) through the monitoring server 3 and then to communicate with a database 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 the maintenance requirements on the individual monitoring clients 1, 4, and 11 can be reduced. Optionally, monitoring client 1 can communicate with a patient treatment device, such as infusion pump 7, to receive information about the progress of the treatment (such as operating parameters) and provide operating instructions to the patient treatment device. In another embodiment, the monitoring client 1 also receives read information from the device,
Potentially, to instruct devices 14, 15, 16, 17 to take readings as desired by the provider or by an 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 embodiments of the present disclosure, equipment service 8 and / or drug adverse 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, turned off) by the caregiver using the user interface of the infusion pump 7 and / or the monitoring client 1 (also audible and / or audible).
Or a vibration alarm alone), while a hard alarm interrupts treatment until the cause is removed.

In still further embodiments of the present disclosure, the DERS system may include a first set of predetermined criteria defining soft limits and / or a second set of predetermined criteria defining hard limits. it can. The hard and soft limits define treatment limits, such as drug dose limits, based on size, weight, age, other patient parameters, or other criteria. The soft limit is used to prevent the therapy from starting until the setting is changed to meet a second set of predetermined criteria defining the hard limit. Despite being outside predetermined criteria, it can be overridden by a 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, the system 100 also includes a communication module 124A, each having an antenna of each of the 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 mounted in FIG.

Each communication module 124A-124K optionally communicates with one another over one or more wireless links, at the device dock 104, at the monitoring client dock 102, at the monitoring client 1, at the remote communicator 11, at 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 with the hub 802 (see FIG. 8) and / or otherwise with any other device having sufficient wireless communication capabilities. In some particular embodiments, the communication modules 124A-124K may be, for example, IEEE 802.14.4, Zigbee, XBee, Wibee, IEEE 802.
. 11 can operate, for example, 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.) may be, for example, (eg, monitoring client 1, 4, 11 and / or dock 1
Device discovery, handshake, as described herein, whether in a static, dynamic, or ad hoc topology (to accommodate the mobility of various medical devices associated with And / or may 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 three or more modules (eg, a communication module). For example, each module may have a specific function, for example, WiFi, and a user may select a plurality of modules each having a specific function and combine them. The group of modules can then be applied to a patient-care device, such as an infusion pump. Consider another embodiment. Each module can have a primary processor, a backup processor, and functional circuitry, all in operable communication with each other. The functional circuitry includes a wireless transceiver, a battery, an interface to a touch screen or display (the display can be attached to the housing), wire connections, Bluetooth, Bluetooth low energy, WiFi, 3G, 4G, coprocessor, (eg, Control system (for controlling the infusion pump), dosing using a fluid measurement circuit, and the like. The selected modules can be connected to each other, for example, in a daisy chain, and then connected to an infusion pump. The selected modules may be in operative communication with one another in this embodiment, for example, via a CAN bus, wired communication, wireless, and / or the like, to coordinate their operation and / or function.

Each of the modules can include a speaker and a microphone. If several modules are connected to each other, the modules can adjust their operation, so that while another module is using the microphone, to determine whether the speakers are working properly In turn, one module sends an audible signal to the speaker. Several modules can each use their speakers on different frequencies, so that any one of the modules can sense sound through its microphone while simultaneously testing 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 power a device coupled thereto. For example, the communication module 124A can be coupled to the infusion pump 7 to power it. Other structures and functions of the communication modules 124A-124K may be included depending on the purpose and function of the associated device. For example, in some embodiments, control of the infusion occurs at the infusion pump, and input regarding the desired delivery occurs at the infusion pump, and thus, in some embodiments of the present disclosure, the communication module 124A includes the infusion pump 7A. Implements a control algorithm, for example, a proportional-integral-derivative (PID) control loop. In such a case, the monitoring client 1 can, for example, communicate a fluid flow signal to the communication module 124A (e.g., via a wireless link), and then switch the infusion pump 7 to achieve the desired flow rate. A signal corresponding to the fluid flow signal is applied through electrical contacts coupled to a motor (not explicitly shown). In some embodiments, the infusion pump 7 provides one or more feedback signals to the communication module 124A from a flow meter provided in the infusion pump 7 so that the communication module 124A operates the infusion pump 7 (Eg, some aspects of operation of a PID control system, etc.). 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, a drip flow meter 148 is used to wirelessly communicate flow to a communication module 124A via a communication module 124K and an antenna 122K associated with the drip flow meter 148. can do.

As will be appreciated in light of the present disclosure, communication modules 124A-124K may be operatively coupled to various patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 148. For example, referring still to FIG. 1, the communication module 124B is operatively coupled to the syringe pump 126 and the communication module 124C is
8 is operatively coupled to 8. Additionally or alternatively, the communication module 124
E is operatively coupled to the ECG monitor 12, the communication module 124F is operatively coupled to the blood pressure monitor 15, and the communication module 124G is a pulse oximeter / CO.
₂ operatively coupled to the _two capnometers 16 and the communication module 124H
7, the communication module 124I is operably coupled to the patient's intravenous access 35, and the communication module 124K is operatively coupled to the infusion flow meter 148. Each respective communication module 124A-124K may include, 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
Is docked in the device dock 104, for example, to communicate with any device attached to the device dock 104, and to communicate with the electronics in the device dock 104, the electronics in the monitoring client dock 102, and And / or operatively coupled to device dock 104 via a bus or backplane for communicating with monitoring client 1. Optionally, the communication module 124D includes the device dock 10
Any device docked in 4, eg infusion pump 7, syringe pump 12
6. The pill dispenser 128 or the microinfusion pump 130 can be communicated and / or powered. Note that the functionality of communication module 124D can also be integrated into the circuitry of device dock 104 itself.

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

As previously discussed, in some embodiments, the communication modules 124 each provide sufficient power to the corresponding devices 7, 126, 128, and 130 (e.g., voltage converters, regulation circuits, Rectification and filtering circuits, buck circuits, boost circuits, buck-boost circuits, switch-mode power supplies, etc.). In some such cases, the power circuit may include a variety of different patient care devices 7, 14, 15, 16,.
17, 35, 126, 128, 148 can be configured to enable provision of various power supply features (eg, voltage levels, maximum load / current requirements, and A / C frequencies). is there. Any number of power delivery and management schemes are self-evident in light of the present disclosure.

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

The example system 100 can 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 to the device dock 104 and / or the monitoring client 1. Dongle 133 may provide a communication link or protocol for wireless devices that would not otherwise be available. For example, as new wireless protocols, technologies, standards, and technologies become available over time, Dongle 1
33 can be used to provide a bridge, router, or repeater between new communication protocols and to convert information conveyed in one protocol to another, thereby enabling the new protocol device to Nursing care devices 7, 14, 15, 17,
35, 126, 128, 130, the device dock 104, the communication module 124D, the monitoring client dock 102, the monitoring client 1, the hub 802 of FIG. 8, and / or other devices. The dongle 133 is in a format known or used to each other, such as the monitoring server 3 or the monitoring client 1, for example.
Patient care devices 7, 14, 15, 17, 35, 126, 128, 130, device dock 104, communication module 124D, monitoring client dock 102, monitoring client 1, monitoring client 1, hub 802 in FIG. 8, and / or other devices The data received from the new communication link may be retransmitted using wireless protocols, technologies, standards or technologies used by any one or more of the following. Dongle 133 may also provide a communication bridge to a mobile-based communication link, such as an EVDO or CDMA-based mobile system.

In some embodiments, the dongle 133 communicates patient care parameters from one or more patient care devices, eg, patient treatment parameters or patient status 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 wire-mounted connector, for example, an RS-232 connector, to communicate with one or more other patient-care devices, monitoring clients from legacy devices. 1, the hub 802 of FIG. 8, and / or the monitoring
Connectable to 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 also includes 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.
It can interact with and / or pair with it. The wearable system monitor 131 can be worn by the patient 2 or the 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 to determine if any failures, mistakes, fraud, data corruption, communication degradation, incomplete operation, slow operation, or other problems are present, the patient-care device 14, 15, 16, 1
7, 35, 126, 128, 130, monitoring client 1, monitoring client dock 1
02, the device dock 104, and / or the hub 802 of FIG.

Communication from wearable system monitor 131 indicates that the device being queried is functioning properly, functioning within predetermined operating parameters, and / or otherwise in a desired state or situation. One or more interrogation signals may be included to determine if. The system monitor 131 may alert the provider, initiate a shutdown procedure, and / or initiate other appropriate therapy operations directed to the malfunctioning device, the monitoring server 3, the monitoring client 1, or One or more devices, such as hub 802 in FIG. 8, may communicate the detected status or mistake. For example, the system monitor 131 may be a monitoring client 1, a monitoring server 3 via a WiFi router coupled to a network and / or the Internet, another monitoring client 4, a communication module 124, or another configured with the remote communicator 11. The transceiver of the communication module 124J in communication with the device can be used to signal an abnormal interrogation response or an alarm due to lack of interrogation and / or an alarm. The alarm and / or alarm can cause the device to sound or alert the alarm and / or alarm audibly. 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 a care provider, for example, to make the request visible to the user owning the device. The request is routed to the monitoring client 1 or the remote communicator 11 to indicate audibly.

The system monitor 131 may, for example, (1) predict a response to a query within a predetermined amount of time, (2) increment a counter in the device being queried, and, after being incremented, retrieve the value of the counter from the device. Request, (3) challenge response inquiry,
And / or (4) implement the function in various ways, including other system monitoring techniques or methods.

As previously described, in some embodiments, system monitor 131 predicts a response to a query within a predetermined amount of time after querying a patient-care device paired to 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 embodiment, infusion pump 7 receives a message labeled "System Monitor Inquiry" from system monitor 131 and processes the message using one or more processors therein. When the infusion pump 7 processes the message, the software routine therein executes code that sends a response message to the system monitor 131 again, for example, the response message is sent to the・
It may be a text string message of "monitor response". In this embodiment, the system monitor 131 can predict that a response message will be received 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 alert or a miss message, or cause the processor to provide the alarm or alert audibly or visually via the remote communicator 11).

As described above, in some embodiments, the system monitor 131 increments a counter in the device being queried and requests the value of the counter from the device after being incremented. For example, the system monitor 131 can send a request to a patient-care device, such as the infusion pump 7, by sending a message, such as an "increment counter", to the device. The processor of the device receives the "increment counter" message, reads the value from the memory location of the device, increments the value found at the memory location, and stores the new value in the same memory location by overwriting the previous value. . Thereafter, in this embodiment, the processor reads the new value from the memory location and sends the new value to the system monitor 131, for example, via a wireless transceiver on the device being queried.
In this embodiment, the system monitor 131 predicts a particular value from the device being queried (the predicted value can be stored in a memory of the system monitor, such as in a table, for example). ). For example, the system monitor 131 can store in its memory 48 values previously received from the device, and after requesting to update the values in the queried device, 49 Predict to receive a value.

Also, as described above, the 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, for example, using the encryption key, and send the message to the system monitor 131 again. System monitor 131 can anticipate unencrypted messages to return within a predetermined amount of time. In the present embodiment, if 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 (e.g., system
Monitor 131 can broadcast alerts or alarm messages and / or communicate them to monitoring client 1, monitoring server 3, hub 802 of FIG. 8, or remote communicator 11, and then alert or Display or audible alarm).

In an embodiment of the present disclosure, monitoring client 1 uses a hand-held or portable remote communicator 11 (which may be, for example, a smart phone, tablet computer, PDA, laptop, or other portable computing device). And health care
Has the ability to communicate and interact directly with the provider. This can be accomplished by wireless 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 in the monitoring client 1 so that the patient's healthcare provider can directly access the information without having to access the monitoring server 3. it can.

In some embodiments, optionally by incorporating appropriate safety and security checks, the connected infusion pump 7 or patient monitoring device 14-17,
Changes to the settings or flow parameters of 35, 126, 128, 130, 148 are (
Monitoring client 11 and monitoring client 1 of the provider (via wired or wireless communication)
The selected changes can also be communicated to the monitoring server 3, and optionally to other suitable locations, such as the nurse station 5 and / or pharmacy 6. In addition, any new instructions relating to the patient 2 are entered into the remote communicator 11 (eg a smart phone) of the instructing provider and the monitoring client 1
And then inform the caregiver (eg, nurse, nurse practitioner, physician, physician, or other healthcare professional) via the caregiver's own portable communicator 11. Can be. Additionally or alternatively, in some embodiments, a new indication is provided by the infusion pump 7 or the 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 points, 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 inactive, a new device can be assigned to the patient 2 and the patient's current information from the monitoring server 3 can be quickly re-added. Instructions, medications, progress notes, monitoring data, treatment data, patient treatment parameters, patient monitoring parameters, and / or operating parameters from the patient's attached device may also be used 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, the hub 8 of FIG. 8 for analysis to ensure compliance with ranges, thresholds, etc.
02 and / or the monitoring server 3.

In some embodiments, the monitoring server 3 includes several monitoring clients 1 in the facility 8.
, 4, 11 can be provided with a computer capable of communicating with and providing some element of control. The monitoring server 3 can provide the monitoring clients 1, 4, 11 with data extracted from several databases both 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 regarding the patient 2 and then provides a predetermined set of information (eg, patient's age, height, weight, Disease categories, current drugs and drug categories, drug allergies and hypersensitivity, etc.).
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, if the monitoring client 1 is assigned to the patient 2. (Eg, heart disease 23 or scheduling database 2
4) can be established. With a unique patient identifier, the monitoring server 3 can receive 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 against which new instructions can be analyzed. The instructions input into the monitoring client 1 are:
The compatibility with the patient-specific information obtained by the monitoring server 3 can be checked.
Optionally, for security redundancy, instructions entered remotely from the communicator 11 can be intercepted by the monitoring server 3 and can be checked as well. The monitoring server 3 also retrieves information from a drug database within the pharmacy 22 of the facility or outside 9 to determine if the new patient order may generate incompatibilities with the patient's existing drugs, for example. Obtainable. 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). The program can be programmed to access a public Internet site 25 to determine if a connection is available. 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 may monitor the patient's monitoring client 1 to relay or receive new instructions regarding the patient 2 (eg, drug instructions, etc.).
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 as well as 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" (e.g., Google's Nexus One ph, in particular) having a customized communication application on the monitoring client 1
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, convenient for both portable and 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 use a keyboard on the monitoring client 1 or direct input through a touch screen to enter or receive information about the patient 2.

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 that can connect or associate the patient 2. The monitoring client 1 may be, for example, a handheld device approximately the size of a wireless telephone or a tablet netbook. It is convenient to be able to have a touch screen interface for use by the patient's provider. Also, it is possible to provide output to a larger fixed display in the patient's room or at the nurse station 5 or other convenient location, either through a wired or wireless connection.
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 can upload information received from the patient monitoring devices 14-17 or from the provider input 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 via the monitoring server 3 with an Internet connection 25. Various external databases 9 are thus accessible, including various drug information databases and alert 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 to keep the content of the monitoring client 1 as up to date as possible. This can be accomplished, for example, by comparing safety and medication information associated with the patient as they become available, and prioritizing updates / downloads on the data transfer schedule. The monitoring clients 1, 4 can also communicate either directly or through the monitoring server 3 with the portable communicator 11 used by healthcare providers such as nurses, physicians, and pharmacists. In some cases, these devices may have a wired connection to the monitoring server 3 (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
ps, a private key mechanism, etc.). Alternatively, the hand-held remote communicator 11 (such as a smart phone or tablet netbook) communicates directly with the equipment monitoring client 1 via the cellular network.
2 can communicate and / or the equipment is connected to a WiFi network (eg, 2.
Private cell networks that can include 4 GHz to 2.4835 GHz unlicensed ISM bands).

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. Present via wireless transmission, all patient-specific monitoring clients 1, 4 can be linked to a central monitoring server 3. The server 3 can then act as a relay for communication with the other equipment servers 8, the web-based server 25, and the inner and outer portable communicators 11 owned by the health care provider. In some embodiments, the wireless network provides additional functionality that allows for communication with the monitoring server 3 regardless of where the patient 2 is within the facility.

One method of covering the entire facility with wireless coverage requires that the facility be licensed for a private cellular network. One or more micro-cell frequencies can be obtained or rented to provide a local communication network throughout the facility. Such an arrangement maintains communication as the patient and monitoring clients 1, 4 are moved from one location in the facility to another, and includes a monitoring server 3, various in-hospital and out-of-hospital databases 8, 25 and a monitoring client 11 with a user at a fixed station (eg, nurse station 5 and pharmacy 6 in some embodiments), or either inside or outside the hospital (eg, a portable smart phone, laptop) , Or tablet-type devices). In some embodiments,
This type of system provides additional security through the licensed mobile communication infrastructure. In addition, in some embodiments, the active wireless system can monitor the power used within an area and command an additional channel frequency for 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 over a wired connection.

Alternatively or additionally, the hospital may implement an Internet or intranet based communication system in which the 802.11 WiFi type protocol establishes a wireless connection between individual monitoring clients 1, 4 and monitoring server 3. Used for communication. 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 carriers. The fiber optic or cable network can then distribute the signal throughout the facility. Additionally or alternatively, the monitoring server 3 can use the private mobile telephone network described above. Such a system can typically provide secure communication, and can efficiently communicate large files, such as, for example, radiation images stored in the radiation database 21. . A home or office based user can connect to the hospital server through, for example, a VPN or another secure access using wired or fiber optic cables, or a DSL phone 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 capacity. This embodiment uses a licensed 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 embodiment, the upstream bandwidth and data rate requirements are relatively small compared to the downstream requirements. For lower priority upstream transmissions, the monitoring client 1 allows the data to be transmitted over a more distributed and cost-effective network such as, for example, a ZigBee network, a Bluetooth network, a mesh network.

As previously described, communication between various monitoring devices, such as patient care devices 14, 15, 16, 17, 35 and monitoring client 1, may be, for example, a ZigBee wireless mesh.
It can be achieved in a cost-effective way using a network and / or a Bluetooth network. Exemplary monitoring devices include, among others, ECG monitor 14,
Blood pressure monitor 15, pulse oximeter / capnometer 16, thermometer, and scale. The most common feature of these devices is that they perform a periodic reading of a single or a 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. High-level communication protocols can be used to ensure data fidelity and security, for example, TCP, UDP, etc. For example, using a symmetric encryption key, Twofish, Serpent, AES (Rijndael), Blowf
Communication between the monitoring client and the patient-care device, such as those generated for cryptographic algorithms such as ish, CAST5, RC4, 3DES, IDEA, etc., can be guaranteed. Additionally or alternatively, various data integrity techniques can be used, such as, for example, a 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 inexpensive, scalable, and mobile for 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. Using a similar network in providing a wireless link within the facility between the portable communicator 11 of the healthcare provider and its assigned patient through the patient monitoring clients 1,4. it can.

In many cases, the information communicated to the monitoring client 1 may include a single parameter value (eg, blood pressure, etc.) and a time stamp. The monitoring client 1 can be programmed to determine whether 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 allows the patient monitoring device (
For example, the BP monitor 15) can be queried and instructed to perform an unscheduled read. This may be useful, for example, if an abnormal read 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 can 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 indicates a blood pressure below a predetermined tolerance range, the monitoring client 1 can be programmed to instruct the infusion pump 7 to stop infusion and issue an emergency notification 12 (one (Or multiple) to the monitoring client 11 of the healthcare provider. In another embodiment,
If the infusion pump 7 is able to determine 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 monitoring client 1 or the processor in the infusion pump 7 can calculate the delivered volume from the infusion rate and the elapsed time of the infusion.)

When the estimated residual volume reaches a predetermined volume, 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 bags at a particular time, and that intravenous fluid is depleted before the nurse's scheduled return. Rather than alerting and / or sending its alarm, the monitoring client 1 will cause the intravenous bag to be empty upon arrival of the nurse 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 the infusion rate. In addition, a notification recommending the replenishment 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 surveillance client 1, whereby the percentage of borders that illuminate (eg, when the border is filled, begin to form a completely buried outer surface) is determined by the 4 shows the progress of the treatment being performed by the patient-care device. The border can be communicated from the infusion pump 7 to the monitoring client 1 in an image format (eg, JPEG, BMP, etc.) and / or as a percentage completed to the monitoring client 1, where the monitoring client 1 Generate

In some embodiments, a GPS and / or ranging module (eg, an ultrasonic ranging module that uses time-of-flight estimation) includes an infusion pump 7, a monitoring client 1, a caregiver,
And / or can be placed on the patient. The predetermined settings may be such 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, initiate therapy and / or Before configuring one of the pump 7 and / or the monitoring client 1, it may be necessary to be at a certain distance from each other.

In some embodiments, the patient-care device 7, 170, 126, 128, 130, 1,
4, 15, 16, 17, 124, or 148, dock 102 or 104, monitoring client 1, hub 802 in FIG. 8 (eg, a caregiver may provide a solution to eliminate the cause of the alarm without disturbing the patient. Soft alarms, hard alarms, and / or critical alarms without warning on the device and / or on the monitoring client 1 until after a predetermined amount of time has elapsed (so that the alarm can be found). No alarm 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 is provided with a clip so that a venous tube can be clipped thereto.

In some embodiments, the infusion pump 7 has a condition that indicates one or more of passing a safety check, that the pump is running, that there is an obstruction, and / or that the pump is disconnected. Includes LED light. The user can use the monitoring client 1 to read the barcode on the intravenous bag 170 (e.g., using the camera 144 or camera 136, and / or the scanner 120), and then use 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, as shown in FIG. 1, or as described herein, is numbered or unnumbered. The computing device is optional. For example, in some embodiments, the monitoring client 1 is optional, the monitoring server 3 is optional, the equipment service 8 is optional, and each service 19, 20, 21, 22, 23, 24 is Optional, cloud server 25 is optional, other monitoring clients 4 are each optional, online drug database 9 is optional, drug adverse event network is optional, patient personal EHR19 'is optional, and / or
Alternatively, the treatment result database 10 is optional. Additionally or alternatively,
In some embodiments, each patient-care device 7, 14, 15, 16, 17, 35, 12
6, 128, 130, 148 are optional. Similarly, the system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply are each optional in some embodiments of the present disclosure.

In addition, in some embodiments, some items, components, devices, patients, as shown in FIG. 1 or as described herein, numbered or unnumbered Although the care device, dock, and computing device are shown as the only item, component, device, patient care device, dock, or computing device, a number of items, components, devices, patient care devices, docks, and computing devices may be provided. Conceivable. For example, while a single infusion pump 7 is shown in FIG. 1, 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 may be used.

Additionally 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 thereof of particular patient-care devices may be used. For example,
In some embodiments, only the infusion pump 7 of the patient-care device is used,
In this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128
, 130, 148, may not be present or available for system use, may be powered down, or may not be part of the system 100 of FIG. Additionally or alternatively, in some specific embodiments, only the patient-care device used can be docked to the device dock 104. For example, in this particular embodiment, infusion pump 7 is the only device docked in device dock 102,
Only the device dock 102 receives one device, for example the infusion pump 7. Additionally, or alternatively, in certain embodiments, the patient-care device 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 is dockable. Can operate without and / or not be dockable and can operate as a stand-alone patient care device.

In some embodiments, the 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 secure data classes, for example, via an API.

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

FIG. 2 illustrates a monitoring client, eg, the monitoring client 1 of FIG. 1 and one or more of the patient care devices, eg, the patient care devices 7, 14, 15 of FIG. 1, in accordance with an embodiment of the present disclosure.
, 16, 17, 35, 126, 128, 130, 148 show a flowchart diagram illustrating a method 150 for maintaining communication between one or more. The method 150 of the present example includes operations 152-169. The monitoring client 1 may 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 the pairing and / or communication with the designated patient care device is available at predetermined intervals, and to pair or to the designated patient care device. If communication is not available for a predetermined time, the monitoring client 1 can sound an alarm or an 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.

Act 154 indicates that the monitoring client dock uses the cable to monitor the monitoring client dock.
Determine if it is available 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, for example, through 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.

Act 158 is a process in which the device dock communicates with the monitoring client and device over a wireless link.
Determine if 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 communicating endpoints.
A 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 another link (not explicitly shown). Otherwise, if decision operation 168 determines that the handshake of operation 166 was successful, then 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 can use other schedules, can use broadcast, anycast, multicast or unicast, and uses a routing algorithm Can be 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, certain alternative communication Static routing on the path may be used and / or an adaptive network may be used. For example,
In some embodiments of the present disclosure, 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, the weight can be determined in any known way, the bandwidth, signal quality, bits Including 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 illustrates a block diagram of an electronic patient care system 300 having two docks 102, 104 for wireless communication therebetween, according to another embodiment of the present disclosure. System 300 is similar to system 100 of FIG. 1, but communication between monitoring client dock 102 and device dock 104 is over 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 not present or operating, and additionally or alternatively, the system 300 of FIG. Can have docks 102 and 104 that are not connectable together using cables.

Optionally, providing instructions or requests to the patient-care device 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148 to transmit the bolus volume, infusion flow, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile, for example, to infusion pump 7, syringe Monitoring client 1, other monitoring clients 4, and / or remote communicator 11 can be used to send to pump 126 and / or microinfusion pump 130. In some embodiments, instructions or requests, such as, for example, a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills, may be transmitted to the pill dispenser 128.
One or more of the monitoring clients 1, 4, 11 may be used to send to the client. The maximum pill distribution criterion is the maximum amount of a drug that can be delivered within a given time interval, e.g., when a particular drug is taken on demand (i.e., as needed), If the drug is not safe, the maximum pill distribution criteria can prevent the drug from being taken by the patient at an unsafe level, e.g., in a predetermined amount during a predetermined time interval. .

In some embodiments, remote communicator 11 is used to provide remote communicator 1.
A two-way audio / visual communication (e.g., a video call) between the client 1 and the monitoring client 1 can be initiated. Additionally 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 raised or transmitted, determine whether a treatment or condition is safe for the patient, system 30,
0 monitors the data to determine if it is operating properly or at predetermined boundaries and / or display the data on the display of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. A reply can be sent to the client 1, the other monitoring client 4, and / or the remote communicator 11. For example, optionally, the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 may include an upstream pressure, an upstream pressure change, a downstream pressure for the patient 2, a downstream pressure for the patient 2. Changes, the presence or absence of air in the infusion line, the actual bolus volume delivered, the actual infusion flow rate, the actual total fluid delivered, the actual start time of drug delivery, the actual stop time of drug delivery, or the actual The delivery flow profile can be communicated (if applicable) to one or more of monitoring client 1, other monitoring clients 4, and / or 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 whether a maximum pill dispensing threshold has been exceeded. Such as data,
Monitoring client 1, other monitoring clients 4, and / or remote communicator 11
You 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 generate an alarm and / or an alarm. For example, one or more of the monitoring clients 1, 4, 11 is one indication of excessive coagulation, penetration, occlusion or bending of the tubing to the patient, or occlusion by other materials in the intravenous bag 170. An increase in pressure downstream of the infusion pump 7, the syringe pump 126 and / or the microinfusion pump 130 can be used. In response to a sharp increase in downstream pressure, monitoring clients 1, 4, 11
One or more can visually or audibly alert or alert the user. Additionally or alternatively, the sharp drop in downstream pressure on the patient 2 is an indication that the tubing has disconnected from the needle and / or that the needle is now disconnected from the patient, and, accordingly, One or more of the monitoring clients 1, 4, 11 can visually or audibly alert or alert the user. Optionally, one or more of the monitoring clients 1, 4, 11 may respond to a surge in downstream pressure on the patient 2 in response to an increase and / or a decrease.
An indication can be sent to one or more of the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 to stop delivery of fluid.

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

Additionally, in some embodiments, some items, components, devices, patients, numbered or unnumbered, as shown in FIG. 3 or as described herein Although the care devices, docks, and computing devices are shown as the only items, components, devices, patient care devices, docks, or computing devices, numerous items, components, devices, patient care devices, docks, and computing devices may be provided. Conceivable. For example, while a single infusion pump 7 is shown in FIG. 3, 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 may be used.

Additionally 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 thereof of particular patient-care devices may be used. For example,
In some embodiments, only the infusion pump 7 of the patient-care device is used,
In this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128
, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 300 of FIG. Additionally or alternatively, in some embodiments, only the patient-care device used can be docked to the device dock 104. For example, in certain embodiments, infusion pump 7 is the only device docked in device dock 102, and only device dock 102 receives one device, for example, infusion pump 7. Additionally, or alternatively, in some specific embodiments, the patient-care device 7, 14
, 15, 16, 17, 35, 126, 128, 130, 148 are dockable.
It can operate without docking and / or can be dockable and operate as a stand-alone patient-care device.

Although in FIG. 3 the device dock 104 is shown as capable of receiving a number of patient-care devices, in other embodiments, the device dock 104 includes one patient-care device, multiple patient-care devices, A patient care device, or any number of patient care devices, may be received. Also, the dock section may not be used, for example, an empty section 170 is shown in the device dock 104 as shown in FIG. In addition, while the monitoring client dock 102 is shown as capable of receiving one monitoring client 1, in other embodiments, the monitoring client dock 102
It may receive two monitoring clients 1, three or more monitoring clients 1, or any number of monitoring clients 1.

FIG. 4 illustrates a monitoring client, eg, monitoring client 1, and one or more of the devices, eg, patient care devices 7, 14, 15, 16, 17, FIG.
FIG. 4 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 in 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, method 202 proceeds to operation 212;
Method 202 proceeds to operation 210.

Act 210 is a process in which the device dock communicates with the monitoring client over a wireless link with the device client.
Determine if 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 operation 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 via 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 an alternative embodiment, no handshake is attempted, eg, some communication protocols do not utilize handshaking. A 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 the communication link has been established, method 202 may use available communication link (s) to perform operation 22.
2 communicate data between the monitoring client and the device. If the determining operation 220 determines that the handshake was not successful, the method 202 determines in operation 218 that communication with the device is not available, or the method 202 determines whether the unverified communication link (explicitly (Not shown in FIG. 2) between the monitoring clients.

Method 202 is an exemplary embodiment of the present disclosure that describes a method of maintaining communication between a monitoring client and one or more patient care devices. In some embodiments, the method 202 includes a schedule of the communication link, but can use other schedules, can use broadcast, anycast, multicast or unicast, and uses a routing algorithm Can use a distance vector routing protocol, can use a link state routing protocol, can use an optimized link state routing protocol, can use a path vector
Protocols may be used, static routing on predetermined alternative communication paths may be used, and / or adaptive networks may be used. For example, in some embodiments of the present disclosure, weight can be assigned to each communication path and Dijkstr
a) can communicate between the monitoring client 1 and one or more patient-care devices using the algorithm of a, determine weight in any known manner, and determine bandwidth, signal quality, bits Including as a function of error rate may be linear with available data throughput or latency, and / or the like.

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

Optionally, providing instructions or requests to the patient-care device 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148 to transmit the bolus volume, infusion flow, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile, for example, to infusion pump 7, syringe Monitoring client 1, other monitoring clients 4, and / or remote communicator 11 can be used to send to pump 126 and / or microinfusion pump 130. In some embodiments, instructions or requests, such as, for example, a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills, may be transmitted to the pill dispenser 128.
One or more of the monitoring clients 1, 4, 11 may be used to send to the client. The maximum pill distribution criterion is the maximum amount of a drug that can be delivered within a given time interval, e.g., when a particular drug is taken on demand (i.e., as needed), If the drug is not safe, the maximum pill distribution criteria can prevent the drug from being taken by the patient at an unsafe level, e.g., 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 raised or transmitted, determine whether a treatment or condition is safe for the patient, system 50.
0 monitors the data to determine if it is operating properly or at predetermined boundaries and / or display the data on the display of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. A reply can be sent to the client 1, the other monitoring client 4, and / or the remote communicator 11. For example, optionally, the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 may include an upstream pressure, an upstream pressure change, a downstream pressure for the patient 2, a downstream pressure for the patient 2. Changes, the presence or absence of air in the infusion line, the actual bolus volume delivered, the actual infusion flow rate, the actual total fluid delivered, the actual start time of drug delivery, the actual stop time of drug delivery, or the actual The delivery flow profile can be communicated (if applicable) to one or more of monitoring client 1, other monitoring clients 4, and / or 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 whether a maximum pill dispensing threshold has been exceeded. Such as data,
Monitoring client 1, other monitoring clients 4, and / or remote communicator 11
You 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 generate an alarm and / or an alarm. For example, one or more of the monitoring clients 1, 4, 11 is one indication of excessive coagulation, penetration, occlusion or bending of the tubing to the patient, or occlusion by other materials in the intravenous bag 170. An increase in pressure downstream of the infusion pump 7, the syringe pump 126 and / or the microinfusion pump 130 can be used. In response to a sharp increase in downstream pressure, monitoring clients 1, 4, 11
One or more can visually or audibly alert or alert the user. Additionally or alternatively, the sharp drop in downstream pressure on the patient 2 is an indication that the tubing has disconnected from the needle and / or that the needle is now disconnected from the patient, and, accordingly, One or more of the monitoring clients 1, 4, 11 can visually or audibly alert or alert the user. One or more of the monitoring clients 1, 4, 11 optionally may respond to a sharp rise and / or drop in downstream pressure on the patient 2,
An indication can be sent to one or more of the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 to stop delivery of fluid.

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

Additionally, in some embodiments, some items, components, devices, patients, as shown in FIG. 5 or as described herein, numbered or unnumbered Although the care device, dock, and computing device are shown as the only item, component, device, patient care device, dock, or computing device, a number of items, components, devices, patient care devices, docks, and computing devices may be provided. Conceivable. For example, while a single infusion pump 7 is shown in FIG. 5, 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.

Additionally 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 thereof of particular patient-care devices may be used. For example,
In some embodiments, only the infusion pump 7 of the patient-care device is used,
In this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128
, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 500 of FIG. Additionally or alternatively, in some specific embodiments, only the patient-care device used is dockable in dock 502. For example, in certain embodiments, infusion pump 7 is the only device docked in device dock 102, and only device dock 102 receives one device, for example, infusion pump 7. Additionally or alternatively, or in some specific embodiments, the patient-care device 7, 14, 1,
The 5, 16, 17, 35, 126, 128, 130, 148 can be dockable, can operate undocked, and / or can be non-docking and operate as a stand-alone patient care device.

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

FIG. 6 illustrates a monitoring client, eg, 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, 17, 35, 126, 128, 130, 148 are flowchart diagrams 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, otherwise, method 304 proceeds to operation 310.
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 via 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 used, for example, some protocols do not use handshaking. Decision operation 3
18 determines whether the handshake was successful, and if so, the method 304 proceeds to operation 320 to communicate the data using the available communication link (s). If decision operation 318 determines that the handshake was not successful in operation 314, operation 316 determines that communication with the device is not available. In another embodiment, if decision operation 318 determines that the handshake was not successful in operation 314, 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 of 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 may use other schedules, use broadcast, anycast, multicast or unicast, and use a routing algorithm. Can use a distance vector routing protocol, can use a link state routing protocol, can use an optimized link state routing protocol, can use a path vector
Protocols may be used, static routing on predetermined alternative communication paths may be used, and / or adaptive networks may be used. For example, in some embodiments of the present disclosure, weight can be assigned to each communication path and Dijkstr
a) can communicate between the monitoring client 1 and one or more patient-care devices using the algorithm of a, determine weight in any known manner, and determine bandwidth, signal quality, bits Including as a function of error rate may be linear with available data throughput or latency, and / or the like.

Referring now to FIG. 7, a patient care device 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 therein is shown. Additionally, in some embodiments, communication module 124D and dongle 133 can all be docked to dock 702. The patient care system 700 of FIG. 7 is similar to the patient care system 100 of FIG. 1 except that the patient care system 700 includes an integrated dock 702. In some embodiments, the monitoring client 1 communicates with the patient-care device when docked via the dock, but the monitoring client 1 communicates with the patient-care device, such as the patient-care device 7, 14, 15, 16,. 17, 35, 126, 128, 13
0 and 148, the monitoring client 1 can communicate wirelessly, for example, using the antenna 112 of the monitoring client 1.

Optionally, providing instructions or requests to the patient-care device 7, 14, 15, 16, 17
, 35, 126, 128, 130, 148 to transmit the bolus volume, infusion flow, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile, for example, to infusion pump 7, syringe Monitoring client 1, other monitoring clients 4, and / or remote communicator 11 can be used to send to pump 126 and / or microinfusion pump 130. In some embodiments, instructions or requests, such as, for example, a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing pills, may be transmitted to the pill dispenser 128.
One or more of the monitoring clients 1, 4, 11 may be used to send to the client. The maximum pill distribution criterion is the maximum amount of a drug that can be delivered within a given time interval, e.g., when a particular drug is taken on demand (i.e., as needed), If the drug is not safe, the maximum pill distribution criteria can prevent the drug from being taken by the patient at an unsafe level, e.g., 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 raised or transmitted, determine whether a treatment or condition is safe for the patient,
0 monitors the data to determine if it is operating properly or at predetermined boundaries and / or display the data on the display of the monitoring client 1, other monitoring clients 4 and / or the remote communicator 11. A reply can be sent to the client 1, the other monitoring client 4, and / or the remote communicator 11. For example, optionally, the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 may include an upstream pressure, an upstream pressure change, a downstream pressure for the patient 2, a downstream pressure for the patient 2. Changes, the presence or absence of air in the infusion line, the actual bolus volume delivered, the actual infusion flow rate, the actual total fluid delivered, the actual start time of drug delivery, the actual stop time of drug delivery, or the actual The delivery flow profile can be communicated (if applicable) to one or more of monitoring client 1, other monitoring clients 4, and / or 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 whether a maximum pill dispensing threshold has been exceeded. Such as data,
Monitoring client 1, other monitoring clients 4, and / or remote communicator 11
You 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 generate an alarm and / or an alarm. For example, one or more of the monitoring clients 1, 4, 11 is one indication of excessive coagulation, penetration, occlusion or bending of the tubing to the patient, or occlusion by other materials in the intravenous bag 170. An increase in pressure downstream of the infusion pump 7, the syringe pump 126 and / or the microinfusion pump 130 can be used. In response to a sharp increase in downstream pressure, monitoring clients 1, 4, 11
One or more can visually or audibly alert or alert the user. Additionally or alternatively, the sharp drop in downstream pressure on the patient 2 is an indication that the tubing has disconnected from the needle and / or that the needle is now disconnected from the patient, and, accordingly, One or more of the monitoring clients 1, 4, 11 can visually or audibly alert or alert the user. Optionally, one or more of the monitoring clients 1, 4, 11 may respond to a surge in downstream pressure on the patient 2 in response to an increase and / or a decrease.
An indication can be sent to one or more of the infusion pump 7, the syringe pump 126, and / or the microinfusion pump 130 to stop delivery of fluid.

In some embodiments, each item, component, device, patient-care device, dock, as shown or described herein 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 equipment service 8 is optional, and each service 19, 20, 21, 22, 23, 24 is Optional, cloud server 25 is optional, other monitoring clients 4 are each optional, online drug database 9 is optional, drug adverse event network is optional, patient personal EHR19 'is optional, and / or
Alternatively, the treatment result database 10 is optional. Additionally or alternatively,
In some embodiments, each patient-care device 7, 14, 15, 16, 17, 35, 12
6, 128, 130, 148 are optional. Similarly, the system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 134, and / or AC power supply are each optional in some embodiments of the present disclosure.

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

Additionally 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 thereof of particular patient-care devices may be used. For example,
In some embodiments, only the infusion pump 7 of the patient-care device is used,
In this particular embodiment, the other patient care devices 14, 15, 16, 17, 126, 128
, 130, 148 may be disabled, not present or available for system use, powered down, or not part of the system 700 of FIG. Additionally or alternatively, in some specific embodiments, only the patient-care device used is dockable in the integrated dock 702. For example, in one particular embodiment, infusion pump 7 is the only device docked in integrated dock 702 and integrated dock 7
Only 02 receives one device, for example infusion pump 7. In addition, as an alternative,
Or, optionally, in some particular embodiments, the patient-care device 7, 14, 15
, 16, 17, 35, 126, 128, 130, 148 can be dockable, can operate undocked, and / or can be non-docking and operate as a stand-alone patient care device.

In FIG. 7, the integrated dock 702 is shown as capable of receiving several patient-care devices, but in other embodiments, the integrated dock 702 includes one patient-care device, multiple patient-care devices, A patient care device, or any number of patient care devices, may 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, while the integrated dock 702 is shown as capable of receiving one integrated monitoring client 1, in other embodiments, the integrated dock 702 includes two integrated monitoring clients 1.
, Three or more integrated monitoring clients 1, or any number of integrated monitoring clients 1.

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

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

In some embodiments, hub 802 includes an application programming interface (API) for displaying GUIs, windows, data, etc. on monitoring client 1 and / or remote communicator 11. APIs can include secure data classes. In still additional embodiments, docks 102, 804,
And / or 806, the G on the monitoring client 1 or the remote communicator 11
Includes an API to display UI, windows, data, etc. In yet additional embodiments, the dock 102, 804, or 806, or hub 802, may
An API is included for displaying 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 therewith,
Identifying the type of patient care device associated therewith and loading configuration data based on the type of device (device plugged or docked into hub 802 and / or docks 102, 804, and / or 806) Can be.

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

The user interface described herein may utilize a request behavior framework.

Optionally, in some particular embodiments, the hub 802 includes all of the safety critical circuits and software for communicating with the monitoring client 1. For example, in this particular embodiment, the hub 802 receives the treatment parameters from the monitoring client 1 and the hub 802 determines that the treatment parameters are independent of any safety checks performed elsewhere on the monitoring client 1, for example. 2 is safe for you. In yet additional specific embodiments, the system 800 is optionally fully fault-tolerant of the monitoring client 1, for example, where the independent security checks performed therein are based on predetermined criteria, such as an infusion pump 7. If the specified safety range for drug delivery is not met,
There is a possibility that instructions, requests, or parameters from the monitoring client 1 may be ignored.

Optionally, in a still further specific embodiment, a barcode attached to the intravenous bag 170 can be scanned by the scanner 120 to download a predetermined prescription (e.g., from the patient's personal EHR 19 '). And / or infusion pump 830 includes a prescription that is uploaded to hub 802 when docked in dock 804. Thereafter, in this particular embodiment, and optionally, the hub 802
Initiates infusion of the intravenous bag 170 into the patient 2 and monitors the progress of the treatment to ensure patient 2 safety. Additionally or alternatively, in this particular embodiment, the caregiver can interact with the system 800 via the hub 802 only, as shown in FIG. Optionally, in some embodiments, hub 802 uploads treatment, condition, or patient information to monitoring client 1. For example, the hub 802 may provide treatment information received from the infusion pump 830 or scan on the intravenous bag 170 for display to the user, such as for confirmation by the user, for storage in the monitoring client 1, or the like. The treatment information received from the patient's personal EHR 19 ′ corresponding to the bar code thus set 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 includes one, two,
Receive one or more or multiple patient care devices. Device dock 806 receives pill dispenser 814. In some embodiments, the device dock 806 receives one, two or more, or multiple patient care devices, such as a 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. The hub 802 and the docks 804 and 806 each have a U
They can communicate with each other using SB cables, using Ethernet cables, and / or via wireless links. Optionally, hub 802 may include additional accessories such as display 822, camera 824, microphone 826, scanner 120, 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, providing instructions or requests to the patient-care device 14, 15, 16, 17, 3
5, 830, 810, 812, 814, 830, 148, for example, the bolus volume, infusion flow, total delivery fluid, drug delivery start time, drug delivery stop time, or delivery flow profile. Monitoring client 1, other monitoring clients 4, and / or remote communicator 11 may be used to send to one or more of 830, 810, 812. In some embodiments, the monitoring is performed to send instructions or requests to the pill dispenser 814, such as, for example, a pill dispensing instruction for dispensing the pill, a pill type, a pill dispensing schedule, and / or a 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 a drug that can be delivered within a given time interval, e.g., when a particular drug is taken on demand (i.e., as needed), If the drug is not safe, the maximum pill distribution criteria can prevent the drug from being taken by the patient at an unsafe level, e.g., 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 raised or transmitted, determine whether a treatment or condition is safe for the patient,
Determine whether system 800 is operating properly or at predetermined boundaries, and / or monitoring client 1, other monitoring clients 4, and / or remote communicator 1.
The data can be sent back to the monitoring client 1, the other monitoring client 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 include an upstream pressure, a change in upstream pressure, a downstream pressure for patient 2, a change in downstream pressure for patient 2, Monitor the presence or absence of air, the actual bolus volume delivered, the actual infusion flow rate, the actual total fluid delivered, the actual start time for drug delivery, the actual stop time for drug delivery, or the actual delivery flow profile Client 1, other monitoring clients 4, and / or one or more of remote communicators 11 can be communicated (if applicable). In another embodiment, the pill dispenser 814 optionally optionally determines whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule at the time of dispensing, or the maximum pill dispensing criteria has been exceeded. Such data can be returned to the monitoring client 1, the other monitoring client 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 to generate an alarm and / or an alarm. For example, monitoring clients 1, 4, 1
Infusion pump 830, one or more of which is one indication of excessive coagulation, penetration, occlusion or bending of the tubing to the patient, or occlusion by other materials in intravenous bag 170.
One or more downstream pressure increases at 810, 812 may be used. In response to a sudden increase in downstream pressure, one or more of the monitoring clients 1, 4, 11 can visually or audibly alert or alert the user. Additionally or alternatively, a sharp drop in downstream pressure on the patient 2 is an indication that the tubing has been disconnected from the needle and / or that the needle is now disconnected from the patient, and accordingly monitored. Clients 1, 4,
One or more of the eleven can visually or audibly alert or alert the user. One or more of the monitoring clients 1, 4, 11 is optionally provided with an infusion pump 830, 810, An indication may be sent to one or more of 812.

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

In addition, in some embodiments, some items, components, devices, patients, numbered or unnumbered, as shown in FIG. 8 or described herein Although the care device, dock, and computing device are shown as the only items, components, devices, patient care devices, docks, or computing devices, numerous items, components, devices, patient care devices, docks, and computing devices may be provided. Conceivable. For example, while 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 number of pill dispensers 814 can be used. Additionally or alternatively, in some embodiments, multiple docks 804 or 806 and / or multiple monitoring client docks 102 may be used.

Additionally or alternatively, while particular patient care devices 830, 810, 812 are shown, other combinations, subsets, many, or combinations thereof, of particular patient care devices may be used. . For example, in some embodiments, only the infusion pump 830 of the patient care devices is used, and in this particular example, the system is used for disabling other patient care devices 810, 812, 814. May not be present or available, may be powered down, or may not be part of the system 800 of FIG.
Additionally or alternatively, in some specific embodiments, only the patient-care device used is dockable to dock 804 or 806. For example, in one particular embodiment, infusion pump 830 is the only device docked in dock 804, and only dock 804 receives one device, eg, infusion pump 830.

Although the dock 804 is shown in FIG. 8 as capable of receiving a number of patient care devices, in other embodiments, the device dock 804 includes a single patient care device, multiple patient care devices. A device, or any number of patient-care devices, may be received. Also, the dock section may not be used (not shown in FIG. 8).
In addition, while monitoring client dock 102 is shown as capable of receiving one monitoring client 1, in other embodiments, monitoring client dock 1
02 may receive two monitoring clients 1, three or more monitoring clients 1, or any number of monitoring clients 1. Additionally or alternatively or optionally, in some particular embodiments, the patient-care device 14, 15, 16, 1
7, 35, 830, 810, 812, 814 can be dockable, can operate undocked, and / or can be non-docking and operate as a stand-alone patient care device.

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

In embodiments of the present disclosure, equipment service 8 and / or drug adverse 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 causes the user interface of the infusion pump 830, the user interface of the hub 802 and / or the user interface of the monitoring client 1 to be interrupted while the hard alarm interrupts therapy until the cause of the hard alarm is removed. It can be used and disabled (eg, turned off) by a caregiver (and may be only an audible and / or vibration alarm).

In still further embodiments of the present disclosure, the DERS system may include a first set of predetermined criteria defining soft limits and / or a second set of predetermined criteria defining hard limits. it can. Hard and soft limits define treatment limits, such as drug dosage, based on size, 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 defining the hard limit.
The user interface of the infusion pump 830, the user interface of the monitoring client 1, and / or the user interface of the hub 802 for initiating treatment, even though the treatment is outside the first set of predetermined criteria. 808 can be used to override by a caregiver.

In some embodiments, the 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 include secure data classes, for example, via an API. Can be.

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.
A block diagram of an electronic patient care system 900 having a pump 906 and another stackable patient care device 908 is shown. Stackable devices 902-908
Communication may be performed using a backplane and / or a bus (in some embodiments, stackable devices 902-908 communicate via a communication module).

Optionally, providing instructions or requests to the patient-care device 14, 15, 16, 17, 3
5, 128, 904, 906, 908, 148, for example, bolus volume, infusion flow, total delivery fluid, drug delivery start time, drug delivery stop time, or infusion stackable delivery flow profile Pump 904, stackable syringe pump 906
The monitoring client 902, the other monitoring client 4, and / or the remote communicator 11 can be used to transmit to and / or other stackable patient care devices 908. In some embodiments, for example, pill dispensing instructions for dispensing pills, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria,
In order to send instructions or requests to the pill dispenser 128, the monitoring client 9
02, 4, 11 can be used. The maximum pill distribution criterion is the maximum amount of a drug that can be delivered within a given time interval, e.g., when a particular drug is taken on demand (i.e., as needed), If the drug is not safe, the maximum pill distribution criteria can prevent the drug from being taken by the patient at an unsafe level, e.g., in a predetermined amount during a predetermined time interval. .

Optionally, patient care devices 14, 15, 16, 17, 35, 128, 904, 9
06, 908, 148 may also determine whether an alarm or alert should be raised or transmitted, determine whether a treatment or condition is safe for the patient, and operate the system 900 appropriately or at predetermined boundaries. Data to monitor and / or display data on a display of monitoring client 902, other monitoring client 4 and / or remote communicator 11, and / or other monitoring client 4. Alternatively, a reply can be sent to the remote communicator 11. For example, optionally, a stackable infusion pump 904, a stackable syringe pump 906, and / or other stackable patient-care device 908 may include an upstream pressure, a change in upstream pressure, a downstream for patient 2. Pressure, change in downstream pressure for patient 2, presence or absence of air in the infusion line, actual bolus volume delivered, actual infusion flow rate, actual total fluid delivered, actual start time of drug delivery, drug delivery May be communicated (if applicable) to one or more of monitoring client 902, other monitoring clients 4, and / or remote communicator 11. In another embodiment, the pill dispenser 128 may optionally include, for example, whether the actual pill dispensed, the actual pill type dispensed, the actual pill dispensing schedule when dispensed, or whether the maximum pill dispensing threshold has been exceeded. Such data can be returned 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 generate an alarm and / or an alarm. For example, one or more of the monitoring clients 902, 4, 11 is one indication of excessive coagulation, penetration, occlusion or bending of the 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 a sudden increase in downstream pressure, the monitoring clients 902, 4,
One or more of the eleven can visually or audibly alert or alert the user. Additionally or alternatively, a sharp drop in downstream pressure on the patient 2 is an indication that the tubing has been disconnected from the needle and / or that the needle is now disconnected from the patient, and accordingly monitored. One or more of the clients 902, 4, 11 can visually or audibly alert or alert the user. One or more of the monitoring clients 902, 4, 11 are optionally stackable infusion pumps 904 to stop delivery of fluid in response to a sudden rise and / or fall in downstream pressure to the patient 2. Instructions may be sent to one or more of the stackable syringe pumps 906.

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

Daisy chains can be created, for example, through electrical conductors in each of the stackable monitoring clients 902, stackable patient care devices 908, stackable infusion pumps 904, and stackable syringe pumps 906, thereby. Continuous electrical contact is maintained between each of these devices.

Additionally or alternatively, the stackable devices 902, 908, 904,
906 can optionally maintain wireless communication with each other. For example, the stackable monitoring client 902 is electrically unresponsive due to an internal short circuit in one of the stackable devices 902, 908, 904, 906 where the daisy chained conductors are stackable. And the stackable monitoring client 902 checks each stackable device 9 to determine which device has failed.
08,904,906. After making the determination, the stackable monitoring client 902 may stack the devices 902, 908, 904, 906 to electrically disengage the failed device from the daisy-chained conductors.
Wireless communication with an insulated disconnection circuit within the failed device. Additionally or alternatively, one or more of the stackable devices 902, 908, 904, 906 is such that one of the stackable devices 902, 908, 904, 906 is faulty and / or stackable. Alerting, sending an alert, and / or displaying a message that one of the devices 902, 908, 904, 906 communicates wirelessly rather than via a daisy-chained wired communication link. 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, below or above the daisy chain. Information can be relayed or retransmitted to other devices. For example, a stackable infusion pump 9
04 buffers the data in the internal memory and stacks the patient care device 9
08 communicates information from stackable patient-care device 908 indicating that it is ready to receive additional data, thereby allowing all data received from stackable syringe pump 906 to be communicated. Can communicate. In some embodiments, each item, component, device, patient-care device, dock, as shown in FIG. 8, or as described herein, is numbered or unnumbered. The computing device is optional. For example, in some embodiments, the monitoring client 1 is optional, the monitoring server 3 is optional, the equipment service 8 is optional, and each service 19, 20, 21, 22, 23, 24 is Optional, the cloud server 25 is optional, the other monitoring clients 4 are each optional,
The online drug database 9 is optional, the drug adverse event network is optional, the patient's personal EHR 19 'is optional, and / or the treatment result database 10 is optional. Additionally or alternatively, in some embodiments, each patient-care device 830, 810, 812 is optional. Similarly, the system monitor 131, wristband 118, RFID 116, barcode 114, scanner 120, display 808, and / or AC power supply are each optional in some embodiments of the present disclosure.

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

Additionally or alternatively, while particular patient care devices 904, 906, 908 are shown, other combinations, subsets, many, or combinations thereof, of particular patient care devices may be used. . For example, in some embodiments, only the stackable infusion pump 904 of the patient-care devices is used, and in this particular example, the system is used for disabling other patient devices 906, 908. May not be present or available, may be powered down, or may not be part of the system 900 of FIG. Additionally or alternatively, in some particular embodiments, only the patient-care devices used are stacked. For example, in one particular embodiment, the infusion pump 904 is the only device stacked. Additionally or alternatively, unstacked patient-care devices, such as patient-care devices 904, 906, and / or 908, can continue to operate when operating as a stand-alone device. Additionally, or alternatively, in some particular embodiments, the patient-care device 14, 15, 16, 17, 35, 904, 906, 908, 128, 148 is dockable. Can operate without and / or not be dockable and can operate as a stand-alone patient care device.

In FIG. 9, the stack is shown as capable of stacking several patient-care devices, but in other embodiments, the stack may be a single patient-care device, multiple patient-care devices, or any optional device. Of patient care devices can be received. In addition, while the stack is shown as capable of receiving one monitoring client 902, in other embodiments, two stackable monitoring clients 902, three or more stackable monitoring clients 902 902, or any number of stackable monitoring clients 902 are stacked in the system 900.

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

Referring to FIGS. 1, 3, 5, 7, 8 and 9, various update technologies and / or technologies are utilized to make hubs, docks, devices, insulin pumps, infusion pumps, and / or
Or the patient care device can be updated. For example, the patient-care device may include, for example, in some embodiments, a computing device (in some embodiments, a personal computer, or personal computer) with a bus converter that converts RS232 format data to, for example, I2C format data. It can be coupled to any device that can be used in a manner similar to a computer, including but not limited to a tablet. The processor in the hub, dock, device, insulin pump, infusion pump, and / or patient care device may, in some embodiments, load software in flash memory by, for example, a supervisor processor and / or a command processor. Updates can be performed to control or organize the download. In some embodiments, the computing device is a hub, dock, device, insulin pump, infusion pump, and / or flashing patient care device.
Downloading software in memory can be organized. Software updates obtained by the computing device may be sent into 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 scripting process.

In some embodiments, the hub, dock, device, insulin pump, infusion pump, and / or patient care device may be, but are not limited to, through a web-based secure portal and / or through email. And / or a wireless communication protocol, including, but not limited to, the ability to download applications, download software updates, upload information, and / or send information to various machines. It may be or have the capability of a remote interface. Thus, in various embodiments, the remote interface application can execute on any functional device, and is not limited to a so-called dedicated device. Further, in some embodiments, the remote interface includes, 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 Communicating with one or more devices, which may include one or more of any other devices, for example using radio frequency (RF) communication, may be enabled in Bluetooth, or otherwise. Can be made possible in the following manner.

In some embodiments, the charging station can include a hub, dock, device, insulin pump, infusion pump, and / or patient care device charging area to a remote interface that can include a USB plug. In some embodiments, the charging station can include a USB port, and in some embodiments,
A mini USB port may be included, and in some embodiments, for receiving power to charge a hub, dock, device, insulin pump, infusion pump, patient care device, and / or remote interface through the USB. A charging station can be enabled. Additionally and / or alternatively, the USB port may be connected to a computer or other device, and / or a computer-type device, through 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, while the remote interface is charging, the system can call the personal computer and / or web portal to check for update software, and there is update software available In such cases, software updates can be downloaded, for example, via a USB connection. These updates can then be transferred to the hub, dock, device, insulin pump, infusion pump, and / or patient care device upon pairing.

Thus, the user can use a hub, dock, device, insulin pump, infusion pump,
And / or the remote interface of the patient-care device 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, in addition to charging / recharging the remote interface, this may synchronize and / or upload / download data from a personal computer, 1908 and / or web portal.・ USB to computer
The connection can be used to accomplish during a remote interface "recharge", which can be done in some embodiments. At this time, the system may determine if a software update is available for one or more of the devices and / or the remote interface. The user can select "update downloads", which can also be made at the time of charging and / or a personal computer, and / or a web-based system specifically designated for the system, either with a direct or indirect remote interface. 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 is capable of communicating with various devices. Thus, software updates can be communicated to any one or more devices of the remote interface. Without limitation, data from all of the devices /
Remote interface to personal computer / web portal for both uploading information and / or updating and / or downloading applications from the personal computer and / or from the internet / web portal to either device It has many advantages, including only being connected to
This includes, but is not limited to, the ability to efficiently and easily update all devices from one connection, and / or to see all of the data from all devices in 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 new "remote interface" is introduced into the system at any time, as the personal computer / web portal contains all information from all devices, including but not limited to the remote interface. can do. This can be achieved by connecting the new remote interface to a personal computer / web portal and downloading all information about the system to the remote interface. In some embodiments, this may require first removing the old remote interface from the "authentication device", while in other embodiments, the system "allows" the additional remote interface with permission from the user. Can be. Thus, the system transmits 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 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 may connect any device (including several parameters, such as the ability to wirelessly connect and connect to a personal computer and / or web portal) to various devices, such as an infusion pump. And / or CG
Receiving 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 are 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, the information on the remote interface, including, but not limited to, uploading data to an Internet site (web portal) that can be password protected, can be uploaded and / or otherwise uploaded. Devices and / or computers and / or machines. Therefore, the user
Access information from any device, and / or download information to any device, including any device specific applications,
Thus, user information, including but not limited to information such as history, preferred settings, etc., 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. Method 600 includes operation 602.
To 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 FIG. 1, 3, 5, or 7.
4, 15, 16, 17, 35, 126, 128, 130, 148, the patient care devices 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care devices 14, 15, of 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, such as over a local area network and / or the Internet, over WiFi, over a monitoring client, one or more hubs, or a dock. Act 606 de-identifies the patient care parameters. Act 606 may be, for example, monitoring server 3 of FIGS. 1, 3, 5, 7, 8, and / or 9.
Within, can be performed 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 the patient's identity in the monitoring server. Act 608 stores the de-identified patient care parameters in a database, for example, a monitoring server such as an SQL database, a relational database, an associative database, a cloud server, and the like.

FIG. 11 is a flowchart diagram of a method 701 for collecting patient care parameters from a number of patients as determined from a patient care device in 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 of the patient-care devices disclosed herein, for example, the patient-care devices 7, 14, 15 of FIGS. 1, 3, 5, or 7.
, 16, 17, 35, 126, 128, 130, 148, the patient care device 14, FIG.
15, 16, 17, 830, 810, 812, 814, the 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 a monitoring server, eg, monitoring server 3 of FIGS. 1, 3, 5, 7, 8, or 9 and a plurality of patient-care devices associated with a plurality of patients. Optionally, multiple patient-care devices 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, for example, a database such as an SQL database, a relational database, an associative database. Act 707 can be performed automatically and / or electronically. Act 711 treats a subset of the patients from 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 the blood pressure medication of act 711 may have a blood pressure reading at a predetermined time, eg, six months, to determine if the treatment is effective for one or more patients. Can have a comparable blood pressure.

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 unplugged, power turned off, a hardware or software fault may temporarily disable one or more processors or other circuits in the patient-care device, and so on. Additionally or alternatively, one or more processors on the patient-care device may perform the method 801 such 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 the patient care device. The patient care device of method 801 may be any of the patient care devices disclosed herein, for example, FIGS.
Patient care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 14
8, the 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 a patient treatment parameter or a patient condition parameter, 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, operating parameters include infusion pump motor speed limit, infusion pump speed, wireless communication wattage limit,
Battery discharge speed or speed limit, update frequency, etc. may be used. Act 809 stores one or more operating parameters in a 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, the gain factor of a proportional-integral-derivative (PID) control loop with an adaptive gain factor 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, such as a loss of power to the patient-care device, a failure of the patient-care device, a brownout CPU reset, and the like. Act 817 determines that operation of the patient-care device can resume.

Operation 819 loads one or more received or calculated operating parameters into an active memory of the patient-care device, and operation 821 includes loading one or more received memory parameters into the active 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 with a user interface to 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 may be the monitoring client 1 or the remote communicator 11 of FIG. 1, 3, 5, 7, or 8, the monitoring client 902 of FIG. 9, the remote client of FIG. 1, 3, 5, 7, 8, or 9. The communicator 11, a mobile phone, a hand-held computer, a tablet computer, a laptop computer, a personal computer, a personal digital assistant, and the like may be used.
Although the method 900 describes the pairing between the monitoring client and the patient-care device,
In some embodiments, the method 900 is used to connect a hub (eg, hub 802 of FIG. 8) to a patient care device (eg, patient care devices 830, 810, 812, and 814).
A first patient-care device (eg, patient-care device 830 of FIG. 8)
To 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 a system monitor (eg, FIG. 1, 3, 5, 7, 8, or 9 system monitoring 131) with a patient care device (eg,
Patient care devices 7, 170, 126, 128, 1 as shown in FIGS. 1, 3, 5, and 7
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, buttons, accelerometer for user input, etc.) within operating distance of the patient-care device. Act 904 displays the identity of the patient-care device on the user interface. The patient-care device can be identified, for example, by a serial number, device type, or a visual indication on the user input of the patient-care device using a standard or custom discovery protocol. Act 906 selects a patient-care device for pairing using the user interface. For example, the user in operation 906 can touch the touch screen of the monitoring client to display a selection of the patient-care device.

Act 908 pairs the patient-care device with the monitoring client. For example, pairing a patient care device with a surveillance client may involve Bluetooth, Bluetooth
Low energy (IEEE 802.15.1), WiFi, infrared communication, near field communication (NFC ISO 13157), IR communication, or optics can be used. As will be apparent in light of the present disclosure, a custom pairing protocol may be utilized that may or may not utilize a handshake sequence. Act 910 communicates patient care parameters between the patient care device and the monitoring client, for example, whereby the patient care device can be controlled or monitored by the monitoring client.

Act 912 optionally includes adding additional patient care parameters to another patient care device.
Operatively communicate through a patient-care device. At operation 912, if a patient-care device is operatively coupled to or operably in communication with another patient-care device, the patient-care device can act as a relay or router, thereby allowing the monitoring client to operate separately. Can communicate with other patient care devices. Additionally or alternatively, the patient-care device may use information from another patient-care device for its operation, e.g., the infusion pump may have a flow rate determined by a flow meter, or a temperature. 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, either in parallel or in series, with multiple patient care devices coupled to the paired patient care device. Additionally 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 may be through electrical conductors embedded in or attached to the venous vein, via electrical communication using the fluid in the venous vein as a conductive medium, using sound waves traveling through the venous vein, or fluid in the vein. May be caused by using optically as an optical waveguide. Using communication via the intravenous line, using another communication link, such as Bluetooth, Bluetooth Low Energy, WiFi, etc. (eg, a monitoring client, hub, dock, patient care device and / or monitoring client) , A hub, dock, patient care device, and / or a system monitor with one or more of the system monitors).

In still further embodiments of the present disclosure, a first device (eg, a monitoring client, hub, patient care device, or system monitor) to a second device (eg, a monitoring client, hub, patient care device, or system). 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 pairing between devices using, for example, Bluetooth, Bluetooth Low Energy, or WiFi. Pairing settings (e.g., via near field communication or IR communication) include a monitoring client that monitors requests for user confirmation of the pairing device, e.g., a pairing via Bluetooth.
Requests on the hub, patient care device, and / or system can be commanded. In some embodiments, when the 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 to a server, eg, monitoring server 3,
Examine 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 the 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 an option on the touch screen to the user to update the patient-care device if the software is not up-to-date. Can be given. The communication link that establishes the pairing (eg, NFC) and / or the communication link that uses the pairing (eg, Bluetooth or Bluetooth Low Energy) may include updated software,
The ID and software version number can be communicated and notifications can be provided. For example, one pairing that can be used with a pump patient care device or an insulin pump is (1) filed on 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 Reference Number G98, Application No. 12 / 416,662, Bryant et al. Methods and systems for controlling pumps ("METHODS AND SYSTEMS FOR CONTROLLING")
AN INFUSION PUMP ")" and / or (3
) Filed on December 31, 2009, Agent Reference No. G75, Application No. 12/347,
No. 985, Kamen et al., "Infusion Pump Assembly (" INFUSION PU
MP ASSEMBLY ")", which can be found in the patent application entitled "MP ASSEMBLY") ", the contents of all three references 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 with 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 wearable system monitor of method 1000 with a patient care device. be able to. In some embodiments, each operation 1014-1040 is optional.

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

The patient care device of the method 1000 includes the patient care device 7, of FIG. 1, 3, 5, or 7,
14, 15, 16, 17, 35, 126, 128, 130, 148, the patient care device 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care device 14, 15, of FIG. It may be any of the patient care devices disclosed herein, such as 16, 17, 904, 906, 908, or other patient care devices disclosed herein.

The system monitor of the method 1000 includes the system 100 of FIG. 1, the system 300 of FIG.
A device 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, can be used in a stand-alone system, and / or is disclosed herein. Can be used in any other sufficient system or group of

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

The face recognition algorithm in operation 1014 includes the relative dimensions, shape, eye position, nose, chin,
Alternatively, any caregiver's facial features can be relayed, such as analyzing other facial features. The face recognition algorithm of operation 1014 may use three-dimensional face recognition, skin texture analysis, or other face recognition algorithms. Additionally or alternatively, in some embodiments, the speech recognition algorithm of operation 1014 includes a hidden Markov model,
Dynamic time warping based speech recognition, or other speech recognition algorithm (s) may 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, and thus can be attached to the patient with a wristband similar to a wristband on a watch;
A portion of the wearable system monitor may be removed from a dock (also referred to herein as a "wearable dock") with a wrist band and a snap-fit base member into which the wearable system monitor snaps. It is possible. Operation 1020 starts a timer when the wearable system monitor is unplugged from its dock. Each of the timers and associated operations are optional in the method 1000 of FIG.

The timer in operation 1020 keeps track of the time that the wearable system monitor is out of its dock. Act 1022 stops treatment if a predetermined amount of time has elapsed after undocking the wearable system monitor from the wearable dock. For example, the wearable system monitor of the method 1000 can signal the infusion pump to stop pumping. When the wearable system monitor is docked again, operation 1024 may be performed if treatment is interrupted, for example, by undocking the wearable system monitor from its wearable dock after a predetermined amount of time has elapsed. Resume treatment.

Operation 1018 removes the wearable system monitor from the wearable dock, as previously described. Act 1026 identifies the patient using one or more of, for example, voice recognition algorithms, face recognition algorithms, barcodes, RFID tags, near field communications, simple logins, caregiver inputs, and the like. Act 1026 can be similar to act 1014, can utilize the same software utilized in act 1014, and / or can 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 caregiver's identification information, for example, by using biometrics 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 given rules. Acts 1014 and / or 1026 can 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, for example, to pair the wearable system monitor with the patient care device. If the caregiver is not authorized, then the method 1000
Prevents additional pairing (or editing pairing settings) of the wearable system monitor. If the caregiver is authorized to pair the wearable system monitor, operation 1030 includes selecting one or more patient care devices for the caregiver to pair with the wearable system monitor. Enable. Use caregiver rights, for example, to ensure that certain treatments are being given to the correct patient; and / or
Or, compliance with a given rule can be provided.

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 caregiver may select the wearable system monitor (
For example, select the patient wearable system monitor of 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, pairing of the wearable system monitor with the patient-care device is performed in parallel or serially with the patient-care device with another device (eg, a monitoring client, a hub, another patient-care device, etc.). Can be used for pairing. As will be appreciated in light of the present disclosure, any suitable pairing protocol (eg, Bluetooth or IEEE 802.11
) Can be used. Additionally or alternatively, operation 1034 can record the pairing within one or more of devices 1002-1012.

Act 1036 reattaches the wearable system monitor to the wearable dock. Act 1038 includes, for example, determining whether 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 can ensure that the wearable system monitor is docked in the correct patient's wearable dock. For example, if the wearable system monitor was docked in the wrong patient's wearable dock, the wearable system monitor would recognize the mistake and (in some embodiments) stop operating so that the patient A signal is sent to a patient-care device associated with the device to prevent the associated treatment from proceeding and to a monitoring client, for example, FIGS.
, 7, 8 monitoring clients 1, 4, or 11, the monitoring clients 9, 4, or 11 of FIG. 9, or other monitoring clients disclosed herein. Act 1024 can resume treatment if treatment is interrupted, or act 1040 can treat a patient according to any updated settings 1040.

In some particular embodiments, if the caregiver is identified in act 1016 and / or the patient is identified in act 1026, the caregiver may be, for example, a monitoring client, a hub, a remote communicator, or a 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-1132 are optional.

The monitoring clients of the method 1100 are the monitoring clients 1 and 4 of FIGS.
9, or 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 includes the patient care device 7, 14, 15, 16, 17, 35 of FIG. 1, 3, 5, or 7.
, 126, 128, 130, 148, the patient care devices 14, 15, 16, 17, of FIG.
830, 810, 812, 814, the patient care devices 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 the monitoring client, the monitoring client replaces the hub, a 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 particular area for displaying patient care parameters on a predetermined display. For example, a user interface template for an infusion pump may define a particular area for display on a GUI, such as a current fluid flow rate. The user interface template may also define an area on the display of the monitoring client to display the current fluid flow, such as from an infusion pump. The user interface template may include 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 control or visual information to the user of the care device can 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 to communicate with a monitoring client having a user interface. For example, in operation 1102, the monitoring client may automatically identify a given infusion pump previously specified by the patient's treatment provider. Additionally or alternatively, in operation 1102, the provider may provide the patient care device with information regarding the operation of the selected patient care device (s) to display on the monitoring client user interface. You can give a list of

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

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

If the type has not been determined in operation 1114 or the user interface template has not been 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 additionally or alternatively, operation 1114 can raise an alarm or alert via a monitoring client and / or a patient care device. Act 1126 allows the user to select a user interface template from the plurality of user interface templates using the monitoring client user interface. Act 1128 displays the user interface template on the monitoring client user interface. 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 also includes, for example,
The user interface template described above can be used to store one or more fonts for display on a monitoring client. Font is JP
It can be stored in any format, such as EG, BMP, image format, prestore font, etc., and can be conveyed for use in an area to provide an indication of operating parameters (eg, convey values) Rather, an image indicating the number or value that is subsequently displayed on the monitoring client is communicated). In some embodiments, the fonts stored in the monitoring client can be used, so that the values of the operating parameters are changed to display in the template using the fonts stored in the monitoring client. Sent to the monitoring client.

FIG. 16 is a flowchart diagram of a method 1134 of downloading an application for controlling a patient care device according to an embodiment of the present disclosure. Method 1134 of FIG.
Although the monitoring device is described as an exemplary device for controlling a patient care device, the monitoring device may include a dock, a hub, a communication module, a remote communicator,
It can be replaced by 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. Optionally, the monitoring client of method 1134 includes:
The monitoring client 1, 4, or 11, of FIG. 1, 3, 5, 7, 8, the monitoring client 9, 4, or 11, of FIG. 9, or one of the other monitoring clients disclosed herein. Is 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.
The patient care device 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care device 14, 15, 16, 17, 904, 906, 908 of FIG. 9, or disclosed herein. It may be one of 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, FIGS.
Five or seven infusion devices 7, 830, 810, or 812 in FIG. 8, or infusion device 904 in FIG. 9 can be docked in their respective docks. At operation 1138, the monitoring client identifies the patient-care device. For example, the patient-care device can communicate, for example, an ID number, a serial number, a description, a prescription, a treatment plan, a patient treatment parameter, and the like to the monitoring client, for example, via a discovery protocol. The docked patient care device can store therein treatment information (eg, drug volume, infusion rate, total fluid volume, or other patient treatment parameters) that can be associated with or correspond to the patient, respectively.

In operation 1140, the monitoring client queries the server for an application to control the patient-care device (eg, to set an 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 may encrypt the application before sending it to the monitoring client, and the monitoring client may decrypt the application using a sufficient encryption key. Additionally or alternatively, all communications can be encrypted. During operation 1144, the monitoring client executes the application. At operation 1146, the monitoring client is communicatively coupled to the patient-care device through the application by executing the application on one or more processors. The monitoring client can place the application in a sandbox (as described below). In one such embodiment, the application includes an action set of processor-executable instructions 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. Additionally or alternatively, in some embodiments, the patient care device has parameters or values such as bolus volume, infusion flow rate, total delivery fluid, drug delivery start time, drug delivery stop time, delivery flow profile. The application can be used to control the patient-care device by optionally transmitting a pill dispensing instruction, pill type, pill dispensing schedule, and / or maximum pill dispensing criteria for dispensing the pill.

FIG. 17 is a flowchart diagram of a method 1200 for ensuring data integrity when communicating data (eg, a request) for a patient-care device, according to 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 the method 1200 may include any of the patient care devices disclosed herein, for example, the patient care device 7, FIG. 1, 3, 5, or 7 of FIG.
14, 15, 16, 17, 35, 126, 128, 130, 148, the patient care device 14, 15, 16, 17, 830, 810, 812, 814 of FIG. 8, the patient care device 14, 15, of FIG. 16, 17, 904, 906, 908, or other patient-care devices disclosed herein.

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

Act 1202 submits a request for a patient-care device using the monitoring client's user interface. For example, 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, for example,
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 reference.

Act 1204 is optional, and act 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 periodic redundancy check algorithm is dependent on the request.
A change in one bit of the request also changes the check value calculated by the cyclic redundancy check algorithm. Similarly, changing a few bits also changes the check value. Additionally or alternatively, in other embodiments, parity bits (even or odd) or other data integrity checks may be used.

Act 1210 adds a check value to the request. Act 1212 is optional and acts to communicate the request using a user interface.
Request confirmation from the user. The request for confirmation may be a pop-up dialog box on the touchscreen that displays "90 ml / hr infusion rate confirmed?" With a box to select "confirm." The text and format shown in act 1212 may be used to provide additional safeguards against bad display pixels, corrupted font tables, user misunderstandings, etc., as well as other displays, such as those displayed during request entry. The information may be in a different font, a different font size, and / or a different display location. Act 1214 confirms the request for communication of the request using a user interface. According to some embodiments of the present disclosure, a user may touch a "Confirm" box to confirm a request for communication of the request.

Act 1216 communicates the request to the patient-care device. Communication can be via wired, wireless, guided, or fiber optic communication, and the like. During act 1216, the patient-care device receives a request. During the passage of the 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, and so on. Data corruption is undesirable.

Act 1218 of method 1200 facilitates detecting corrupted data. During operation 1218, the patient-care device authenticates the check value according to the request. At operation 1218, the patient-care device may use the same periodic redundancy check algorithm as operation 1208 on the request to calculate an additional check value. The check value in 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
The check value of 6 and the check value of operation 1208 are corrupted, the data of the request has fewer or more bits, or is not the same as the digital data used to determine the check value of operation 1208 Only different.

If the check value of the request has not been validated, then in operation 1222, the patient-care device requests a retransmission 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 retransmission of the request is not successful, the method 1200 can communicate an error, an alarm, or an alert (not shown) to the monitoring client. Alternatively, if the check value is verified not to indicate data corruption, then in operation 1220 the patient care device makes the request.

In an alternative embodiment, the request of operation 1218 may additionally be sent to the monitoring client again after authentication from the patient-care device, and include an additional CRC check during transmission. The authenticating patient-care device may check in this alternative embodiment to determine whether the request is within a predetermined range (eg, whether the infusion rate for a particular drug is safe, etc.). . The monitoring client, in this alternative embodiment, can compare the request received from the patient-care device with the original request stored in memory (the requests can be correlated), and / or the monitoring client can: The request can be displayed to the user for confirmation. The request for confirmation is a pop-up dialog box on the touch screen that displays "90 ml / hr infusion rate confirmed?" With a box to select "confirm".
It may be a box. The text and format shown in this alternative embodiment for confirmation is displayed, for example, during the input of the request, to provide additional safeguards against bad display pixels, corrupted font tables, user misunderstandings, etc. Like
It may be a different font, a different font size, and / or a different display location than the other display information. In this alternative embodiment, the user may confirm the request for communication of the request using a user interface. According to some embodiments of the present disclosure, a user may touch a "Confirm" box to confirm a request for communication of the request.

Then, in this alternative embodiment, retransmit to the patient-care device to make the request, or in addition, or alternatively, in this alternative embodiment, an action message is sent to the patient-care device, and the action message is Link to the original request (e.g., "This is just for the 90 ml / hr request sent
Operation ").

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 the patient-care device 7, 14, 15, 1 of FIG. 1, 3, 5, or 7.
6, 17, 35, 126, 128, 130, 148, the patient care devices 14, 15 of FIG.
, 16, 17, 830, 810, 812, 814, or the patient care device 14, of FIG.
15, 16, 17, 904, 906, 908 and any of the patient care devices disclosed herein. The monitoring client 1302 is configured as shown in FIGS.
, 7, 8 monitoring client 1, 4, or 11, monitoring client 9, 4, or 11, FIG. 9, tablet, smart phone, PDA, etc., any of the monitoring clients described herein. .

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

The dock 1304 optionally includes a processor 1301, a sensor 1309, a watchdog 1310, a charger 1312, a battery 1314, and an alternating current (AC) power code 1316. The processor 1301 controls the operation of the dock 1304. The patient-care device 1318 can be docked on the dock 1304. The system 1300 also includes a wireless dock 1306 that docks the patient care device 1320. Wireless dock 1306 may be the same or similar to dock 1304, but wireless dock 1306 is in wireless communication with monitoring client 1302 in some embodiments.

Battery 1314 can power 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 sole power source for monitoring client 1302 or patient care device 1318. Additionally or alternatively, monitoring client 1302 and / or patient care device 1318 can include an on-board battery or a separate AC power cord (not shown).

In some exemplary embodiments, the dock 1304 provides the patient care device 1318 with an I
EC-60601 compliant power can be provided. Additionally or alternatively, dock 1304 can provide a variable DC voltage as required by patient-care device 1318. For example, dock 1304 may include a particular connector
The pins can be provided with a programmable buck-boost power supply (not shown) that can provide a DC voltage from 1 volt to 24 volts as required by the patient-care device 1318.

Battery 1314 can be charged by charger 1312 when power cord 1316 is plugged into an AC outlet (not shown). Battery 1314 is used to store patient care device 13 when AC power cord 1316 is unplugged from an AC outlet (not shown).
18 to provide unimpeded power. For example, the patient-care device 1318
An infusion pump that continues to operate even after the C power cord 1316 is unplugged. That is, the battery 1314 will remain on the patient-care device 13 even after the AC power cord 1316 has been unplugged.
18 is automatically supplied with replacement power.

Sensor 1308 may optionally include one or more of an atmospheric temperature sensor, an atmospheric pressure sensor, an atmospheric humidity sensor, and the like. Sensors 1308 may optionally include extra sensors, such as two temperature sensors, and dock 1304 determines whether one or both are faulty, for example, by comparing the readings of the two sensors. Extra sensors may be used to The dock 1304 communicates with sensors 1308 and / or other peripherals to ensure proper operation, perform data integrity checks, and provide the patient care device 1318 with its measurements, eg, ambient temperature. be able to.

The watchdog 1310 optionally makes the above query and monitors the output of the patient-care device 1318 to determine if it is within a predetermined range (eg, a physically possible or possible range). Ensure that the patient-care device 1318 is operating properly and may have feedback according to the applied input, or may be operating properly. Additionally or alternatively, the system monitor 130
10 can optionally monitor the operation of monitoring client 1302 via cable 1308. Although one watchdog 1310 is described herein, one or more watchdogs 1310, for example, a plurality of watchdogs 1310, may be used. In some exemplary embodiments, patient care device 1318 communicates with watchdog 1310 at fixed intervals. The fixed interval is optional, monitoring client 1
Configurable using the user interface at 302 or using a computer attached to the cable 1308. If the patient-care device 1318 cannot communicate with the watchdog 1310 during the fixed interval, the watchdog 1310 determines that an error has occurred within the patient-care device 1318 and alerts or alarms, for example, the speaker 132
4 to emit an audible tone or flash LED 1326 red. The responsive action to not receiving a communication within the interval can be configured and / or programmed using, for example, a 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 the LED 1326 to flash red by not responding to the watchdog 1310, and the action to the critical patient-care device may be added to the dock 1304.
And / or the monitoring client 1302 includes a nurse station and / or a remote communicator, such as the remote communicator 11 of 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. Additionally or alternatively,
LED 1326 may optionally flash green when patient care device 1326 is operating properly or is currently treating a patient. Additionally or alternatively, a speaker in the monitoring client 1302 can emit an audible alert or alarm. Where appropriate, the patient-care device can be disabled or replaced until the error condition is resolved.

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

Charger 1312 uses AC power provided through AC power cord 1316 to provide
The battery 1314 can be charged. Additionally or alternatively, 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 in 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. System 1400 also includes a USB sensor 14 coupled to dock 1404 through a USB cable.
12, a wireless sensor 1414 that wirelessly communicates with the dock 1404, a server 1416, and a hospital information server 1418. The monitoring client 1402 is configured as shown in FIGS.
Monitoring client 1, 4, or 11, monitoring client 9, 4, or 11, in FIG.
It can be any monitoring client such as one of a tablet, smart phone, PDA, laptop, etc. The dock 1404 may be connected to one or more large volume pumps 1406, 1408, and / or via electrical conductors and / or wirelessly as shown in FIG.
Or, it can communicate with the sensor 1410 to receive parameters and / or control the device.

Dock 1404 receives AC power 1420 from AC outlet 1422. Dock 1
404 uses monitoring client adapter 1424 to monitor client 1402
And operably communicate with the The monitoring client adapter 1424 has a UI connector 1426
, 1428 to dock 1404. UI connectors 1426, 1428
Provides power to the monitoring client adapter 1424 and data over the USB link. The monitoring client adapter 1424 includes 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 have a 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 types.

The connectors 1438 to 1450 allow the dock 1404 to supply power to the large capacity pump 1406,
The syringe pump 1408 and the sensor 1410 can be operatively supplied. Additionally or alternatively, connectors 1438 and 1440 may connect to dock 14
04 provides serial communication between the high volume pump 1406 and the connectors 1442 and 1444.
Provides serial communication between the bulk pump 1406 and the syringe pump 1408, and connectors 1446 and 1448 provide serial communication between the syringe pump 1408 and the sensor 1410. Connector 1450 provides any extension to 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 a subsequent device, or each device includes electrical conductors such that both of its connectors include electrical connections to respective pins.

Dock 1404 may include, 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 a patient monitoring device or one or more environmental sensors such as a temperature sensor, humidity sensor, camera, microphone, ambient light sensor, vibration sensor, and the like.

The server 1416 can communicate with the hospital information system 1418. Server 141
6 provides a WiFi router so that the dock 1404 can access the hospital information system 14.
18 in operative communication. The information uses the protocol of the dock 1404 and the hospital information system 1
418 or health level 7 (HL7) can be transferred to and from hospital information system 1418 through server 1416, which can be converted therefrom. The server 1416 (and / or the hospital information system 1418)
Can be provided with a drug error reduction system (DERS) that checks to determine that any treatment being given to 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 facility service 8 of FIGS. 1, 3, 5, 7, 8, and / or 9.

FIG. 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 include 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, AC / DC converter 1452 may be external to the dock. In other embodiments, AC / DC converter 1452 is located in dock 1404.

DC power 1454 may be 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 planes of the PCB board, respectively.
Can be received at DC power input 1456 provides power to the circuitry in dock 1404. DC
Power input 1456 can also receive wireless power 1458.

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 supercapacitor 146.
Charge 4. The charging circuit 1460 can utilize various charging techniques, for example, a constant current / constant voltage charging algorithm.

The dock 1404 includes a primary processor 1466 and a security processor 1468. Primary processor 1466 is powered by primary battery 1462. The safety processor 1468 may also be powered by a primary battery 1462 as well as from a backup battery or supercapacitor 1464.

In this exemplary embodiment, primary processor 1466 includes a 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 has a communication / ranging module 1492, and the internal expansion slot 1488 includes an RFID reader 1494 and a short-range communicator 1488 inserted therein (each optional). Is).

Security processor 1468 provides a watchdog function 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 the security processor 1468 does not receive the expected response or communication, it can be determined that an error has occurred. The safety processor 1468 responds to the error with an LED fault status light 14.
01 may be used to indicate a failure, backup speaker 1403 may be used to generate audible sound, or vibration motor 1405 may be used to cause dock 1404 to vibrate. As will be appreciated in light of the present disclosure, many failure notifications (eg, phone calls, emails, text messages, etc.) can be issued to many staff members (eg, nurses and / or physicians, equipment maintenance, etc.). .

Safety processor 1468 may use current sensing circuit 1407 to monitor the power provided through the device connector. If the safety processor 1468 determines that the current provided to the device connector 1438 has exceeded a predetermined threshold or is out of specification, the safety processor 1468 may supply the device connector 1438 from the primary battery 1462. A signal is sent to the power enable circuit 1409 to release the power.
The power enable circuit 1409 may include relays, switches, solid state switches, contactors, etc. to connect and disconnect the primary battery 1462 to the device connector 1438.

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

The communication / ranging module 1492 may communicate with other communication / ranging modules 1492, for example, on a patient-care device, another dock, or a monitoring client to determine a distance therebetween. For example, two communication / ranging modules (eg, a communication / ranging module 1492 and another communication / ranging module) may determine a distance therebetween by:
For example, wireless communication can be performed by ultrasonic waves, RF, UHF, electromagnetic energy, optics, and 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 are within a predetermined distance of each other. It may not work unless you decide.

FIG. 21 shows the infusion pump 2 connected to and delivering from the smaller fluid bag 2118
106 and an infusion pump 21 connected to and delivering from the larger fluid bag 2116
08, an infusion detection device 2112 connected to the tubing from the smaller bag 2118,
FIG. 14 illustrates an exemplary arrangement of a system 2100 with a pill dispenser 2114 and a microinfusion pump 2110, wherein a monitoring client 2102 is linked to several patient care devices via a dock 2120. I have. Monitoring client 2102 includes infusion pumps 2106, 2108, microinfusion pump 2110 (via docks 2120, 2104), and pill dispenser 21.
As shown for 14, communication with these patient-care devices can be wired.
Alternatively, the monitoring client may include the drip detection device 2112 and the monitoring client 210
There can be wireless communication with the patient-care device as suggested by the lack of a wired connection between the two. In embodiments, a wired connection between the monitoring client 2102 and the patient-care device also provides an opportunity for power to be provided from the monitoring client 2102 to the patient-care device. In this case, the monitoring client 2102 communicates 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 power outlet (not shown) in the patient's room. To provide power, the electronics required to convert the voltage can be provided. Additionally or alternatively, dock 2104 provides power to infusion pumps 2106, 2108 and microinfusion pump 2110.

In embodiments, the monitoring client 2102 may be directly from the device itself or, for example,
Information about each patient-care device can be received, 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 similar connection mounts, and the microinfusion pump 2110 can be mounted, for example, to certain dimensions of the housing of the microinfusion pump 2110. It can be attached to 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, certain patient-care devices 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 the pre-programmed treatment information is safe for the identified patient, and / or
Or, authenticate that the pre-programmed treatment information matches the prescribed treatment stored in the EMR record.

In some embodiments, the infusion detection device 2112 can communicate with the monitoring client 2102, either over a wireless or wired connection. If an abnormal fluid flow condition is detected (eg, due to a blocked pipe to the patient), (1) the monitoring client 2
The flow rate of fluid 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, either by terminating the infusion or changing the pump speed. Or (4) a signal that can generate an audible alarm (and / or a vibration alarm) on the infusion pump 2106 can be communicated to the monitoring client 2102. The alarms can be raised simultaneously on several devices, or they can be raised sequentially on a predetermined schedule. For example, if the obstruction is infusion pump 2
If it occurs in the line connected to 106, (1) the infusion detection device 2112 alerts using its internal speaker and internal vibration motor, and (2) then the infusion pump 2106
Warns using its internal speaker and internal vibration motor, (3) the monitoring client 2102 then warns using its internal speaker and internal vibration motor, and (4) finally, the remote communicator 11 ( For example, FIGS. 1, 3, 5, 7, 8, 9) warn using its internal speaker and internal vibration motor.

In some embodiments, if 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 an independent feature option is enabled if the medication being infused is pre-designated not to be interrupted or sustained in case of failure of other parts of the system. You. In some embodiments, a pump programmed to operate independently in fail-safe mode may also be configured to receive information from the infusion detection device 2112 directly, rather than through the monitoring client 2102. it can. With this option,
The pump, in some embodiments, may be programmed to stop infusion if the infusion 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, the 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 a patient care device 2106, 2108, 2110 according to an embodiment of the present disclosure.
, Docked in dock for wireless communication with 2112, 2114
11 shows an electronic patient care system 2200 having the same. The monitoring client 2102 can communicate with the patient care device 2106 wirelessly or through a wireless transceiver on the dock 2120.
, 2108, 2110, 2112. For example, monitoring client 2
The 102 can communicate with the transceiver in the dock 2104. Additionally or alternatively, dock 2120 communicates with dock 2104 by monitoring client 21.
02 and / or patient care devices 2106, 2108, 2110, 2112
, A transceiver for direct use via a wireless connection to 2114.

FIG. 23 illustrates an electronic patient care system 2300 having a modular infusion pump 2302, 2304, 2306, 2308 docked in a dock 2310 having a monitoring client 2312 with a retractable user interface, according to an embodiment of the present disclosure. ing. The modular infusion pumps 2302, 2304, 2306, 2308 have standard connectors so that they can snap 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 increase infusion rate button 2320, and a lower infusion rate button 2322. FIG. 24 is a side view of the electronic patient care system 2300 of FIG. 23, wherein the mounting post 2402 is movable, thereby allowing the monitoring client 2312 to rotate along the pivot 2404 and push down into the cavity 2400. Thus, the outline of the cavity 2400 in which the monitoring client 2312 can be stored is shown.

FIG. 25 has modular infusion pumps 2502, 2504, 2506, 2508 docked in a dock 2510 having a staggered monitoring client 2512 with a retractable user interface, according to another embodiment of the present disclosure. Shown is an electronic patient care system 2500. The system 2500 of FIG.
00 are staggered modular infusion pumps 2502, 2504, 2506, 2
Other than having 508, it may be similar to system 2300 of FIG. The staggered arrangement of the modular infusion pumps 2502, 2504, 2506, 2508 can provide more room for tubing routing.

FIG. 26 shows an electronic patient care system 2600 having modular infusion pumps 2602, 2604, 2606 docked in 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 within the dock 2608, and / or some monitoring client 2610 circuitry can be stored within the dock 2608. 27, which shows a side view of the electronic patient care system 2600 of FIG. 26, the monitoring client 2610 has a cavity 270 inside the dock 2608.
2 pivots along a pivot 2700 to store the monitoring client 2610 therein.

FIG. 28 illustrates another embodiment of an electronic patient care system 2900 with 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 an electrical connection to dock 2904 and scanner 2912.
Modular infusion pumps 2906, 2908, 2910 are shown docked in device dock 2904. The system 2900 also includes a scanner 2912 coupled to the hub 2902. Dock 2904, each dock 2904
Are provided with quick-release handles 2914 and 2916 on the left and right sides. Also, respective buttons 2918 that are lit when the patient care device is the focus of interaction on the monitoring client 2901 (type of monitoring client, shown as a tablet) or 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 may select a particular modular infusion pump, or the user may select buttons 2918, 2920, and 292 of the modular infusion pumps 2906, 2908, and 2910.
2 can be selected for operation on the monitoring client 2901 by pressing each button.

30-32 show 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.
FIG. 13 shows a top view of a dock 3100 having a hole 3102 for receiving the same. 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. 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 may be used to attach clutches 3110 and 3112 to struts 310 (e.g., by pushing handles 3106, 3107).
4 can be locked. As can be readily seen from FIG. 31, a downward force, for example, due to gravity, further presses the clutches 3110, 3112 against the post 3104. Although two clutches 3110, 3112 are shown in FIG. 31, one clutch can be used to push the post 3104 against the friction surface. FIG. 32 shows an alternative post mounting structure 3300 that uses two fasteners 3302 and 3304 to tighten the post 3104.

FIG. 33 illustrates an infusion pump 3400 and a retractable connector 34 according to an embodiment of the present disclosure.
02, 3406 are shown. 33 to 35, the hub 3401 is provided with the storable connector 3.
402 and 3406 are shown. Hub 3401 has a docking connector and docks it. The retractable connectors 3402 and 3406 are shown as 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 mounting mechanism surrounded by the hub 3401 (see FIG. 36). Hub 3401 may be a dock or a cradle in some embodiments and may optionally include a handle coupled thereto. The handle can be integrated into the strut mounting mechanism, whereby lifting the handle releases the hub 3401 from the strut. Alternatively, in some embodiments, the hub 3401 supports a cradle, which can be attached to a surveillance client, such as a tablet, or the surveillance client can be separately mounted to a post. Retractable connectors 3402 and 3
The 406, in some embodiments, can have a support feature (eg, a lip) on the bottom of the retractable connectors 3402 and 3406 to support the infusion pump when installed. In this exemplary embodiment, the lip may also be a mechanism for electrical connection.

In FIG. 34, the retractable connector 3402 is shown open, and connectors 3408 and 3410 are shown. Connectors 3408 and 3410 are retractable connectors 340
2, but 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 3408
A cover for covering 410. The retractable connector 3406 has an infusion pump 3412 docked thereto. FIG. 35 shows the infusion pump 3416 docked to the retractable connector 3402, with the infusion pump 3412 docked to the 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 the infusion pump 3400 and the hub 3401 as attached to the post 3420 of FIGS.
The retractable connectors 3402 and 3406 are shown in an open configuration.

FIG. 37 illustrates several connectors 3703, 3705, 370 according to embodiments of the present disclosure.
7 shows a square hub 3701 with 7,3709. 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 to it using a subset. In some embodiments, each connector 3703, 3705, 3707, and 3709 uses a subset of the available pins specific to the device being connected based on the type of device, as determined, for example, from signals. be able to. The pillar mounting mechanism is a square hub 3
701. The square hub 3701 also has a front connector 37
11 and a back connector 3713. Each connector 3703, 3705
The mechanical attachments associated with the 3707, 3709, 3711, 3712 may be permanent attachments (eg, screws) or quick release attachment points (eg, latches).

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 connection type 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 to the right of the hub 3701. The pump dock 3723 is removable for transport, with all infusion pumps 3725, 3727, 3729, all mounted so that they can be transported as one unit. A quick release 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.
An articulated monitoring client 3721 (eg, a tablet) can be permanently attached to the hub 3701 and a “zero channel pump” when the dock 3723 is removed.
Can be produced. 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 connected to a hub 3701 according to another embodiment of the present disclosure.
Shown is an electronic patient care system having a post 3715 and a hub 3701 coupled to 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 in FIG. 40 is shown as a connector plate. That is, the dock 3735 uses the generic connector provided by the hub
01 is shown as an adapter or connector plate adapted to facilitate connection of the infusion pumps 3725, 3727, 3729. 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 includes a connector 4 for receiving three respective infusion pumps, eg, infusion pumps 4113 and / or 4115.
107, 4109, and 4111. The patient care system 4101 includes the support 4
A monitoring client 4117, such as a tablet, and a connector 410 on one side of
There is an infusion pump attachable to the other side of the column 4105 via 7, 4109 and 4111. Although three connectors 4107, 4109, 4111 are shown,
Any number of connectors can be used. The electronic patient care system 4101 includes a monitoring client 4117 and an infusion pump, such as connectors 4107, 4109,
Facilitate viewing of infusion pumps 4113 and 4115 attached to 4111.
In addition, the electronic patient care system 4101 facilitates tube routing. The tubing can be inserted from the top to the bottom of the infusion pump, or from the side of the monitoring client 4117 on the side of the post 4105 (eg, using a tube organizer on the post 4105).
Can be routed. The monitoring client 4117 can be linked.
The post mount of the hub 4103 can be fixed to the post 4105 or can be slid over steps within the post 4105 that are available with several adjustable posts. Although the post mount of the hub 4103 is shown here as a tubular shape, in other embodiments it may be rectangular and / or include a power supply, handle, and / or hub hardware. . In some embodiments, 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 the three. The infusion pump 4713 includes a slide connector 4715 that slides within one of the notches 4207, 4709, 4711. The connector 4715 may be structurally sufficient and / or may add additional structural support. Monitoring client 42
03 may break, for example, flatten at dock 4205. The dock 4205 can include a run-out for routing tubes, for example, from left to right or 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 tubing. FIG. 43 is an enlarged view of a T-shaped connector, such as connector 4715 of FIG. 42, for connecting 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.
Shown is an electronic patient care system 4401 having a 4405 and a stackable container 4407 for storing infusion bags, eg, infusion bags 4411 and 4408. Stackable container 4407 includes lid 441 for securing bags 4411, 4409 therein.
3 is provided. The electronic patient care system 4401 includes a monitoring client 4415 with a collapsible screen and a handle 4417 that can be raised for portability.

Infusion bags 4411 and 4407 may be microbags and may be embedded in an integrated flow monitor and / or having a serial number or data (eg, patient data) associated with the contents of bag 4411 and / or 4407. RFID tag can be provided. In this particular embodiment, microbags 4411 and 440
7 can include an integrated flow meter, an infusion counter, an integrated infusion chamber, a communication link for communicating via an intravenous line, 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 is via electrical conductors embedded or attached in the venous duct, via telecommunications using the fluid in the venous duct as a conductive medium, using sound waves traveling through the venous duct, or optical waveguides Can occur optically by using the fluid in the tube as Intravenous communications may be encrypted, for example, using symmetric or asymmetric key cryptography. Microbag 4411 and / or 4407 can include an optical communicator that communicates data (via an infusion tube) to the infusion pump, describing the flow rate and / or contents of the liquid contained therein. The microbag 4411 and / or 4407 is a pigtail that can interface with a drip counter that can be used by a reader to determine the content and / or amount of liquid inside the microbag 4411 and / or 4407. Can include an RFID and / or NFC tag (eg,
Information is encoded in). Microbags 4411 and / or 4407 can include bubble sensors (capacitive or ultrasonic) that communicate bubble size estimates to monitoring clients and / or hubs. The microbag 4411 and / or 4407 may be activated (e.g., open a valve and / or activate an integrated flow meter, drip counter or drip chamber, communication link, power supply, etc.) before NFC and / or measurement. It may need to be within a predetermined distance from the patient, as determined by the distance module.

FIG. 45 illustrates a stackable patient care device 4503, 4505, 4507, stackable 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 foldable screen and a monitoring client 4519 that includes a handle 4520 that can be raised for portability.

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

FIG. 47 illustrates 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.
Shown is an electronic patient care system 4701 having 703, 4705, 4707, 4709.

FIG. 48 illustrates a display (ie, display 48) according to another embodiment of the present disclosure.
11, 4813, 4815, 4817), respectively, showing an electronic patient care system 4801 having stackable patient care devices 4803, 4805, 4807, 4809. FIG. 49 is an enlarged view of the handle 4901 of the electronic patient care device of FIG. 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 illustrating 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 a post 5105.

FIG. 53 illustrates 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.
Shown is an electronic patient care system 5301 having 5309, 5311, 5313, 5315. Hub 5303 is coupled to monitoring client 5305. The dock connector 5305 connects to the patient care devices 5311, 5313,
And 5315, connected to patient care devices 5307 and 5309.

FIG. 54 illustrates an electronic patient care system 54 having stackable patient care devices 5403, 5405, 5407 that are stackable from the bottom up 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 illustrates a perspective view of a clutch system 5601 having a release handle 5603 for frictionally gripping a post 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 back to show 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. The system 3400 includes the user interface component 3
402, a pump engine component 3404, a data management therapy layer component 3406, and a fluid measurement / safety monitor component 3408.

Components 3402, 3404, 3406, and 3408 may include one or more of the following: hardware, software, running software, digital logic, firmware, bytecode, virtualization, using a 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 operation set of processor-executable instructions configured to be executed by one or more processors on device 3401; 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.

User interface 3402 may be a touchscreen (or processor executable code for controlling the touchscreen) configured to receive user input, such as an infusion rate. The user interface 3402 can be used by an operator to set treatment parameters and view treatment status. The user interface 3402 can be used to adjust patient treatment parameters during treatment, for setup guidance of the system 3400, and / or for post-treatment degradation of the system 3400. User interface 3402 can include a touch screen and buttons. User interface 3402 may be a resident software application on device 3401 or may be executable by a remote or separate component, such as a handheld device or a nurse station computer.
For example, the user interface 3402 may be the remote communicator 11 or FIG.
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 includes one or more external data systems 3
410. For example, the data management therapy component 3406 may indicate that the therapy (eg, infusion rate) entered via the user interface component 3402 is (1) safe for the patient, (2) the illness, condition, or illness of the patient 3412. ,
(3) not contraindicated by another drug or treatment,
4) There is no need for the presence of an expert not determined to be close to the patient 3412 (as determined by RFID tags, voice authentication, face recognition, username / password identification or authentication, secure signature, etc.). The electronic medical record 3410 can be compared to the patient's 3412 ID to determine if this is the case.

The data management treatment component 3406 can include all treatment settings, can authenticate the settings in an external data system 3410, and can store treatment history such as flow rates, drug settings, vital signs, etc. in the external data system 3410. Can be recorded in electronic medical records. 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 a patient treatment parameter, such as an infusion rate, to the infusion pump 3414. Infusion pump 3414 can be any of the infusion pumps disclosed herein. In some embodiments of the present disclosure, only the pump engine component 3404 sends 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.

Fluid measurement / safety monitor component 3408 can act as a watchdog for other pump engine components 3404, receive flow data from a flow meter (not shown), and watchdog for pump 3414. Can work as The fluid measurement / safety monitor component 3408 can determine if a fault or error condition exists, for example, if the measured infusion rate is outside a predetermined range or above a threshold, and communicate a stop command to the pump 3414. Then, 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 infused fluid to the patient 3412.

Additionally or alternatively, the fluid measurement / safety monitor component 3408
Can receive flow rate and feedback regarding patient condition parameters such as heart rate, temperature, vital signs, and the like. Fluid measurement / safety monitor component 34
08, if any of the parameters monitored are outside a predetermined range, an alert, such as a text message or email, may be issued, for example, to a monitoring device, remote communicator, other monitoring client, smart phone, tablet, PC, etc. , Issued to tablet computers, etc. Additionally or alternatively, the mechanical fluid, fluid measurement / safety monitor component 3408 communicates with a mechanical occlusion device (not shown) to communicate with the patient 3
The flow of infusion fluid to 412 can be stopped.

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

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, a pulse oximeter device, a heart rate monitor device, a blood pressure device, and a temperature device. The devices 3502, 3504, 3506, 3508, 3510 communicate with a monitoring client, for example, a tablet 3514, and then communicate with one or more servers 3516. The one or more servers 3516 may include, for example, the equipment service 8, the online drug database 9 or drug adverse event network 9, the patient's personal HER 19 ', 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, or the like may be used.

Tablet 3514 may be a primary program and 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 3514.
14 may identify the patient (eg, if the patient's ID is
Tablet 3514 can download patient treatment parameters after being manually entered into 514 through an RFID reader, barcode reader, etc.).

Tablet 3514 may communicate patient status 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, eg, patient status parameters or patient treatment parameters, in real-time (ie, with at least one time constraint, such as a deadline).

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

The infusion pump 3504 may be a low flow infusion pump (e.g., capable of delivering 0.1-10 milliliters per hour), a medium flow infusion pump (e.g., capable of delivering 10-300 milliliters per hour), a high flow infusion pump, 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. The infusion pump 3504 is connected to the hub 3 through the receiver.
518. 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. The infusion pump 3504 can be sent to a pharmacy for configuration and / or can be attached to an infusion bag (also called 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 the patient's identity from the smart arm band, for example, via RFID, and the other devices 3502, 3504, 350
8, 3510 can provide a watchdog function to track flow,
It may include a call button that detects air, monitors vitals, or is integrated thereon. Wearable system monitor 3506 can occlude flow in response to an error condition. Wearable system monitor 3506 may be in wireless communication with hub 3518 or infusion pump 3504.

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

Dock 3702 supplies power to the internal battery of tablet 3708 and charges it.
Dock 3702 is also coupled to USB hub 3710, with tablet 3708 being the host. Flow meter 3716, eg, drip 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 will be appreciated in light of the present disclosure, the flow meter 3716 and the wearable system monitor 3718 are coupled to a transceiver and an antenna, such as the communication module 124 and the antenna 122 of FIG. It can be operatively coupled or integrated therein.

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

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

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

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

In some embodiments of the present disclosure, the hub 3910 is a patient safety circuit that allows the system 3900 to be completely fault tolerant to any failure or error that may occur in or with 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, the infusion pump 390).
2 has a display 3918, but not the device 3906 explicitly shown). For example, hub 3910 may provide infusion rate and drug user confirmation (e.g., hub 3) before sending a request or command for infusion rate to infusion pump 3902.
(Via a touch screen at 910). Additionally or alternatively, in some embodiments, the infusion pump 3902 is configured to include (eg, infusion pump 3
Requests infusion rate and drug user confirmation (via touch screen 902) before delivery.

The 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, when an alarm or alarm condition occurs May be a fail-safe system to secure the patient-care device in the event of a failure, may comprise an independent sensor for the critical sensor, and may be a time-critical patient-care device, such as a real-time patient-care device A separate time-based or real-time clock for powering the patient-care device through a USB cable can be provided, and a circuit for charging the internal battery therein can be provided. Battery Door can be.

Hub 3910 may include a power input module for AC or DC power and may receive power from a standard AC power outlet. Hub 3910 is an IEC-60
According to 601 requirements for insulation and electromagnetic compatibility can be fulfilled. Hub 3
910 provides AC power to regulated DC power used to charge an internal backup battery, provide power to various circuits therein, or power patient care devices 3906, 3902 via respective USB cables. Is converted.

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

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 may have its own battery charging circuit, for example a constant voltage / constant current charging circuit.

The display 3916 of the hub 3910 may be a patient care device 3902, 3906, 39
An alarm or alarm can be displayed based on the signal received from 20. For example, if hub 3910 can periodically query patient care devices 3902, 3906, 3920 and hub 3910 does not receive a response from one or more of patient care devices 3902, 3906, 3920 or tablet 3914, Alternatively, if one or more of the patient-care devices 3902, 3906, 3920 or tablet 3914 becomes unresponsive, the display 3914 displays an alarm or alarm. The alarm may indicate to the user that the patient-care device is unresponsive. The patient care device is via the serial number, the infusion pump path, the drug being delivered by the infusion pump, the letters or numbers displayed on the patient care device, via the visual mapping of the patient care device on the monitoring device And, via the others, can be identified by the monitoring client. For example, the monitoring client 3914 can display a layout view of the patient-care device 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 alerts the user to the device being alerted and / or alarmed. Hub 3910 may also include status lights, LEDs, speakers, vibrators, or other visual / audio indicators.

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

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

Hub 3910 may include, for example, WiFi capabilities, Zigbee, Bluetooth, low energy Bluetooth, Xbee, short-range communication, ranging devices, and the like. Hub 3910 may also include various wired interfaces such as, for example, RS-232, SPI, CAN, USB, Ethernet connectivity, and the like.

The hub 3910 also provides a patient care device 3902 in the safety circuit when lowered.
All of the 3906, 3920 or tablet dock 3912, or one on the patient-care device 3902, 3906, 3920 or tablet dock 3912, which can cause the particular device that fails to enter fail-safe mode. Or it may include multiple fail-safe lines. For example, an electrical conductor (ie, a wire or line) may be between the hub 3910 and one or more coupled to a voltage source via a resistor (ie, the line is “high”), and another Can couple the conductor to ground (the conductor can be so-called "pulled down"). In some, but not all, embodiments of the present disclosure, patient care devices 3902, 3906,
When one or more of the 920 or a patient care device disclosed herein, such as a monitoring client such as a tablet 3914, enters a fail-safe mode, the software
Only critical ones (predetermined set) are enabled and / or only critical circuits (predetermined set) are powered. In some, but not all embodiments, all circuits can be disabled except the motor driver circuit of the infusion pump, such as, for example, a radio, display, display driver, or other circuit. Additionally or alternatively, in some but not all embodiments, disabling some software routines or features that are not required if a particular fail-safe mode is entered. And software that displays configuration information can be disabled, such as in an infusion pump.

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

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

Hub 3910 also includes one or more processors for execution by one or more processors therein.
One or more components can be provided. The hub 3910, 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, if hub 3910 does not receive a response, hub 3
910 monitors the health of the various power supply voltages, and monitors the voltage levels to verify that they are responding to "pull" the safety line (indicating that an error condition exists). A watchdog circuit for checking and authenticating that data transmitted through the hub 3910 has not been corrupted and transmitting internal and route packets transmitted to the tablet 3914 or the patient care device disclosed herein. A data integrity check to check and a range checker to allow a programmed threshold check can be provided. Hub 3910 may use a data integrity check.

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

Hub 3910 may include an application programming interface (API) for displaying data on display 3916 or tablet 3914. APIs can include secure data classes. The patient-care device can be displayed on the display 3916 of the hub 3910 using the 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, hub 3910 may send a message to tablet 3914 instructing tablet 3914 to download an application from one or more servers 3926 to display a user interface on tablet 3914. , Hub 3910 may be connected via a USB cable or wirelessly (eg,
(Using the pairing described herein), the patient care device may
This message can be sent when first connected to. In addition to it,
Or, alternatively, hub 3910 sends instructions to 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 an infusion pump 4004A-40A.
The electronic medical record server of one or more servers 4002 enters a prescription and validates the prescription with infusion pump 4004A-400C for confirmation using one or more interfaces of 04C.
Shown is a system 4000 that enables transmission to one infusion pump at 4004C. The prescription is sent from the server 4 to the infusion pumps 4004A to 4004C via the application.
002 from the EMR record. The application may be on a bedside computer 4008 that can be used to determine clinician compliance with prescriptions. 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 to download prescriptions and / or treatment plans for use on 4C may be included. APIs can include secure data classes. In some additional embodiments, the hub communicates with the server 4001 through middleware as described above. Additionally or alternatively, with reference to FIG. 65, the application for interfacing with the EMR server may be on the tablet 4102 as shown in FIG. Although the scanner 4104 is shown coupled to the hub 4106, it can also be attached to the patient-care devices 4108A-4108C or the tablet hub 4110. Scanner 41 to identify drug
Rather than using 04, the camera 4112 can be used to identify a drug by reading a 2D or 3D barcode on the drug, for example, on an infusion bag or pill container.

In FIG. 66, a system 4200 is shown. Patient care devices 4202A-420
One of the 2C patient care devices may broadcast patient care parameters, such as patient treatment parameters, such as infusion rates, to authorized 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 to a temperature probe). The data can have different levels of encryption so that not all data is accessible to all clients (e.g., a device registered to another device has the lowest level of security priority) May be necessary). The broadcast signal may be the same signal received by tablet 4212 or a subset thereof. The broadcast message may use a cross-platform protocol, eg, http, https, and the like.

FIG. 67 illustrates a timing diagram 4300 for communication to 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 performed on a tablet 4212. In some embodiments of the present disclosure, the drug error reduction system and / or guardrail (or a cached version thereof) may include a hub 4204 or an infusion pump 420.
Providing redundant patient safety when the system 4200 is not on operative communication with an electronic medical record on one or more servers 4214 on one of the infusion pumps 2A-4202C. Can be.

Timing diagram 4300 includes operations 4302 through 4354. During operation 4302, the user updates the prescription of an application in a computer or monitoring client, for example, a tablet. In operation 4304, the updated prescription is communicated to one or more servers in the EMR. Act 4306 checks the prescription in the DERS,
For example, predetermined criteria may be used to determine if it is safe for any patient or a particular patient. Act 4308 communicates security information from the DERS system to an application on a monitoring client or computer application. Act 4310 includes:
Receive safety information. Act 4312 communicates the prescription from the tablet or computer application to the hub's API in act 4314 via the hub's EMR application programming interface (API). APIs can include secure data classes. 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 in operation 4324 and received in operation 4326. During act 4326, treatment is initiated and status information is displayed in act 4326.
The pump status UI is communicated via 28 and displayed to the user in operation 4330.

Also, status information is communicated in acts 4332 and 4334. At operation 4326, status information is received by the hub broadcasting status over WiFi in operation 4338. The tablet application converts the state information in operation 4340 to operation 4342.
Received from communications in the middle state. During act 4346, the state information is interfaced via the EMR API, communicated to the tablet or computer app via act 4348, and received at act 4350. The status information is transmitted to the EMR at operation 4352.
The database is communicated and the EMR database is updated in operation 4354. In some embodiments, communication between the EMR and the Allscript tablet / computer app or hub is through middleware (eg, middleware on monitoring server 3 of FIG. 1).

68A-68B illustrate a method 43 illustrating the timing diagram of FIG. 67, according to an embodiment of the present disclosure.
FIG. 35 shows a flowchart diagram of 35. Method 4335 includes acts 4301-4333.

Act 4301 updates a patient prescription in the application. Act 4303 queries the electronic medical record on the server from the application to determine the security of the updated prescription for the patient. Act 4305 communicates the determined security of the updated prescription for the patient from the server to the application. Act 4307 communicates the updated prescription from the application to the API of the hub. APIs can include secure data classes. In some embodiments, the communication of operation 4307 may include middleware (eg, FIG. 1).
Through the middleware on the monitoring server 3). Act 4309 determines the security 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 the updated prescription confirmation request on the pump user interface. Act 4315 confirms the updated prescription on the pump user interface. Act 4317 pumps fluid according to the updated prescription. Act 4319 displays the parameters on the user interface of the pump. Act 4321 communicates parameters from the pump to the hub. Act 4323 wirelessly broadcasts the parameters from the hub. Act 4325 communicates parameters from the hub to a monitoring client, for example, a tablet. Act 4327 displays the parameters on the monitoring client user interface. Act 4329 communicates parameters and / or updated prescriptions from the hub to the application using the hub's 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,
Communication is performed through middleware on the monitoring server 3 in FIG.

FIG. 69 illustrates an electronic patient care system 4400, and FIG. 70 illustrates an electronic patient care system 4500. In some embodiments, the electronic medical record application can reside on the tablet 4402 as shown in FIG. 69 and / or on the bedside computer 4502 in FIG. 70. 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 device, some combination thereof. May or may not be utilized. The scanner 4404 can be used to determine whether a medicament, eg, an infusion bag, matches a prescription prescribed for the identified patient, eg, the patient can be identified using the scanner 4404.

FIG. 71 shows that infusion pump 4408A and / or hub
Shows a timing diagram 4600 illustrating a method for requesting which prescription was prescribed to a patient by querying an electronic medical record application running on a tablet 4402 from some embodiments of the present disclosure. ing. The user can enter patient identification information, or the patient identification information is scanned using 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 multiple prescriptions, for example, multiple 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. Act 4602 “pulls” prescription information from a monitoring client.
. Patients can be identified using a barcode scanner, RFID interrogator, voice or face 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. APIs can include secure data classes. The patient's identity is communicated to the EMR database in operation 4610 and the EMR
The prescription list is communicated to the MR API during operation 4614 and received by the monitoring client or the EMR program running on the computer application at operation 4616, and then communicated 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 monitoring server 3 of FIG. 1).

The monitoring client, eg, a tablet, may display various prescriptions for the patient at operation 4620 for user selection. The selected prescription is communicated to the hub in operation 4622, and the prescription can be checked in operation 4624, 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, for example using DERS, or by requesting user authentication. Additionally or alternatively, the user can activate the prescription using the pump UI.

The validated prescription of act 4628 is communicated to the hub in act 4630 and act 4630
At 632, this is communicated to the monitoring client application at operation 4634. At operation 4636, the user can approve the prescription and then communicate to the hub at operation 4638. Communication of the approved prescription occurs at operation 4640, which communicates it to the pump via operation 4642. In operation 4644, the pump communicates the prescription to the pump UI in operation 4646, and the user may confirm the prescription in operation 4642. The confirmation is sent to the pump in operation 4650. Act 4652 provides a therapy.

72A-72B illustrate 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 the patient's identity using a monitoring client application within the monitoring client, eg, a tablet. Act 4657 communicates the patient's identification information from the monitoring client application to the API. Act 4659 queries the electronic medical record on the server from the API to determine at least one prescription for the patient.
In some embodiments, operation 4659 includes middleware (eg, monitoring server 3 of FIG. 1).
Refer to the electronic medical record through the middleware above. Act 4661 communicates at least one determined prescription for the patient from the server to the API. Act 4663 communicates at least one determined prescription for the patient from the API to the monitoring client application within the monitoring client. Act 4665 optionally displays a user-selectable list of at least one prescription on a user display of the monitoring client. Act 4667 optionally selects a prescription for at least one prescription using the 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 activates 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 selected prescription and / or at least one prescription from the hub 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 confirms the validated prescription on the monitoring client user interface. Act 4683 communicates the validated prescription from the monitoring client application of the monitoring client to the hub. Act 4885 communicates the validated prescription from the hub to the pump. Action 4687
Displays the validated prescription confirmation request on the user interface of the pump. Act 4689 confirms the validated prescription on the user interface of the pump. Act 4691 pumps fluid according to the validated prescription.

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

In operation 4702, a user updates a prescription in an EMR application on a monitoring client, for example, a tablet or computer. The update may be a new prescription for the changed prescription. The updated prescription is communicated to the application in operation 4704. The application processes the update in operation 4706 and communicates it to the EMR database in operation 4719. In operation 4708, the DERS checks for an 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 at operation 4716. The pump operates 471
Process the updated prescription at 8 and communicate this to the pump at operation 4720.
The user confirms the updated prescription in operation 4722 and is communicated to the pump in operation 4724. At operation 4726, treatment is delivered.

FIG. 74 illustrates 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 prescription for the patient in the application. Action 4705 is:
The application queries the electronic medical record on the server to confirm the security of the updated prescription for the patient. Act 4707 communicates the determined security of the updated prescription for the patient from the server to the application. Operation 4709 is a monitoring client API.
To communicate the updated prescription from the application. Act 4711 communicates the updated prescription from the monitoring client to the pump. Act 4713 displays the updated prescription confirmation request on the pump user interface. Act 4715 confirms the updated prescription on the pump user interface. Act 4717 pumps fluid according to the updated prescription.

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

FIG. 76 illustrates 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 prescription for the patient in the application. Act 4805 includes:
The application queries the electronic medical record on the server to confirm the security of the updated prescription for the patient. Act 4807 communicates the determined security of the updated prescription for the patient from the server to the application. Act 4809 communicates the updated prescription from the application to the API of the hub. Act 4811 communicates the updated prescription from the hub to the pump. Act 4813 displays the updated prescription confirmation request on the pump user interface. Act 4815 confirms the updated prescription on the pump user interface. Act 4817 pumps fluid according to the updated prescription.

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

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

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

80A-80B show flowchart diagrams of a method 5101 illustrating the timing diagram of FIG. 79, according to an embodiment of the present disclosure. Method 5105 includes acts 5103-51512.
8 inclusive.

Act 5103 determines the patient's identity using a monitoring client application within the monitoring client, eg, a tablet. Operation 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 at least one determined 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 a 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 selected prescription and / or at least one prescription from the monitoring client 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 confirms the validated prescription 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 according to the validated prescription.

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

In act 5202, the user requests a prescription from the EMR via the monitoring client application, and is communicated in act 5204 and processed by act 5206. The monitoring client application determines in operation 5208 that the hub's EMR AP
I interfaced with 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, 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
Enabled at 26. The activation is communicated at operation 5228 and operation 5230 is performed.
Is communicated to the pump at operation 5232. Operation 5
The prescription can be confirmed at 234 and communicated at act 5236 to act 5238
Start treatment in the pump at.

FIGS. 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 a patient's identity using a monitoring client application within the monitoring client, eg, a tablet. Act 5205 communicates the patient's identity from the monitoring client application to the API on the hub. Operation 5207 queries an electronic medical record on the server from the API to determine at least one prescription for the patient. Acts 5205 and / or 5207 can utilize middleware (eg, middleware on monitoring server 3 of FIG. 1). Act 5209 communicates at least one determined prescription for the patient from the server to the API of the hub. Act 5211 communicates the monitoring client application with at least one prescription determined from the API of the hub. Act 5213 optionally displays a user-selectable list of at least one prescription on a user display of the monitoring client. Act 5215 optionally selects at least one prescription for the prescription using the display on the monitoring client. Act 5217 communicates the selected prescription and / or at least one prescription from the monitoring client 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 confirms the validated prescription 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 user interface of the pump. Act 5231 confirms the validated prescription on the pump user interface. Act 5233 pumps fluid according to the validated prescription.

FIGS. 83-89 illustrate some additional embodiments of an electronic patient care system, according to some embodiments of the present disclosure. FIG. 83 illustrates tablet 3514 and / or hub 3
To display some of the patient's electronic medical records on the user interface of 804,
Shown is a system 5300 in which an electronic medical record application interfaces with an electronic medical record on one or more servers 3516. A subset of the data from the electronic medical record received from one or more servers 3516 (eg, the 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 the data from the electronic medical record may 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 records application 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 record is shown. A subset of the data from the electronic medical record received from one or more servers 4410 (eg, the 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 the data from the electronic medical record may 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, which may be an independent system or may be the system 5400 of FIG. 84, if communication with one or more servers 4410 is interrupted. FIG. 86 illustrates a system 5600, which may be an independent system if communication with one or more servers 4410 is interrupted, or may be the system 5400 of FIG. In FIGS. 85-86, a prescription can be programmed into the system 5500, 5600 without access to the electronic medical record server of one or more servers 4410. The prescription can be adjusted on a tablet 4402, bedside computer 4502, or infusion pump 4408A. Hub 5804 is a scanner, bedside
Communication with a computer 4502 and / or infusion pumps 4408A-4408C may be wireless and / or via a wired connection. In some specific embodiments, the monitoring client 4402, the hub, and / or the bedside computer have an EMR
It can be programmed without data, but can also be compared to a local version of the guardrail.

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

FIG. 88 illustrates a system 5 without a tablet or bedside computer.
800 is shown. System 5800 may be system 5700 of FIG. 87 when communication to one or more servers 5704 is not available 5704. The infusion pump 5802A is programmed using a user interface on the pump 5802A, and a cached set of predetermined safety criteria (eg, guardrail) is stored on the hub 582A.
04 or pumps 5802A-5802C. The predetermined safety criteria can be based on the drug being delivered, the patient, allergies, or memorized drug contraindications, and can prevent unsafe treatment settings from being delivered to the patient. Hub 5804 may be a scanner and / or
Or, it can communicate with the 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. The infusion pumps 5902A-5902C can be controlled directly using each respective user interface on the pump, and a predetermined set of criteria (e.g., DERS) can be cached therein, and 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 a circuit 6000 of the hub disclosed herein. Additionally or alternatively, 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 some devices via a device module interface. Circuit 6000 includes a first fail-safe line 6002 that can be activated by device processor subsystem 6004 and a second fail-safe line that can be activated by interface processor subsystem 6008.
Line 6006 is included. The first and second failsafe lines 6002, 6006 are provided in an OR gate 6010 having an output to an output failsafe line 6012. If either the device processor subsystem 6004 or the interface processor subsystem 6008 detects a failure or an error, the first or second failsafe line 6002, 6006 will output the output failsafe line 6
012 can be activated. The fail-safe line 6012 is responsive to an output fail-safe line 6012, for example, an auto-occlusion device that can automatically prevent fluid flow through an intravenous line when a signal is received from the output fail-safe line 6012. In some embodiments, the patient-care device coupled to the device module interface may be a buck, boost, or buck-boost power supply, respectively, which may be coupled to appropriate circuitry and / or devices. 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 as disclosed herein that connects to a pump, and / or circuit 6100 may be attached to an infusion pump, such as a communication module. It may be a module that can be attached. Circuit 6100 may 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 may communicate with the device coupled to the device hub interface using a wireless link and / or short-range communication.

FIG. 92 illustrates a tablet dock 6202, an infusion pump 6204A-6204D, a dock 6206 for receiving an infusion pump 6204A-6204D, and a tablet 6208.
FIG. 18 shows a block diagram of an electronic patient care system 6200 including a. In an alternative embodiment,
Tablet 6208 is integrated within tablet dock 6202. In additional embodiments, docks 6202 and 6206 are integral with each other. In still further 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. The dock 6202 stores memory for caching or storing user interface templates, or a user interface program for displaying a user interface on a display 6210 to a patient-care device, such as an infusion pump 6204A-6204D. Have. The tablet 6208 can be used to direct or verify a prescription using one or more servers 6212 having a drug error reduction system, for example, using a scanner 6214. In some embodiments, the medical IT system 6212 and the dock 6206
Middleware (for example, middleware on the monitoring server 3 in FIG. 1).
The user interface template or user interface program is configured to display aggregated data from the infusion pumps 6204A-6204D on the display 6210 and back up if one or more of the infusion pumps 6204A-6204D fails.・ Work as an alarm. Dock 6 in addition to or as an alternative
206 alerts using one or more internal speakers and / or internal vibration motors if one or more of the infusion pumps 6204A-6204D fails.

Dock 6206 can collect data from infusion pumps 6204A-6204D and can pass the collected data to tablet 6208. Each infusion pump 62
04A to 6204D have respective displays 6216A to 6216D.
The displays 6216A-6216D can be used to adjust the flow rate during the infusion (prescriptions can be programmed through the tablet 6208 while loading certain safety criteria). By adjusting the flow from zero on the user interface displayed on the displays 6216A-6216D, infusion can be initiated without the predetermined safety criteria of the drug error reduction system. The displays 6216A-6216D may also display alarms and alarms, both visually or by audible indication.

The dock 6206 includes a power input module, a medical grade power supply, and a backup battery. The dock 6206 also includes all 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 moving hardware, such as struts, and strut mounting hardware.

During the prescription program, the personal error reduction system settings, for example, certain safety criteria
Received directly from one or more servers 6212. A tablet 6208 can be used to facilitate patient ID and in-drug entry. Communication between the tablet 6208 and the one or more servers 6212 can occur through the dock 6206. Pre-defined safety criteria from the generic error reduction system are cached on the dock 6206 or in one or more of the infusion pumps 6204A-6204D. If the drug error reduction system is not available from the one or more servers 6212, the locally cached predetermined safety criteria from the drug error reduction system will be re-enabled when the network (eg, WiFi) is available. Updated through.

The dock 6206 is connected to the hub dock 6206 and to the infusion pumps 6114A-6114.
D has enough batteries to support 8 hours of operation. Tablet 6110 may or may not have its own battery. In some embodiments, the infusion pumps 6204A-6204D may have sufficient batteries (or other backup power) to support data storage and alert when pulled from the dock 6206. it can. This alert capability and a separate battery also
06.

The UI display of the pump on one of the displays 6216A-6216D may be small. For example, in some embodiments, the displays 6216A-
6216D may be just large enough to allow only the flow rate to be adjusted. This allows the infusion to be started without entering any other information. If the infusion is initiated without tablet 6208, one or more servers 621 can be entered because the patient's ID and / or drug name can be entered before accessing the EMR.
Data from the drug error reduction system from 2 or guardrail is limited. If the infusion is programmed on the tablet and the tablet is subsequently removed from the system, the pump can continue to implement the guardrail feature on 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, circuit 6300 can be used with the pumps or docks described herein. The circuit 6300 may 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 may have its own power supply (not explicitly shown). In some embodiments of the present disclosure, circuit 6300 may provide 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 FIGS. 1, 3, 5, 7, 8, or 9. Additionally or alternatively, circuit 6400 can be used with the docks or pumps described herein. Circuit 6400 can interface with a bus or hub to communicate with and / or provide power to some devices via the 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. The system 6500 can operate without a drug error reduction system from a server. A display 6508 on the infusion pump 6504 can be used to enter medication information and control the infusion rate. In some embodiments, the drug 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. The infusion pump 6504 has the ability to initiate delivery. Emergency modes in a limited generic drug reduction system based on a subset of drugs easily selected from the list can be cached on device hub 6602 and / or infusion pump 6504. The infusion pump 6504 can be started without data from the drug error reduction system.

FIG. 97 illustrates a system 6700 having a tablet 6702 that allows access to an infusion pump 6504 through the tablet 6702 interface. The user interface of the tablet 6702 can 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 connected to the tablet 6702
, Device hub 6602, and / or infusion pump 6504.

Device hub 6602 may have physical or wireless communication to tablet 6702. Device hub 6602 can include a cradle (not shown) for tablet 6702. Tablet 6702 is optionally a device hub 6602.
Can be securely 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 a system 6800 having a tablet 6702 that plugs into the backplane of the dock 6804 (or cradle, in some embodiments). In addition, power module 6804 includes a power input and a spare battery that can be plugged into dock 6806 or integrated. Device hub 6602 is
Master for communication between all other modules and the IT system via one or more servers (not shown). The 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 pumping mechanism and electronics that can implement the pumping mechanism. In one particular embodiment, the device hub 6602 includes a backup power for one or more infusion pumps 3802A-3802C, a processor that collects data and hosts a UI model (eg, a 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 converts all power input modules and AC / DC.
It is coupled to a power module 6804 including a power supply. Power adapter 6506 is optional, and / or AC to DC conversion may be incorporated into power module 6804. The power module 6804 can also include an extended battery to run multiple pump modules. The dock 6806 includes a backplane that connects various components to one another.

FIG. 99 illustrates an electronic circuit 6900 of a device hub, for example, the device hub 6602 of FIG. 96, according to one embodiment of the present disclosure. Additionally or alternatively, the circuit 6
900 can be used with a pump, dock, or communication module as described herein. The circuit 6900 can interface with a bus or hub to communicate with and / or provide power to some devices via the device patient care interface 6916. The circuit 6900 includes various power supplies, user
It has interfaces, communications, sensors, and actuators. The circuit 6900 includes an AC main 6902, DC power 6904, for example, inductive, wireless power 6906, and an external battery connection 6908.

The AC main 6902 may be a direct connection to the main, such as through an AC outlet. The AC main 6902 rectifies the AC signal from the AC main 6902, and
It is 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 provided 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 include a coil that receives a time-varying magnetic field, whereby a voltage across the coil is induced, and the induced AC signal is rectified and smoothed via a smoothing circuit to a DC power input / charging circuit 6910. Are combined.

The 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.
Used to power a tablet (not shown) coupled to 18. The interface 6916 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 directly coupled to the tablet, or is coupled to a tablet user interface. External battery connection 6908 may be an electrical connector (not explicitly shown) adapted to electrically couple with one or more battery cells located within a separate housing of electronic circuit 6900. . The external battery 6908 can complement or replace the primary battery 6914 when the primary battery 6914 fails. The secondary battery 6920 includes a super capacitor 692
It may be 0. In some embodiments, the secondary battery 6920 is in a failure mode where power is otherwise not available, for example, the AC main 6902 has failed and the external battery 6908 has been removed or has failed. Can only be used. Rechargeable battery 69
20 provides sufficient power to the device processor subsystem 6922 to alert via a secondary buzzer 6824.

The circuit includes a gate regulated power supply 6926, a gated independent power supply from a regulated device power supply 6928,
And various power supplies such as a tablet adjustment power supply 6930.

Hub regulated power supply 6926 is used to power the electrical sensors of circuit 6900. For example, the hub regulated power supply 6926 may include the interface processor subsystem 69
32 to provide a voltage.

The conditioning device power supply 6928 can be gated and provide one or more independent regulated voltage sources that are sent to one or more patient care devices coupled to the patient care device interface 6916. Patient care device interface 6
One or more conditioning device power supplies 6928, sent to one or more patient care devices via 916, are monitored by current sensors 6934 and enabled by device processor subsystem 6922. Additionally 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 applies the requested voltage to the patient-care device. The conditioning device power supply 6928 is programmed to supply.

Tablet coordination power supply 6930 provides DC power to the tablet coupled to tablet interface 6918. Additionally or alternatively, circuit 6900 includes:
For use by the tablet's internal power supply (not shown in FIG. 99), the AC mains 69
02 through which an AC signal is passed.

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

In some embodiments of the present disclosure, the LCD touch screen 6942 may be a main display and input method for a patient care device coupled to a patient care device interface 6916 without a display. Additionally or alternatively, LC
D-touch screen 6942 displays detailed information about the hub coupled to patient-care device interface 6916, hub circuitry 6900, and / or the patient-care device. 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 connects to the tablet interface 691
Providing audio guidance to a patient-care device coupled to a patient-care device interface 6916 that does not have a display or alarm when not connected to and / or otherwise not available at 8 Can be. Secondary buzzer 6
924 is a backup buzzer, where the primary speaker 6944 is unavailable or damaged, and / or the interface processor subsystem 693
2 provides security when not available or damaged.

In some embodiments of the present disclosure, hardware buttons 6946 are used for additional safety inputs to deactivate patient care devices that do not have their own display and tablets are not available. Or input can be provided.

Tablet interface 6918 is coupled to interface 6932, and interface processor subsystem 6932 includes
918 can be communicated with the tablet. 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).

The patient care device interface 6916 includes SPI, I2C, RS232, RS
Provide an interface to a patient-care device including a serial interface 6949, which may be 485, or any other serial protocol. The 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.

The patient care device interface 6916 may provide a type, serial number, class, or performance feature of the patient care device and a wired device ID 6955 that facilitates patient care device discovery of locations within the multi-channel cradle, dock, and / or hub. Can be included. The wired device ID 6955 can be used to determine an optimal or preferred communication protocol based on predetermined criteria. Additionally or alternatively, the method of powering 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 "one wire" device. Additionally or alternatively, the patient-care device interface 6916 also provides the patient-care device type, serial number,
Utilizes an RFID interrogator, near field communication, or other wireless communication link to facilitate class or performance characteristics and patient care device discovery at locations within the multi-channel cradle, dock, and / or hub Wireless device ID 6958 to facilitate patient care device discovery.

The patient care device interface 6916 also includes a digital I / O interface 6956. A digital I / O interface 6956 can trigger an actuator, enable pins as part of a safety system, or be used for use with status lights on a hub or cradle. 69
Multiple lines may be included for each patient-care device coupled to 16.

The patient care device also includes a fail-safe line 6957. Either the interface processor subsystem 6932 or the device processor subsystem 6922 supplies a fail-safe line 6957 to the logical OR 6977.
Can be triggered. The output of the logical OR 6977 can be coupled to an electromechanical occlusion device (not shown) coupled to the patient care device interface 6916. In an alternative embodiment, a logical AND is used in place of a logical OR 6977, whereby both the interface processor subsystem 6932 or the device process subsystem 6922 have the "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 the IT system or one or more servers 6967. The 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 provides a circuit 6900 in the home environment.
Facilitates operation of a hub having The 3G / 4G interface 6961 can be used with any portable technology or long-range 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) and the like.

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

The circuit 6900 may also include a transceiver 6963 for RFID, NFC, or other communication protocols for patient authentication, clinician authentication, and / or solution / drug authentication, or to determine the location of a patient care device. Can be prepared.

The circuit 6900 can also include a communication expansion slot 6964, so that future wired or wireless technologies can be modularly inserted into the slot 6964. Slot 6964 can include one or more expansion connectors, and is internal to the externally connectable hub case. Additionally or alternatively, expansion slot 6964 may be a connection to an additional module having multiple functions, such as wireless communication capabilities, wired communication, and the like.

The circuit 6900 can also include hub sensors 6965 such as temperature sensors, pressure sensors, humidity sensors, and accelerometers. Circuit 6900 may also include, for example, a tablet
A vibration motor 6966 for haptic feedback can be provided when alerting or instructing the user to make a selection via a GUI on a tablet coupled to the interface 6918.

FIG. 100 shows a block diagram of a circuit 7000 illustrating one embodiment of a mechanism that can be used in a patient care device such as a pump. That is, the device module interface can be interfaced 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 may interface with a bus or hub to communicate with and / or provide power to some devices via a device module interface. Circuit 7000 also includes various security systems. The circuit 7000 provides power backup power and communication methods to the tablet and IT system. 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. Circuit 7100 may be on a hub. The device module interface can be interfaced with, for example, the infusion pump 7 of FIG. Additionally or alternatively, in some embodiments, the circuit 7100 may be on a hub, communication module, dock, or infusion pump as described herein. 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. Speakers 7106 may also be useful to articulate issues with drop connections to hubs and IT systems. Tablet adjustment power supply
Use of only one external power supply can be facilitated. In some embodiments, the device hub processor subsystem comprises a Bluetooth, WiFi, Bluetooth,
Communicate through the monitoring client interface using low energy, short range 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 above. That is, the circuit 7200 in FIG.
The extended battery 6502 in FIG. 95 may be used, and for example, the system 6500 can be made wearable. The extended batteries 6502 of FIG. 95 may be stackable on one another (eg, the circuit 7200 includes a transceiver such as a SPI or CAN), thereby allowing the extended battery 6502 of FIG.
Can be stacked on top of each other to power the infusion pump 6504. The circuit 7200 can interface into a bus or hub to provide power to some devices (eg, patient care devices) via a device module interface.

FIG. 103 shows a circuit 730 for controlling multiple infusion pumps with flexibility for expansion.
0 shows a block diagram. 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. 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 technologies. In some embodiments, the device module interface (ie, the 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 I / Os are used to add some functionality to the pump cradle as needed. The power input and AC / DC supply 7302 is inside the hub (ie, inside the circuit 7300) and powers the tablet, hub, and one or more infusion pumps. The infusion pump coupled to circuit 7300 may be "independently" secure. An RFID reader 7304 and a barcode reader / camera 7306 are included to authenticate the patient or provider. A communication expansion slot 7308 is included to expand the communication capabilities (eg, authentication and peanuts for location) if other methods are developed.

FIG. 104 illustrates a failsafe line 7402 and two processors 7404, 74.
FIG. 17 shows a circuit 7400 for a hub as described herein with 06. In addition to it,
Or, alternatively, in some embodiments, the circuit 7400 may be used in a dock, infusion pump, and / or communication module, as described herein. The circuit 7400 includes a number of devices (via a device module interface).
For example, it can interface with a bus or hub to communicate with and / or provide power thereto. Processor 7406 may be a security 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 security is provided by fail-safe line 7402. For example, a pulse oximeter monitor can clamp a line if the pulse is rising or too high. That is, the fail-safe 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 a process in the pulse oximeter is in error or faulty. A fail-safe signal can be transmitted to the 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 provide liver feedback when there is an alarm. Circuit 7400 optionally includes two processors 7404, 740 that implement a method for alerting a user when an alarm or alarm is triggered.
6 is provided. A rechargeable battery or supercapacitor 7412 can provide backup power in the event of a power failure. Circuit 7400 includes a pump module, for example,
It may be a communication module and / or a hub for attachment to a cradle.

FIG. 105 illustrates 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, and more particularly, a stackable monitoring client 7502, and a stackable patient-care device, such as a stackable infusion pump 7504A-7504D. The stackable monitoring client 7502 includes a display 7506 that pivots along a pivot axis 7508. Display 7506 may be a touch screen. The stackable monitoring client 7502 can be equipped with a tilt sensor, eg, an accelerometer, to orient the display 7506 so that it is always visible to the user. Similarly, each stackable infusion pump 7504A-7504D has a respective display 75 that is oriented based on its tilt.
For example, the display can include 10A-7510D, and 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. Additionally 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, can include one or more buttons that orient based on tilt, as indicated by internal tilt. For example, FIG.
As shown at 05, button 7512 is shown in an upright position relative to the elongate length of stackable infusion pump 7504A. Referring to FIG. 106, a system 7500
Is shown inclined, whereby the button 7512 is shown in an upright position relative to the length of the stackable infusion pump 7504A. Display 7
Note also that 507 is further pivoted along pivot axis 7508. FIG.
Shown is the display 7506 turned with respect to the monitoring client 7502. FIG.
08 indicates vein holes 7807A to 7807D. FIG. 109 shows an additional range of pivoting along pivot axis 7408. FIG. 110 shows an infusion pump 7504B slidable into a stack.

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

FIG. 113 illustrates that the monitoring client 8106 can include a connector to receive the infusion pump 8102D. The monitoring client 8106 can have an attachable / removable display 8110. FIG. 114 illustrates that another monitoring client 8108 can be stacked on a stackable infusion pump 8102D. The monitoring clients 8106, 8108 can adjust its operation.
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
000.

FIG. 115 shows a stackable infusion pump 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. Sliding connection 850
The 2,8504, 8506, 8508 can include electrical connectors that allow the stackable infusion pumps 8422, 8424 and the 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. Backplane panel 8606 includes a connector 8610 that mates with and engages connector 8612 of 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. FIG. 118 shows a cross-sectional view of the backplane panel 8608 of FIG. 117.

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

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 illustrates a communication module 9000 according to an embodiment of the present disclosure. Communication module 9000 includes connector 9002, LED status ring 9004, 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. 1, 3, 5, 7, or 8. FIG. 122 shows the 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 a short-range interrogator (eg, operating at about 13.56 MHz) at 900M
Shown is an electronic circuit 9300 that enables reading of a Hz UHF RFID tag. The electronic circuit 9300 includes a heterodyne transfer oscillator. The circuit 93000 converts the short-range interrogation signal into an RFID interrogation 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, which allows short-range communication circuits to interrogate RFID tags. Each antenna can be replaced with an RF circuit, allowing the circuit to be used on an interrogator or receiver. Additionally or alternatively, in another embodiment, the electronic circuitry can be arranged to communicate with the near field communication device using a UHF RFID interrogator.

FIGS. 125-127 show some 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, can be placed in front of an RFID or near field interrogator and / or antenna (for transmission and reception). . The resonators 12500 and 12600 have a.
Made using a 0.028 inch thick FR-4 single-sided board with 5 ounces of copper. Trimming can be used to tune the resonator (as shown).

FIG. 127 shows a near-field antenna 12700 for a UHF reader (eg, a 915 MHZ RFID reader) focusing on a near-field pattern with a reader chip. Without a power amplifier, a read 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 wristband 12800 with an RFID tag 12802 attached according to an embodiment of the present disclosure. Since the capacitance is observed when the RFID tag 12802 is attached to the patient's wristband, a split ring resonator (SRR) 12804 can be used that is 0.01 inches away from the patient. Inductive load from the patient's capacitance lowers the frequency of the RFID tag 12802, thereby causing the SRR 1280
4 couples 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 enlarged view of a split ring resonator 12804 for use on the wrist band of FIG. 128.

The RFID tag 12802 of the patient's wristband 12800 is writable. The hub, dock, patient care device, and / or monitoring client may be configured to: (1) treat history such as flow, medication settings, vital signs, etc., (2) use statistics (patient care parameters, patient care parameters, patient care device operating parameters). (3) venous pump flow parameters, ECG parameters, blood pressure parameters, pulse oximeter parameters, CO ₂ capnometer parameters, intravenous bag parameters, and infusion flow total value, (4) an infusion pump, an electrocardiogram signal, blood pressure signal, a pulse oximeter signal, CO ₂ capnometers signals, and patient parameters including at least one course of treatment of the temperature signal, the (5) infusion rate or injection pressure Includes patient treatment parameters such as infusion settings Data related to the patient 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 can be received, such as the pressure of the fluid. In some embodiments, the RFID tag 12802 stores only a predetermined elapsed time (i.e., rolling history) in its memory, e.g., in some particular embodiments, 32 or 56 kilobytes of the RFID tag 12802. Includes 6 to 14 hours history in memory. In yet additional embodiments, the RFID tag 12
802 can include a near field communication receiver for receiving a patient ID and / or data.

FIG. 130 illustrates 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 in place of the air gap. The SRR 13000 has 13 dB to improve the loop antenna by 10 dB.
. It can be located about 8 inches away from the 56MHZ 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 digitally modulated signal. FIG. 131 illustrates an equivalent circuit 13100 for the SRR 13000 of FIG. 130, according to an embodiment of the present disclosure.

FIG. 132 shows 5 that can be displayed on any of the displays disclosed herein.
9 shows an R checklist. FIG. 133 illustrates an occlusion checklist that can be disclosed on any of the displays disclosed herein. FIG. 134 shows a display in operable communication with some infusion pumps, for example, the monitoring client 1 or 11 of FIGS.

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

FIG. 136 illustrates a healthcare device illustrating 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. FIG. 5 shows a display on a portable monitoring client of a provider. FIG. 137 is a diagram showing a display on a healthcare provider's portable monitoring client showing a data entry area for a medication prescription for use with an intravenous infusion pump, according to an embodiment of the present disclosure. FIG. 138 illustrates a healthcare provider's portable monitoring client showing a risk profile associated with the indicated medication and a proposed course of action, as generated by the monitoring client, according to an embodiment of the present disclosure. It is a figure showing the above display. FIG. 139 is a diagram illustrating a display on a healthcare provider's portable monitoring client showing a drug prescription ready to be presented by the referral provider, according to an embodiment of the present disclosure. FIG. 140 illustrates how a monitoring system can display to a referral provider a confirmation that a prescription has been communicated to a pharmacist, according to an embodiment of the present disclosure, on a portable monitoring client of a health care provider. It is a figure showing a display.

Example of a Monitoring Assistance Instruction Entry The functionality of a patient monitoring system can be illustrated by an example where an instruction provider enters a new medication prescription for a patient. In this scenario, the physician can view the list of authorized 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 instructions for the patient 2 are incomplete and the nurse flags the patient for attention, or the monitoring client 1 provides a database or input that the predetermined threshold has been exceeded for a physician notification. When received from the patient monitoring devices 14-17, a warning symbol 27 can be transmitted by the monitoring client 1 to the physician's device 11.

After the physician selects a patient for further review, a display as shown in FIG. 135 can be communicated to the physician's device 11. The physician monitors the monitor 1 to which the patient is connected.
The user selectable data resulting from 4-17 can be viewed 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 available infusion pump 7 for use with the patient 2. In the scenario shown in FIG. 136, the physician can press the 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 that allows a physician to remotely order medication. 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 22 and the monitoring server 3 is accessible by the monitoring client 1. The “PDR” button 29 may indicate a physician's one touch access to the in-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 dose 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 enters a prescription. The monitoring client 1 sends the new medicine 28 to E
It can be compared to a list of patients' existing drugs and drug allergies downloaded from HR19. The monitoring server 3 preferably adds appropriate patient-specific data in the monitoring client 1, which is programmed to retrieve this information after a new medication order has been entered. The monitoring client 1 can be programmed to request from the monitoring server 3 a list of significant side effects and drug interactions associated with each patient's medication and the new medication 28. The server 3 can then access the pharmacy database 22 or the external database 9 for this information. If a potential drug interaction or side effect common to the existing or new drug 28 is detected, the monitoring client 1 issues an alert 32 and communicates this to the instructing physician, as shown in FIG. Can be. If the potential side effect is due to a common effect of both the new drug and the existing drug, the monitoring client 1 classifies this as a potential additional side effect and proposes to reduce the initial drug dose by, for example, 50%. 33 can be emitted.

As shown in FIG. 139, the instructing physician has the option to accept proposal 33 or edit the suggested dosage to another value. In any case, monitoring client 1
Will report the warning 32 and any corrections 33 made by the physician,
The report can be generated and recorded with the option of further editing before the physician records or enters the patient's EHR 19.

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

After the prepared drug 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 uses a barcode reader, such as a barcode reader, that a nurse can use to verify that the identification code on the medication bag matches the identity of the prescribed patient 2 Of input devices. If the identification information matches the information entered into the monitoring client 1 by the pharmacist, the nurse can leave the device 1, 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,
(Which can be calculated by the processor in the monitoring client 1) to the nurse. 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 illustrates a device 14100 formed by a microinfusion pump 14104 coupled to an adapter 14102, according to an embodiment of the present disclosure. Adapter 14102 includes a touch screen 14106 that can be used to control the operation of microinfusion pump 14104. Microinfusion pump 14104 pumps fluid from tube 14108.

The adapter 14102 includes the monitoring client 1 of FIGS. 3, 5, 7, and 8, the monitoring client 902 of FIG. 9, the dock 102 or 104 of FIG. 1, the dock 102 or 104 of FIG.
Dock 502, hub 802 of FIG. 8, dock 804, 806 or 102 of FIG. 8, FIG.
3, 5, or 7 dongles 133 or any of the patient-care devices 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. Adapter 14102 may include an electrical connector on the underside to interface with patient care device dock 104. For example, adapter 14102 can include a connector, whereby adapter 14102 can be docked.

The touch screen 4106 can be used to set an infusion rate, bolus volume, or extended bolus settings. Additionally or alternatively, the touch screen 4
106 can be used to estimate the amount of liquid drug remaining in the microinfusion pump 14104.

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

Wireless hub device 14200 includes a main body 14 coupled to a touch screen 14204.
02, and a holder 14206. Wireless hub device 1420 may communicate data from another patient care device to the patient care device to a monitoring client, another hub, dock, etc. For example, wireless hub device 14200 can communicate data with a patient-care device and relay information via another wireless protocol to a monitoring client, another hub, dock, etc., according to a first wireless protocol. For example, wireless hub device 14200 can communicate with a patient-care device via Bluetooth and relay data to a dock (eg, dock 104 of FIG. 1) via near field communication. In this particular embodiment, holder 14206 can be shaped such that holder 14206 is in a dock, for example, 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 are shown in front perspective view. The dock 14314 is connected to the column 14312. The adapter 14316 is connected to the dock 14314 and the patient care devices 14304, 14306, 14
An electrical connection is provided between 308 and 14310. That is, the adapter 14316
Changes can be made based on the type of patient care device 14304, 14306, 14308, and 14310 used.

FIG. 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, the patient-care device 14306 slides on the adapter 14316 via the rails 14318 and 14320. The infusion pump 14304 can be snap-fit onto the spring loaded flange 14322. The lever on the back side of the adapter 14316 can be pulled to pull the flange away from the infusion pump 14304.

FIG. 145 illustrates 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 the flange 14322 and thereby the infusion pump 143
04 snaps into place in adapter 14316.

FIG. 146 illustrates a top view of the electronic patient care system 14300 of FIG. 143 according to an embodiment of the present disclosure. The dock 14314 has two adapters 14602 and 14316
Is joined to. The dock 14314 is connected to the column 14312 via the 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, docks / 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). A central server 14702 may provide software updates, firmware updates, and / or configuration files. For example, central server 14702 may include hospital server 14704, dock / hub 1470
7, 14708 and 14709, dock / hub 14707, 14708 and 1470
9 or dock / hub 1470 based on device ID
Updates can be provided to monitoring clients operatively communicating with 7,14708 and 14709. Additionally or alternatively, the central server 14702 may provide software for downloading to a sandbox as described below (see FIG. 148). Additionally or alternatively, the central server 14702
Can receive usage statistics (patient care parameters, patient treatment parameters, patient care device operating parameters, docks, diagnostic information from hubs and monitoring clients, etc.). The central server 14702 can record data in a database, for example, a SQL database, a related database, and the like.

Central server client 14703, as described above, central server 14702
Monitor the operation of the central server 14702, view log files therein,
Alternatively, data on the effectiveness of the drug can be viewed. In some embodiments of the present disclosure, the central server client 1403 is a nurse station software that allows a nurse to monitor a dock / hub, patient, and / or patient care device.

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

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

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

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

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

FIG. 148 illustrates a block diagram of an electronic patient care system 14802, according to an embodiment of the present disclosure. System 14802 includes an enterprise server system 14804, an application store 14806, a device manager 14808, one or more hubs 14808.
26, one or more tablets 14810, one or more infusion pumps 14814,
And one or more wireless sensors 14816. Tablet / dock / hub 14812, dock / hub 14816 and wireless sensor 14816, dock / hub 1
4812 and infusion pump 14814, 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 may be WiFi, Ethernet, Bluetooth, USB, 3G
Self-describing data, HL7, TC using 4G, HALO, SOAP, XML data
This can be done using P / IP, Bluetooth templates, dedicated and / or non-dedicated communication links.

The enterprise server system 14804 may, in some embodiments, include a CMMS database 14832, a CPOE 14834, an EMR 14836, and / or a billing server 148.
38 can be provided. The company 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, which may include one or more patient-care devices, one or more sensors,
One or more infusion pumps 14814 can be controlled or programmed to provide patient diagnostics and the like. The application store 14806 can provide encrypted communication to facilitate the downloading of one or more of the device applications 14850-14853.

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

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

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

The patient care device, for example, the infusion pump 14814, may
Close to the hub 14812, for example, to pair the device, pass configuration data, or the infusion pump 14 to the patient with which the dock / hub 14812 is associated.
When setting 814 parameters, short-range communication (N
FC). After the NFC communication, the infusion pump 14814 switches to dock / hub 1
4812 may be communicated wirelessly or over a wireless link. For example, infusion pump 14814 can be in intimate contact (or contact) with dock / hub 14812, and use NFC communication to pair infusion pump 14814 with dock / hub 14812 using a Bluetooth communication link.

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

For example, the dock / hub identifies the infusion pump 14814 by serial number, and the device / application 14850 from the application store.
12 (e.g., device application 14820). The device application 14820-14824 may control and / or communicate with the infusion pump 14814 to relay information about the infusion pump 14814 to the tablet 14810 for display (eg, via XML). . Additionally or alternatively, one or more of the device applications 14820-14824 may display data from the device and combine data from several sources and the like using complex heuristics. it can. The 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 can restrict or prevent 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 disrupt the DERS 14826, local policy 14828 by the device application 14820, or to prevent the 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 execution of the sandbox via 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).

Sandbox 14818 may control the initiation of one or more of device applications 14820-14824. For example, sandbox 14818
The device application 14820-14824 specified to run does not have any broken links and the sandbox 1481
Rules or links (eg, dynamic link library calls) can be checked to ensure that predetermined criteria controlled by 8 are met.
For example, the sandbox 14818 may indicate that all references from the device application 14850 to a shared library in the software of the dock / hub 14812 are in a particular "safe" shared library, a particular function or variable in the library. Can be checked and that the variables and data types requested by the device application 14820-14824 and communicated by the device application 14820-14824 match or are present 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
If 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 This allows the caregiver to override a particular alarm condition, address a number of alarm causes, and / or evaluate the condition of the patient.

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

In some embodiments of the present disclosure, the dock / hub 14812 comprises two processors, whereby one of the processors runs a sandbox 14818 and another processor has one of the device applications 14820-14824. Operating system that controls the allocation of resources used by the sandbox 14818 via
Run the system.

In some embodiments of the present disclosure, the dock / hub 14812 comprises two processors, whereby one of the processors runs a sandbox 14818 and another processor has one of the device applications 14820-14824. Implements a watchdog function that ensures the safe operation of the resources used by the sandbox 14818 via.

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

In some embodiments of the present disclosure, dock / hub 14812 comprises one or more processors, each having one or more cores, so that at least one process control block runs sandbox 14818. , At least another process control block executes an operating system that controls the 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 the patient-care device and upload the data to a database 14830 (eg, a cloud-based database), where the data can be transmitted to a hospital or hospital system within a disease epidemic. It may be real-time data collected at the national level to facilitate discovery, resource planning, and deployment planning.

FIG. 149 illustrates a block diagram 14900 of the bedside portion of the electronic patient system of FIG. 147 and / or 148, according to an embodiment of the present disclosure. FIG. 14900 shows a monitoring client 14902 (which may be a tablet 148120), a monitoring client 1
The 4902 includes a monitoring client adapter 14904 that can interface with the dock / hub 14906 (which may be the dock / hub 14812), and a number of infusion pumps 14910. Dock / Hub 14906 is compatible with WiFi,
Zigbee, Bluetooth, mesh network, point to point
An infusion pump 14910 can be communicated, such as via a protocol (eg, based on WiFi). The infusion pump 14910 can receive power directly through an AC outlet 14908 (not shown) and / or directly from the dock / hub 14906. Dock / hub 14906 provides wireless sensor 14814 (wireless or wired) and U
It is connected to the SB sensor 14912 via a USB cable.

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

FIG. 150 illustrates 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 security processor 15002 (either or both may be a processor, a microprocessor, or a microcontroller, such as a Snapdragon processor).

The safety processor 15002 is coupled to a speaker driver 15011 that controls the 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 a Bluetooth, WiFi, CAN bus, or SPI communication link.

Safety processor 15002 is coupled to a 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 the current to a patient-care device coupled to device connector 15014.

Safety processor 15002 also enables switch 1502 to enable / disable 5 volt power to the patient-care device coupled via device connector 15014.
Tied to 0. The 5V signal to the patient care device is received from a primary battery cell 15018 and / or a voltage regulator 15010 that receives its power from a battery charger 15009. The battery charger comprises 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,
Button 15028 and near field communication transceiver 15030 are coupled.

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

FIG. 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
The UI / security processor 15102 controls the P.04 and records data in the nonvolatile memory 15105. The UI / safety processor 15102 has a device connector 1
It communicates with the hub / dock via a CAN bus coupled to 5108. In some embodiments, the real-time processor 151102 and / or the UI / security processor 1
5102 communicates with the hub / dock via device connector 15108 using a Bluetooth, wireless, or wired communication link. The UI / security processor 15102 can include an image processing library for processing images from the camera. Additionally or alternatively, UI / safety processor 15102 may include a library for displaying a GUI interface on pump display 15104 (which may 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,
Button 15120 and status light 15112 are coupled. Safety processor 151
02 can provide a watchdog function to a real-time processor 15103 (which may be a processor, microprocessor, or microcontroller, eg, a Snapdragon processor) and enable the motor drive 15107.

A real-time processor 15103 (one or both of which may be a processor, a microprocessor, or a microcontroller, eg, 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). The real-time processor 15103 loads the pump calibration data from the non-volatile memory 15122. Non-volatile memory 15122 and / or non-volatile memory 15105 may be an SD card and / or an RFID tag.

The real-time processor 15103 includes a motor current sensor 15109, a motor housing temperature 15110, a closing pressure sensor 15111, and a cam shaft position sensor 1511.
2. Receive data regarding the infusion pump from cam follower position sensor 1513 and / or accelerometer 15114.

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

FIG. 152 illustrates a diagram for use in the infusion pump circuit of FIG. 151 according to an embodiment of the present disclosure;
FIG. 18 is a block diagram 1500 illustrating a sensor coupled to an infusion pump mechanism. The 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, a Hall effect sensor 15211 for the outlet valve, and a Hall effect sensor 15 for the plunger position.
212 and 15213, a Hall effect sensor 15214 for the inlet valve, and a 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 variances. In addition, while some embodiments of the present disclosure are shown in the drawings and / or discussed herein, the disclosure is within the skill of the art and the specification is so broad that it can be read. The disclosure is not intended to be so limited. Therefore, the above description should not be construed as limiting, but merely as exemplifications of particular embodiments. Also, those skilled in the art will envision other variations within the scope and spirit of the appended claims. Other elements, steps, methods, and techniques not substantially different from those described above and / or in the appended claims are also intended to be within the scope of the disclosure.

The embodiments illustrated in the drawings are provided only to demonstrate certain examples of the disclosure.
Moreover, the drawings described are merely illustrative and not restrictive. In the drawings, the size of some of the elements may be exaggerated and not drawn on scale for illustrative purposes. In addition, elements shown in the figures having the same number may be the same element or similar elements depending on the content.

Where the term "comprising" is used in the present description and claims, it does not exclude other elements or steps. Indefinite or definite articles are used when referring to a singular noun, for example, "a", "an", or "the", but also includes the plural of that noun unless specifically stated otherwise. . Thus, the term "comprising" should not be interpreted as being restricted to the items listed below; it does not exclude other elements or steps. Thus, the scope of the expression "device with items A and B" should not be limited to devices consisting of components A and B alone. Such a representation simply means in the context of the present invention that the relevant components of the device are A and B.

Furthermore, terms such as “first”, “second”, “third” are used to distinguish between similar elements, whether used in the specification or the claims. And are not necessarily given to describe in a sequential or chronological order. The terms so used are interchangeable in the appropriate context (unless explicitly disclosed otherwise), and embodiments of the invention described herein may be described or illustrated herein. It is operable in an order and / or arrangement other than that described.
A first aspect of the present invention provides:
An electronic patient care system,
A hub configured to monitor a patient-care device, wherein the hub comprises:
An operating system component configured to access at least one of the hub hardware resources and the hub 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 identify the patient-care device and execute an application to monitor the patient-care device;
The hub downloads at least one treatment parameter from the electronic medical record;
Configured to program the patient-care device with the at least one treatment parameter;
The hub executes the application in the sandbox component so that the application communicates through the sandbox component to the at least one of the hardware resources and the software resources.
Access one
The system wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource.
A second aspect of the present invention provides:
The system of claim 1, wherein the hub is further configured to control the patient-care device.
A third aspect of the present invention provides:
The first wherein 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. 10 is a system according to an aspect.
According to a fourth aspect of the present invention,
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.
1 is a system according to a first aspect.
According to a fifth aspect of the present invention,
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.
According to a sixth aspect of the present invention,
The system of claim 1, wherein the hardware resource is one of a disk drive, a memory, a buzzer, a microphone, a speaker, and a camera.
According to a seventh aspect of the present invention,
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. .
According to an eighth aspect of the present invention,
An electronic patient care system,
A hub configured to monitor a patient-care device, wherein the hub comprises:
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 identify the patient-care device and execute an application to monitor the patient-care device;
The hub downloads at least one treatment parameter from the electronic medical record;
Configured to program the patient-care device with the at least one treatment parameter;
The hub executes the application in the sandbox component so that the application communicates through the sandbox component to the at least one of the hardware resources and the software resources.
Access one
The system wherein the sandbox component is configured to preferentially access the at least one of the hardware resource and the software resource.
According to a ninth aspect of the present invention,
The system according to the eighth aspect, wherein the hub is further configured to control the patient-care device.
According to a tenth aspect of the present invention,
An eighth aspect wherein 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. 10 is a system according to an aspect.
An eleventh aspect of the present invention provides:
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 according to an eighth aspect.
According to a twelfth aspect of the present invention,
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.
According to a thirteenth aspect of the present invention,
The system of claim 8, wherein the hardware resource is one of a disk drive, a memory, a buzzer, a microphone, a speaker, and a camera.
According to a fourteenth aspect of the present invention,
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. .
According to a fifteenth aspect of the present invention,
An electronic patient care system,
A monitoring client configured to monitor the patient-care device, wherein the monitoring client comprises:
An operating system component configured to access at least one of the monitoring client hardware resources and the monitoring client software resources;
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 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 monitoring client executes the application in the sandbox component so that the application accesses the at least one of the hardware and software resources 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.
According to a sixteenth aspect of the present invention,
The system of claim 15, wherein the monitoring client is further configured to control the patient-care device.
According to a seventeenth aspect of the present invention,
A fifteenth aspect, wherein 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. 10 is a system according to an aspect.
An eighteenth aspect of the present invention provides:
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.
According to a nineteenth aspect of the present invention,
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.
According to a twentieth aspect of the present invention,
The system of claim 15, wherein the hardware resource is one of a disk drive, a memory, a buzzer, a microphone, a speaker, and a camera.
According to a twenty-first aspect of the present invention,
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. .
A twenty-second aspect of the present invention provides:
An electronic patient care system,
A monitoring client configured to monitor the patient-care device , wherein the monitoring client comprises:
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 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 monitoring client executes the application in the sandbox component so that the application accesses the at least one of the hardware and software resources 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.
According to a twenty-third aspect of the present invention,
23. The system of claim 22, wherein the monitoring client is further configured to control the patient-care device.
A twenty-fourth aspect of the present invention provides:
The twenty-second aspect, wherein 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. 10 is a system according to an aspect.
A twenty-fifth aspect of the present invention provides:
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.
According to a twenty-sixth aspect of the present invention,
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.
According to a twenty-seventh aspect of the present invention,
23. The system according to the twenty-second aspect, wherein the hardware resource is one of a disk drive, a memory, a buzzer, a microphone, a speaker, and a camera.
A twenty-eighth aspect of the present invention provides:
23. 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. .
A twenty-ninth aspect of the present invention provides:
An electronic patient care system,
A hub configured to communicate with the electronic medical record;
With a patient care device,
The hub is configured to identify a patient and the patient-care device;
The hub downloads at least one treatment parameter from the electronic medical record;
Configured to program the patient-care device with the at least one treatment parameter;
A system wherein a sandbox component is configured to preferentially access said at least one of a hardware resource and a software resource.
According to a thirtieth aspect of the present invention,
The hub reads RFID using an RFID interrogator, voice using voice recognition software coupled using a microphone, face using facial recognition software coupled to a camera, biometric reading. 30. The system according to the twenty-ninth aspect, wherein the patient is identified according to at least one of a biometric parameter, identification information, and barcode reading by a barcode reader.
A thirty-first aspect of the present invention provides:
An electronic patient care system,
A monitoring client configured to communicate with the electronic medical record;
With 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 downloads the patient care device with the at least one treatment parameter. Is configured to be programmed
A system wherein a sandbox component is configured to preferentially access said at least one of a hardware resource and a software resource.
A thirty-second aspect of the present invention provides:
Said surveillance client reading RFID using an RFID interrogator, voice using voice 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 the following: a biometric parameter, identification information, and a barcode read by a barcode reader.
A thirty-third aspect of the present invention provides:
An electronic patient care system,
A hub configured to monitor a patient-care device, wherein the hub comprises:
A sandbox component configured to control the access to the at least one of the hardware resource and the software resource;
The hub is configured to identify the patient-care device, the hub download at least one treatment parameter from the electronic medical record, and program the patient-care device with the at least one treatment parameter. ,
Further configured to execute an application to monitor the patient-care device;
The hub executes the application in the sandbox component so that the application communicates through the sandbox component with the at least one of the hardware resources and the software resources.
Access one
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 is configured to prioritize the source of the request and generate a priority list that causes the alarm. Is the system.
A thirty-fourth aspect of the present invention provides:
34. The system of claim 33, wherein the hub is further configured to control the patient-care device.
A thirty-fifth aspect of the present invention provides:
33. The thirty-third, wherein 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. 10 is a system according to an aspect.
A thirty-sixth aspect of the present invention provides:
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 according to the aspect.
A thirty-seventh aspect of the present invention provides:
The system of claim 33, wherein the hardware resource is one of a disk drive, memory, buzzer, microphone, speaker, and camera.
A thirty-eighth aspect of the present invention provides:
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. .

Claims (26)

An electronic patient care system,
A patient care device configured to treat the patient;
A wearable system monitor configured to be dockable;
A dock configured to be worn by the patient and configured to receive the wearable system monitor;
The wearable system monitor comprises:
Start a timer when the wearable system monitor is undocked,
After a predetermined time has elapsed after the timer has been started, stop treatment by the patient care device,
Pairing the wearable system monitor with another patient care device,
Re-attaching the wearable system monitor to the wearable dock,
Identifying and authenticating the wearable dock using the wearable system monitor;
After the wearable system monitor is docked in the wearable dock, resume treatment of the patient-care device, wherein the wearable dock is identified by the wearable system monitor, and the wearable dock is Certified by the wearable system monitor,
The electronic patient care system.   The system of claim 1, wherein the wearable system monitor is configured to identify a caregiver using a voice recognizer.   The system of claim 1, wherein the wearable system monitor is configured to identify a caregiver using a face recognizer.   The system of claim 1, wherein the wearable system monitor is configured to identify a caregiver using a barcode reader.   The system of claim 1, wherein the wearable system monitor is configured to identify a caregiver using an RFID reader.   The system of claim 1, wherein the wearable system monitor is configured to identify a patient using a speech recognizer.   The system of claim 1, wherein the wearable system monitor is configured to identify a patient using a face recognizer.   The system of claim 1, wherein the wearable system monitor is configured to identify a patient using a barcode reader.   The system of claim 1, wherein the wearable system monitor is configured to identify a patient using an RFID reader.   The system of claim 1, wherein the wearable system monitor is configured to determine whether a caregiver is authorized to pair the wearable system monitor.   The system of claim 1, further configured to provide a list of patient care devices that can be paired with the wearable system monitor.   The system of claim 1, further configured to instruct the patient-care device and other patient-care devices to treat with an updated setting. An electronic patient care system,
A first medical sensor coupled to the patient and configured to measure a patient care parameter of the patient;
A medical device configured to operably receive a measured patient care parameter from the medical sensor, wherein the medical device is configured to communicate the measured patient care parameter; and A medical device configured to treat a medical device;
A server in operable communication with the medical device to receive the measured patient care parameters for recording therein;
A wearable dock; and a wearable system monitor dockable to the wearable dock;
The wearable system monitor comprises:
Identify caregivers,
Start a timer when the wearable system monitor is undocked,
When a predetermined time has elapsed without the wearable system monitor being docked to the wearable dock, stopping treatment of the medical device;
Identify the patient,
Allowing a caregiver to pair the wearable system monitor, pairing the wearable system monitor with the medical device,
Re-attaching the wearable system monitor to the wearable dock,
Identifying and authenticating the wearable dock, and resuming treatment of the medical device after the wearable system monitor has been docked to the wearable dock, and the wearable dock can be re-established by the wearable system monitor. Identified and authenticated,
The electronic patient care system.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a caregiver using a voice recognizer.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a caregiver using a face recognizer.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a caregiver using a barcode reader.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a caregiver using an RFID reader.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a patient using a speech recognizer.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a patient using a face recognizer.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a patient using a barcode reader.   14. The system of claim 13, wherein the wearable system monitor is configured to identify a patient using an RFID reader.   14. The system of claim 13, wherein the wearable system monitor is configured to determine whether a caregiver is authorized to pair the wearable system monitor.   14. The system of claim 13, wherein the system is configured to provide a list of medical devices that can be paired with the wearable system monitor.   14. The system of claim 13, wherein the wearable system monitor is configured to instruct a medical device to treat the patient with updated settings.   The electronic patient care system of claim 1 substantially as described or exemplified in the present application.   14. The electronic patient care system of claim 13, substantially as described or exemplified in the present application.

Images