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

Abstract

system (800) for electronic patient care includes a monitoring device such as a client (1) or hub (802). The monitoring device (1, 802) is configured to monitor a patient-care device (14, 15, 16, 17, 35, 148). The system (800) also includes a sandbox secure computing environment configured to control access to at least one of a hardware resource and a software resource. The monitoring device (1, 802) executes an application within the sandbox component such that the application accesses the at least one of the hardware resource and the software resource through the sandbox component. The monitoring device (1, 802) may be further configured to control the patient-care device (14, 15, 16, 17, 35, 148). The monitoring device (1, 802) may be further configured to receive an identification from the patient-care device (14, 15, 16, 17, 35, 148) and download the application from a server (3) associated with the identification. The monitoring device (1, 802) may be further configured to receive an identification from the patient-care device (14, 15, 16, 17, 35, 148) and update the application from a server (3) associated with the identification. rol access to at least one of a hardware resource and a software resource. The monitoring device (1, 802) executes an application within the sandbox component such that the application accesses the at least one of the hardware resource and the software resource through the sandbox component. The monitoring device (1, 802) may be further configured to control the patient-care device (14, 15, 16, 17, 35, 148). The monitoring device (1, 802) may be further configured to receive an identification from the patient-care device (14, 15, 16, 17, 35, 148) and download the application from a server (3) associated with the identification. The monitoring device (1, 802) may be further configured to receive an identification from the patient-care device (14, 15, 16, 17, 35, 148) and update the application from a server (3) associated with the identification.

Description

Patents Form No. 5N.Z. No. 752012d out of New Zealand PatentApplication No. 733443, itself divided out ofNZ 716502, itself divided out of NZ 626636NEW ZEALANDPatents Act 1953TE SPECIFICATION, METHOD, AND APPARATUS FOR ELECTRONIC PATIENT CAREWe, DEKA PRODUCTS LIMITED PARTNERSHIP, a company of the United States of America, of340 Commercial Street, Manchester, NH 03101, UNITED STATES OF AMERICA, do hereby declare theinvention, for which we pray that a patent may be granted to us, and the method by which it is to beperformed, to be particularly described in and by the following statement:-(followed by page 1A)SYSTEM, METHOD, AND APPARATUS FOR ELECTRONIC PATIENT CARECROSS-REFERENCE TO D APPLICATIONSThe present application is a divisional application divided out of New ZealandPatent Application No. 733443, itself divided out of NZ 716502, itself divided out ofApplication No. 626636, and corresponds to a uation-in-Part of U.S. PatentApplication No. 13/011,543, filed January 21, 2011 and ed Electronic PatientMonitoring System (Attorney Docket No. 152, published as US 20110313789), whichclaims priority to U.S. Provisional Patent Application No. 61/297,544, filed January22, 2010 and entitled Electronic Order Intermediation System for a Medical Facility(Attorney Docket No. H53), all of which are hereby incorporated herein by referencein their entireties.

BACKGROUNDField of DisclosureThe present disclosure relates to t care. More ularly, the presentdisclosure relates to a , method, and apparatus for electronic patient care.

Description of Related ArtProviding patient care in a hospital generally necessitates the interaction ofnumerous professionals and caregivers (e.g., doctors, nurses, pharmacists,technicians, nurse practitioners, etc.) and any number of medical devices/systemsneeded for treatment of a given patient. Despite the existence of systems intendedto facilitate the care process, such as those incorporating electronic medical s) and computerized provider order entry (“CPOE”), the s of providingcomprehensive care to patients ing ordering and delivering medical treatments,such as medications, is associated with a number of non-trivial issues.

SUMMARYIn one aspect, the ion provides a system for electronic patient-care,comprising: a monitoring client configured to communicate with electronic medicals; and a patient-care device; n the monitoring client is configured toidentify a patient and the patient-care device, and wherein the monitoring client isconfigured to download at least one treatment parameter from the electronic medical(followed by page 1B)records and program the patient-care device with the at least one treatmentparameter.

Preferably, the monitoring client fies the patient in accordance with atleast one of reading an RFID tag using an RFID interrogator, a voice using voicerecognition software coupled using a microphone, a face using ecognitionsoftware coupled to a camera, a biometric parameter of biometric read, anidentification, a barcode read by a barcode reader.

In an exemplary embodiment involving the ng and stration ofmedications, the electronic patient care system may comprise a first data-gatheringmodule (e.g., a monitoring client) and a second order-input module (e.g., a fixed orportable monitoring client) having a user interface for transmitting an order orreceiving patient-related information. The first module may be configured to receiveand store measured parameters pertaining to a patient’s current condition (i.e.,patient-condition parameters), such as blood pressure, heart rate, heart rhythm,temperature, ation, atory rate, or ventilation, for example. The firstmodule may also be configured to receive information about pre-existing(followed by page 2)parameters related to the patient from a first database (e.g.. an EHR secontaining information about the patient). for example. including t-conditionparameters such as medication allergies or ivities. other currentlyadministered medications presently in the patient's tissue. age, weight. height.kidney. or liver function. The first module may also be configured to obtainmedication information about the ordered medication and/or pre-existingmedications from a second database (e.g.. a drug information database). such asknown medication interactions. effects of the medication or isting medicationson blood pressure. pulse, heart rhythm, or respirations. for e. The firstmodule can be configured to compare the t's currently-measured. patient-condition parameters and received. pre-existing. patient-condition parameters withknown normal ranges. and create a table of patient-condition parameters found tobe outside the normal ranges. The first module may then compare the table ofpatient-condition parameters with a table of corresponding parameters obtainedfrom the drug information database. If a match is found to exist between the tableof patient-condition ters and the table of corresponding parameters. the firstmodule may then retrieve one or more pre-entered and stored messages fortransmission to the second (order input) module. These es may include. forexample. gs to a user of the second module that are appropriate for theparticular medication ordered. the patient's pre-existing medications. and thepatient's current and pre—existing medical condition. Optionally. further repetitionsof warnings may be avoided once a warning has been ed by the secondmodule. and the warning has been acknowledged by the user of the secondmodule through an input signal from the user interface.

In other embodiments. the electronic t-care system may provide theuser with editable default values derived from standard dosing and administrationines obtained from the drug information database. and can alert the user tomodifications that may be indicated based on the patient's current and pre-existingmedical condition. allergies. existing medications. or other patient-conditionparameters. The electronic patient-care system preferably minimizes the amount oftyped input from a user.

In other embodiments. the first module or other s of the electronicpatient-care system may also be used to identify ordered medications to bedelivered to the patient's bedside (through the use of. for example. bar codes andreaders. or RFID tags and scanners). and verify that the appropriate tionand dosage are being prepared and delivered to the patient. In an embodiment.the first module may also interact through a wired or wireless communications linkwith a patient-care device that administers treatment. such as an infusion pump orpill dispenser. In the case of an infusion pump. the first module or anotherconnected module may provide the infusion pump with patient-treatmentparameters. such as on settings ing an infusion rate or infusionpressure. and receive from it various operating parameters. such for example. thepresence of air in the infusion line, the amount of solution remaining in an IV bag towhich it is connected. or the re of fluid in the infusion line. If the operatingparameters are found to be abnormal. the first module may be configured torespond by signaling the infusion pump to halt infusion. respond by ing amechanical occlude to occlude the IV line. alter the infusion rate. andlor alert ahealth care provider or others of the abnormality. either directly through an alarmorated in the first module, or by transmission of an alarm to the secondmodule. In a further embodiment. the first module may also be configured tocommunicate with various patient-care devices used to monitor a patient's ionand determine patient-condition parameters. such as. for e. blood pressuremonitors. ECG monitors. pulse oximetry monitors. temperature monitors. and thelike. The various parameters monitored by be monitored andIor logged by a mobiledevice andlor within an EMR. In some cases. the first module can be programmedto emit an alert to the patient or other s if the monitored patient-conditionparameters fall outside a predetermined range. In some embodiments. the firstmodule can transmit a signal to a monitoring client to t an unscheduledmeasurement by the patient-care device to obtain another patient-conditionparameter. The first module may communicate with s health care providersat various locations. and in an embodiment may be able to notify the patient towhom it is assigned of an abnormality. and recommend corrective action through.for example an e alert or ed message.

In one embodiment. a system for preparing a microinfusion pump includes amonitoring . a pharmacy computer. a compounding robot. a microinfusionpump. and a data download device. The monitoring client is configured tocommunicate a prescription order via a user interface. The pharmacy computer inis operative communication with the monitoring client to receive the prescriptionorder. The compounding robot is configured to prepare the prescription into atleast one liquid corresponding to the prescription order. The microinfusion pump isconfigured to receive the at least one liquid corresponding to the prescription order.

The data download device is configured to download the prescription order into amemory of the microinfusion pump.

In some embodiments. the compounding robot fills the microinfusion pumpwith the at least one . The compounding robot may be in ivecommunication with the data download device. and the nding robot mayinstruct the data download device to download the iption order into thememory of the microinfusion pump. The data ad device may receive theprescription order from the compounding robot and/or the pharmacy computer. Insome embodiments. the compounding robot receives the prescription order fromthe pharmacy computer.

In one ment of the present disclosure. a system includes a hub. Thehub is configured to monitor a patient-care device. The hub includes an operatingsystem (which may be embodied as a processor executing software) and asandbox component (which may be embodied as a processor executing software).

The operating system ent is configured to access at least one of ahardware resource of the hub and a software resource of the hub.

The sandbox component is ured to control the access to the at leastone of the hardware resource and the software resource. The hub is furtherconfigured to identify the patient-care device and execute an application to monitorthe patient-care device. The hub may execute the application within the sandboxcomponent such that the application accesses the at least one of the hardwareresource and the re resource through the x component.

The hub may be further configured to control the patient-care device. Thepatient-care device may be one or more of an infusion pump. a pill ser. amicroinfusion pump. an ECG monitor. a blood pressure monitor. a pulse oximeter, aCO2 capometer. an intravenous bag. and/or a drip-flow meter.

The hub may be configured to receive an identification (e.g., a serial number.code (encrypted or unencrypted). or other identifying value) from the t-caredevice and ad the application from a server associated with theidentification. The hub may also be configured to receive an identification from thepatient-care device and update the application from a server ated with theidentification.

The hardware resource may be a disk drive. memory. a buzzard. amicrophone. a speaker and a . The software resource may be of avariable. a secure data object. a secure variable. a secured API. an API. and asoftware representation of a hardware component.

In yet r embodiment, a system for electronic t care includeshub. The hub is configured to monitor a patient-care device. The sandbox may beconfigured to control access to at least one of a hardware resource and a softwareresource. The hub is further configured to identify the patient-care device andexecute an ation to monitor the patient-care device. The hub executes theapplication within the sandbox component such that the application accesses the atleast one of the hardware resource and the software resource through the sandboxcomponent. The hub may be further red to l the patient-care device.

The hub may be further configured to receive an identification from the patient-caredevice and download the application from a server associated with theidentification. The hub may be further configured to receive an identification fromthe patient-care device and update the application from a server associated withthe identification.

The hardware ce may be a disk drive. memory, a buzzard. amicrophone. a speaker and a camera. The software resource may be of avariable. a secure data , a secure variable, a secured API. an API. and asoftware representation of a hardware component.

In yet another embodiment. a system for electronic patient care includesmonitoring client. The monitoring client is configured to r a patient-caredevice. The monitoring client includes an operating system component configuredto access at least one of a hardware resource of the ring client and asoftware resource of the monitoring client. The sandbox component is configuredto control the access to the at least one of a hardware resource and the softwareresource. The monitoring client may be further configured to identify the patient-care device and execute an ation to monitor the patient-care device. Themonitoring client executes the application within the sandbox component such thatthe ation accesses the at least one of the hardware resource and thesoftware resource through the sandbox component. The monitoring client is rconfigured to control the patient-care device.

The patient-care device may be an infusion pump. a pill dispenser. amicroinfusion pump. an ECG monitor. a blood pressure monitor. a pulse oximeter.and/or a 002 capometer. an intravenous bag. and a drip-flow meter.

The monitoring client may be further configured to receive an identificationfrom the patient-care device and download the application from a server associatedwith the identification. The monitoring client may be further ured to receivean identification from the patient-care device and update the application from aserver ated with the identification.

The hardware ce may be a disk drive. memory. a buzzard. amicrophone. a r and a camera. The software resource may be of avariable. a secure data object. a secure variable. a secured APl. an API. and asoftware representation of a hardware component.

In yet another embodiment, a system for onic patient care includes amonitoring client configured to monitor a patient-care device. The monitoring clientes a sandbox component configured to control access to at least one ofa hardware resource and a software ce. The monitoring client may be isfurther configured to identify the patient-care device and execute an application tomonitor the patient-care . The monitoring client executes the applicationwithin the sandbox ent such that the application accesses the at least oneof the hardware resource and the software resource through the sandboxcomponent. The monitoring client may be further ured to control the patient-care device.

The t-care device may be an infusion pump. a pill dispenser. amicroinfusion pump. an ECG monitor. a blood pressure monitor. a pulse oximeter.and/or a 002 ter. an intravenous bag, and a drip-flow meter.

The monitoring client may be further configured to receive an identificationfrom the patient-care device and download the application from a server associatedwith the identification. The monitoring client may be further configured to receivean identification from the patient-care device and update the application from aserver associated with the identification.

The hardware resource may be a disk drive. memory. a buzzard. amicrophone. a speaker and a camera. The software resource may be of avariable. a secure data object. a secure variable. a secured API. an API. and asoftware representation of a hardware component.

In another embodiment, a system for electronic patient care includes a hubconfigured to communicate with electronic medical records. and a patient-caredevice. The hub is configured to identify a patient and the patient-care device (e.g..an infusion pump). The hub is also configured to download at least one entparameter (e.g.. an infusion drug, andior an infusion rate or rate profile. etc.) fromthe electronic medical records and program the t-care device with the at leastone treatment ter. The hub identifies the patient in accordance with atleast one of reading an RFID tag using an RFID interrogator, a voice using voicerecognition software coupled using a microphone. a face using face-recognitionre coupled to a camera, a biometric parameter of biometric read. anidentification, a barcode read by a barcode reader. In one specific embodiment,the hub may download the at least one treatment parameter using one or more ofthe identification techniques described herein.

In another embodiment. a system for onic patient care includes amonitoring client configured to communicate with electronic medical records, and apatient-care device. The monitoring client is configured to fy a patient and thepatient-care device (e.g.. an infusion pump). The ring client is alsoconfigured to download at least one treatment parameter (e.g.. an infusion drug.andlor an infusion rate or rate , etc.) from the electronic medical records andprogram the patient-care device with the at least one treatment parameter. Thering client identifies the t in accordance with at least one of reading anRFID tag using an RFID interrogator, a voice using voice ition softwarecoupled using a microphone. a face using face-recognition software coupled to acamera. a biometric parameter of biometric read, an identification, a barcode readby a barcode reader. In one specific embodiment, the monitoring client maydownload the at least one treatment parameter using one or more of theidentification techniques described herein.

In yet another embodiment. a system for electronic patient care comprises amonitoring client. a monitoring-clieni dock, a t-care device. and a devicedock. The monitoring client is configured to communicate at least one patient-careparameter. The monitoring-client. dock is configured to e the monitoring clientfor docking the monitoring client thereto. The patient-care device is configured tocommunicate the at least one patient-care ter. The device dock isconfigured to e the t-care device for docking the patient-care devicethereto.

In an embodiment. the monitoring-client dock and the device dock areconfigured to communicate one of wirelessly, and through a cable operativelyd to the monitoring-client dock and the device dock.

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

In another embodiment. the monitoring-client dock is configured to wirelesslycommunicate with the monitoring . and wherein the monitoring clientoperatively communicates with the patient-care device by communicating the atleast one patient-care parameter ssly with the monitoring-client dock, throughthe cable to the dock. and to the docked patient-care device.

In another embodiment. the monitoring client operatively communicates theat least one t-care parameter utilizing wireless communications to thering-client dock when the monitoring client determines at least one of:communication through the cable is unavailable; and the monitoring client isundocked from the monitoring-client clock.

In another embodiment, the device dock is configured to sslycommunicate with the monitoring client, and wherein the monitoring clientoperatively communicates with the patient-care device by communicating the atleast one patient-care parameter wirelessly with the device dock to the dockedpatient-care device.

In another embodiment, the monitoring client operatively communicates theat least one patient-care parameter utilizing wireless communications with thedevice dock when the monitoring client determines at least one of: communicationthrough the cable is unavailable; communication between the monitoring client andthe monitoring-client dock is unavailable; and the monitoring client is undockedfrom the monitoring-client clock.

In another embodiment, the patient care device is configured to wirelesslycommunicate with the monitoring client. and wherein the monitoring clientssly communicates the at least one patient-care parameter with the patient-care device.

In another embodiment. the monitoring client operatively communicates theat least one patient-care ter wirelessly with the patient-care device when thering client determines at least one of: ication through the cable isunavailable; communication between the monitoring client and the monitoring-clientdock is unavailable; communication between the device dock and the t-caredevice is unavailable: the monitoring client is undocked from the monitoring-clientclock.

In another embodiment. the monitoring-client dock and the dock areconfigured to communicate the at least one patient parameter wirelessly. Thesystem may further comprise a cable operatively coupled to the monitoring-clientdock and the device dock; and wherein the monitoring-client dock and the dock areconfigured to communicate wirelessly when at least one of the device dock. themonitoring-client dock. and the monitoring client determines the cable isunavailable as a communications link.

In r embodiment. the monitoring client is configured to communicatewith the patient-care device via a plurality of communication links. and wherein themonitoring client communicates via an operative one of the ity ofications links.

In another embodiment. the patient-care device is one of :n infusion pump.a pill dispenser. a microinfusion pump. an ECG monitor. a blood pressure monitor.a pulse oximeter. and a CO2 capometer, an intravenous bag. and a drip-flow meter.

In another embodiment, the patient-care parameter is at least one of aintravenous pump flow parameter. an ECG parameter. a blood pressure parameter.a pulse oximeter parameter, a 002 capometer parameter, an intravenous bagparameter. and a drip-flow meter value. The patient-care parameter may be apatient-condition parameter andfor a t-treatment parameter.

In r embodiment. the patient-care device is configured to wirelesslycommunicate as a node of a mesh network.

In another embodiment, a cable operatively coupled to the monitoring-clientdock and the device dock; wherein the monitoring client is configured tocommunicate the at least one t-care parameter with the patient-care devicethrough the cable when the patient-care device is docked to the device dock andthe ring client is docked to the monitoring-client dock.

In yet another embodiment. a system for electronic patient care comprises amonitoring client. a patient-care . and a device dock. The monitoring client isconfigured to communicate at least one t-care parameter. The patient-caredevice is configured to icate the at least one patient-care parameter. Thedevice dock is configured to receive the patient-care device for docking the patient-care device thereto and to receive the monitoring client for docking the monitoringclient thereto.

In yet another embodiment. a system for onic patient care comprises: apatient-care device configured to communicate the at least one patient-careparameter; a monitoring client configured to communicate at least one patient—careparameter; and a device dock configured to receive the patient-care device fordocking the patient-care device thereto. The device dock and the monitoring clientare integrated together.

In yet another embodiment. a system for electronic patient care comprises: astackable monitoring client configured to communicate at least one patient-careparameter; and a stackable patient-care device configured to communicate the atleast one patient-care parameter. The stackable monitoring client and the stackablepatient-care device may communicate the at least one pati Int-care parameter via adaisy-chained communications link and/or using a ane.

In yet another embodiment. a system for electronic patient care comprises: apatient-care device configured to communicate the at least one patient-careparameter; a hub client configured to communicate at least one patient-careparameter; and a device dock configured to receive the patient-care device forg the patient-care device o. The hub may plug into the device dock toestablish a communications link therebetween. The system may r se amonitoring client in operative communication with the hub to receive the at leastone patient-care ter. The patient-treatment parameter may be operativelyicated to the hub and the hub icates the patient-treatmentparameter to the patient care device.

In a specific ment, the hub may include a user interface. and the hubmay require user verification prior to sending the patient-treatment parameter to thepatient-care device.

In a specific embodiment, the monitoring client may include a user interface.and the monitoring client may require user ation prior to sending the patient-treatment parameter to the patient-care device through the hub.

In a specific embodiment. the patient-care device may e a userinterface. and the t-care device may require user verification of the patient-treatment parameter prior to treating a patient.

The hub may be configured to monitor a patient-care device. In a specificembodiment. the hub may include a sandbox component configured to controlaccess to at least one of a hardware ce and a software resource.

The hub may be further configured to fy the patient-care device andexecute an application to monitor the patient-care device. The hub may execute theapplication within the sandbox component such that the application accesses the atleast one of the hardware resource and the software resource through the sandboxcomponent.

In another embodiment. a system for electronic patient care comprises: atleast one patient monitor adapted to monitor at least one patient parameter; amonitoring client in operative communication with the at least one patient monitor toreceive the at least one patient ter therefrom; and a monitoring server inive communication with the monitoring client for receiving the at least onet parameter from the monitoring client.

In another ment. the system may r comprise a remotecommunicator in operative communication with the at least one t monitor toreceive the at least one patient parameter.

The at least one patient monitor may includes at least one of anelectrocardiography monitor, a blood pressure monitor. a pulse oximeter monitor,and a 002 capnomter. The monitoring client may be configured to downloadpatient information in accordance with a ated unique patient identifier. Theunique patient identifier may be encoded in a bar code disposed on a wrist band.

The unique patient identifier may be encoded on an RFID tag coupled to a wristband. (e.g.. an RFID interrogator). The t information includes a patientcondition or a patient care parameter. The unique patient identifier may beoperatively sent to the monitoring server to obtain electronic permission tocommunicate patient-specific data. A subset of the patient-specific data may bestored within a memory of the ring client. The monitoring client may beadapted to determine if a new order meets predetermined criteria based upon thesubset of the patient-specific data stored within the memory.

In another embodiment. the system further comprises a portable monitoringclient adapted to submit the new order to the monitoring client. At least one of themonitoring client and/or the remote communicator may be adapted to communicatethe new order to the monitoring server. and wherein the monitoring server may beadapted to determine if the new order meets another ermined criteria.

In another embodiment. the new order may be an order for medication andthe monitoring sewer may be adapted to determine if the new order meets theanother predetermined criteria by ining if the order for medication iscontraindicated by a currently ibed medication. The monitoring server maycommunicate with a database to ine if the new order meets the anotherpredetermined criteria. The ring server may be red to send an alert tothe monitoring client when the new order does not meet the another predeterminedcriteria.

In another embodiment. the system may comprise a remote communicationadapted for operative communication with at least one of the monitoring client andthe monitoring server.

In another embodiment. the monitoring client may be one of a desk-baseddevice. a portable device. a hand-held ller. a notebook PC. a netbook PC. atablet PC, and a smart phone. The monitoring client includes a touchscreen.

In another embodiment, the system may further include an infusion pump.and the monitoring client is in operative communication with the infusion pump.

The infusion pump may be able to the monitoring client. The infusion pumpmay be detachable to the ring client.

In another embodiment. the system further ses a dock configured todock the monitoring client to the infusion pump.

In another embodiment. the monitoring client is in operative communicationwith the infusion pump via a ss link.

In another embodiment, the ring sewer is configured to communicatewith a plurality of databases, and wherein at least one of the plurality of databasesincludes a data formatting or a communications protocol different from anotherdatabase of the ity of databases.

In another embodiment, the ring sewer is adapted to format data fromthe plurality of databases to download the data into the monitoring client.

Optionally. and in some specific embodiment. the monitoring client maycommunicate the at least one patient parameter to the monitoring server. In aspecific embodiment. the t ter may be one or more of andlor compriseat least one of treatment progress of an infusion pump. an electrocardiographicsignal. a blood pressure signal. a pulse oximeter signal. a 002 capnometer signal,and/or a temperature signal.

In another embodiment, the monitoring sewer may be configured todownload operational instructions to an infusion pump via the monitoring client.

The monitoring client may receive a user request to read the patientparameter and may interrogate the monitoring device to receive the tparameter.

In another embodiment, the system may further comprise a portablemonitoring client. The portable monitoring client may be in operative communicationwith the monitoring client for directly communicating t information therebybypassing the ring . The portable ring client may be configuredto change at least one parameter of an infusion pump and communicate thechanged at least one parameter to the monitoring server.

A change in a patient order submitted via the portable monitoring client maybe transmitted to r portable monitoring client.

In another embodiment. the monitoring client is ured to periodicallyupload information to the monitoring server for storage in a patient-specificdatabase.

The system may further comprise another monitoring client adapted toreceive the information from the t-specific database.

The ation may include at least one of a patient order, a patienttion. a progress note. monitoring data from the patient r, andtreatment data from an attached device.

The monitoring server may be configured to tnterrogate an electronic healthrecords database to receive patient information therefrom, The monitoring servermay be further configured to populate the monitoring client with a predefined setinformation in accordance with the patient information.

The predefined set of information may include at least one of a patientage,a height. a weight. a diagnosis. a current tion. a medication category. amedication allergies. and a sensitivity.

In r embodiment. the remote portable monitoring client is adapted tocommunicate with the monitoring client via the monitoring server. The remoteportable monitoring client may be one of a tablet PC, a netbook, and a PC. Theremote le monitoring client may include a touchscreen.

In another embodiment. a method for electronic patient care comprises:displaying a plurality of patients on a display; displaying at least one patientparameter on the display associated with a patient of the plurality of patients;displaying at least one alert associated with the patient on the display; andselecting the patient from the plurality of patients.

The method. in some specific ments, may further comprise sendingthe alert to a portable remote communicator device having the y from amonitoring client.

In yet another embodiment. an electronic patient-care system ses:monitoring client configured to communicate at least one patient-care parameter; apatient-care device configured to communicate the at least one patient-careparameter; and a communication interface configured to facilitate communicationn the monitoring client and the at least one patient care device. bydiscovering the presence of the at least one patient-care device and translatingcommunication signals from that device into a communication protocol associatedwith the monitoring client.

In a specific embodiment, the ication interface is further configuredto discover the presence of additional other patient-care devices that are differentfrom one another. and to translate communication signals from those devices intothe communication protocol ated with the ring client.

In another specific embodiment, the communication interface is furtherconfigured to provision power suitable for each of the devices. In yet anotherspecific embodiment. the system further comprises one or more databasesaccessible by the ring client that allow for at least one of central storage oft info andior downloading ation that can be used in treating of a patientassociated with the monitoring client.

In yet another specific embodiment, the communication interface is furtherconfigured to perform fault checking to at least one of assess data integrity ofcommunications with the patient-care device, assess whether the monitoring theclient is functioning ly. assess r the patient-care device is functioningproperly. and/or assess whether the ication interface is functioningproperly.

In yet another embodiment, an electronic patient-care system comprises: ahub client configured to communicate at least one patient-care parameter; apatient-care device configured to communicate the at least one patient-careparameter; and a communication interface configured to tate communicationbetween the hub and the at least one patient care device. by discovering thepresence of the at least one patient-care device and ating communicationsignals from that device into a communication protocol associated with the hub.

In a c embodiment, the communication interface is further configuredto discover the ce of onal other t-care devices that are differentfrom one another. and to translate communication signals from those devices intothe communication protocol associated with the hub.

In another specific embodiment. the communication interface is furtherconfigured to provision power suitable for each of the devices. In yet anotherspecific embodiment. the system r comprises one or more databasesaccessible by the hub that allow for at least one of central storage of patient infoand/or ading information that can be used in treating of a patient associatedwith the hub.

In yet another specific embodiment, the communication interface is furtherconfigured to perform fault checking to at least one of assess data integrity ofcommunications with the patient-care device, assess whether the ring theclient is functioning properly. assess whether the patient-care device is functioningproperly. and/or assess whether the communication interface is functioningproperly.

In yet another ment. an onic patient-care system comprises: adock configured to communicate at least one patient-care parameter; a patient-caredevice configured to communicate the at least one patient-care parameter; and acommunication interface configured to facilitate communication between the dockand the at least one patient care device, by discovering the presence of the at leastone t-care device and translating communication signals from that device intoa communication protocol associated with the dock.

In a specific ment. the communication interface is further configuredto discover the presence of additional other patient-care devices that are entfrom one another, and to translate ication signals from those devices intothe communication protocol associated with the dock.

In another specific ment, the ication interface is furtherconfigured to provision power suitable for each of the s. In yet anotherspecific embodiment. the system further comprises one or more databasesaccessible by the dock that allow for at least one of central e of patient infoandlor downloading information that can be used in treating of a patient associatedwith the dock.

In yet another specific embodiment, the communication interface is furtherconfigured to perform fault checking to at least one of assess data integrity ofcommunications with the patient-care device, assess whether the monitoring theclient is functioning properly. assess Whether the patient-care device is functioningproperly. andlor assess whether the communication interface is oningproperly.

In an embodiment. a patient-care device comprises: a body; a racewaywithin the body configured to receive a pole; and two friction members coupled tothe body and configured to frictionally lock the body to a pole within theraceway.

In an embodiment. a hub comprises: a patient-care device ace; apowersupply coupled to the patient-care device interface and configured to supply powerto a patient-care device; a processor; a transceiver coupled to the t-caredevice interface configured to provide communications between theprocessor andthe patient-care device. The processor may be configured, in some specificembodiments. to disable the patient-care device when in an alarm state.

In an ment. a dock comprises: a patient-care device interface; apower supply coupled to the patient-care device interface and configured to supplypower to a patient-care device; a processor; a transceiver coupled to the patient-care device interface configured to provide communications between theprocessorand the patient-care device. The sor may be configured, in some specificembodiments. to disable the patient-care device when in an alarm state.

In an embodiment. a communication module comprises: a patient-caredevice interface; a power supply d to the patient-care device interface andconfigured to supply power to a patient-care device; a processor; a transceiverd to the patient-care device interface configured to provide co ationsfor patient-care device and another device. The processor may be configured, insome specific embodiments, to disable the patient-care device when in an alarmstate.

In another embodiment. a t-care system comprises: a dock; a pluralityof modular patient-care device configured to dock with the dock; and a retractingdisplay of a monitoring client. The modular t-care devices may interface withthe dock along a horizontal plane, in a staggered fashion. or via a connector.

In yet another ment, an electronic patient care system comprises: afirst module configured to receive and store information pertaining to a patient, saidinformation including data related to a first parameter of the patient measured by adevice connected to the patient, and data related to a second parameter of thepatient ed from a first database containing information about the patient; anda second module configured to receive a medication order from a user via a userinterface associated with the second module, said second module being furtherconfigured to transmit said treatment order to the first module. wherein said firstmodule is r configured to: a) obtain medication information about saidmedication or other drugs from a second database. the medication informationincluding data providing limitations under which such medication is generallyadministered; b) determine whether the medication order must (in this specificembodiment) be confirmed by the second module based on the medicationation. the value of the first parameter and the value of the second parameter;and c) transmit a tablished message from the first module to the secondmodule for display on the user interface, said e confirming or warning aboutthe acceptability of said medication order.

The medication information may include drug interactions information, drugallergies information, blood pressure effects information. heart rate effectsinformation. heart rhythm effects information, or respiration s information. andwherein the first parameter or the second parameter include data about thepatient's currently administered drugs, known drug ies, current bloodpressure, current pulse rate. current heart . t respiratory rate or currentation.

The pre-established message may e a warning about the potentialeffects of the ordered medication. said warning including measured data about thefirst parameter, received data about the second parameter. or tioninformation obtained by the first module.

The first module may be configured to generate a signal that the tionorder or a modified medication order is to be processed after the pre-establishedmessage has been transmitted and upon receipt of a confirmation signal from thesecond module. the ation signal being triggered by an input signal from theuser interface.

In another embodiment. a patient-care device comprises a firstcommunications link and a second ications link; and a dock includes a firstcommunications link and a second communications link. When the patient-caredevice is within a predetermined range with the clock, the patient-care device andthe dock are paired using the first communications link and remain incommunication using the second communications link after the pairing. The gthat occurs using the first communications link may be to pair the patient-caredevice and the dock for the second communications link. The first communicationslink may be near-field communications and the second communications link may beBluetooth, Bluetooth Low Energy. WiFi, or other communications link.

In another embodiment, a patient-care device comprises a firstcommunications link and a second communications link; and a monitoring clientincludes a first communications link and a second communications link. When thepatient-care device is within a predetermined range with the monitoring . thepatient-care device and the monitoring client are paired using the firstcommunications link and remain in ication using the secondcommunications link after the pairing. The pairing that occurs using the firstcommunications link may be to pair the patient-care device and the monitoringclient for the second communications link. The first communications link may benear-field communications and the second communications link may be Bluetooth.

Bluetooth Low Energy, WiFi. or other communications link.

In some embodiments, a patient-care device comprises memory having auser interface template stored therein. The user interface template may becommunicated to a clock. a hub, and or a monitoring client for displaying on a userinterface of the dock. the hub. andior the monitoring client. The user interfacetemplate may be configured to display one or more t-care parametersed from the patient-care device (e.g., in real-time).

In yet another embodiment, an infusion pump includes an attachableelectronic ent. The attachable electronics component includes at least onesor. a power regulator. and a control system.

In an embodiment. a communication module includes at least one processor,and one or more of a transceiver, a battery, and a power supply to provide at leastone of communications capability and power to a patient-care device.

In yet another embodiment. a wearable system monitor includes a watchdogcomponent and a transceiver. The wearable system monitor may include aprocessor coupled to the watchdog component and the transceiver to perform awatchdog function for at least one paired device. The paired device may be atleast one of a dock, a hub. a monitoring client, and/or a patient-care device.

In yet another embodiment. a method includes one or more of: establish acommunications link between a patient-care device and a ring sewer;communicate a t-care parameter to the monitoring sewer; de-identify thepatient-care parameter; and/or store the de-identified patient-care parameter in themonitoring server.

In yet another embodiment. a method includes one or more of: establishcommunications links between a monitoring server and a plurality of patient-caredevices associated with a plurality of patients; icate a plurality of patient-care parameters from the plurality of patient-care device to the ring server;de-identify the patient-care parameters; store the patient-care parameters in themonitoring sewer; treat a plurality of patients with a treatment; and analyze asubset of the plurality of patient-care parameters associated with the plurality ofpatients to determine the efficacy of the treatment.

In yet another ment. a patient-care device (e.g.. an infusion pump) ishot-swappable in at least one of a dock. a hub, and/or a ring clientconnection.

In yet another embodiment, a method for having a hot-swappable patient-care device. e.g.. an infusion pump, es one or more of: receiving one or morepatient-care ters associated with a patient-care device; storing the one ormore patient-care parameters in a non-volatile memory of the patient-care device;loading the one or more patient-care parameters into the working memory; andresuming operation of the patient-care device. The method may include. in anadditional embodiment determining that operation of the patient-care device canresume.

In yet another ment. a method for having a hot-swappable patient-care device. e.g.. an infusion pump, includes one or more of: calculating one ormore operating parameters ated with a patient-care device; storing the oneor more operating parameters in a non-volatile memory of the patient-care device;loading the one or more operating parameters into the working memory; andresuming operation of the patient-care device. The method may include, in anadditional embodiment determining that operation of the patient-care device canresume.

In yet another embodiment, a method for pairing includes: oning aring client and/or a hub having a user interface within an operationaldistance of a patient-care device (e.g., an infusion pump); displaying the identity ofthe patient-care device on the user interface; selecting the t-care device forpairing using the user interface; pairing the patient-care device to the monitoringclient andfor the hub; and/or communicating patient-care parameters to themonitoring client andlor the hub. In yet another embodiment, and optionally. themethod may include operatively icating additional patient-care parameterswith another patient-care device through the t-care device. e.g.. to themonitoring client and/or the hub.

In yet another ment. a method es: docking a patient-caredevice into a dock; identifying the patient-care device; querying a server for anapplication to l the t-care device; downloading the application into adock, a hub. and/or a monitoring client; executing the application using the dock.the hub. and/or the monitoring client; and controlling the patient-care device usingthe application.

In yet another embodiment. a method includes: placing a patient-care deviceinto in operative ication with a hub; the hub may identify the patient-caredevice; the hub may query a server for an application to control the patient-caredevice; the hub may download the application into a hub; the hub may e theapplication; and the hub may control the patient-care device using the application.

In yet another embodiment, a method includes: g a patient-care deviceinto in operative communication with a dock; the dock may identify the patient-caredevice; the dock may query a server for an application to control the patient-caredevice; the dock may download the application into a dock; the dock may executethe application; and the dock may l the patient-care device using theapplication.

In yet another embodiment, a method includes: placing a patient-care deviceinto in operative ication with a monitoring ; the monitoring client mayidentify the patient-care device; the monitoring client may query a server for anapplication to control the patient-care device; the monitoring client may downloadthe application into a ring client; the monitoring client may execute theapplication; and the monitoring client may control the patient-care device using theapplication.

In yet another ment. a method may include: submit a request on auser interface of a communications device; confirm the request; and send therequest; receive the request with a check value; and confirm that the check value isin accordance with the request prior to sending.

In yet another embodiment, a hub includes a dock to e a patient-care, and at least one connector coupled to an opening door configured toreceive another patient-care device.

In yet another embodiment, a hub is in operative communication with at leastone of electronic medical records. DERS, CPOE, and/or and the internet to controland/or monitor a patient-care device.

In r embodiment. a hub is d to connect to a cradle to controlone or more patient-care devices coupled to the cradle.

In yet another embodiment, a battery pack includes a patient-care deviceinterface, a battery, and a regulated power supply configured to supply power to apatient-care device using the battery. The battery may, in some embodiment, berecharged using a DC power source.

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

In yet another embodiment. an onic patient-care system includes: amonitoring client and a dock configured to couple to a pole. An adapter may becoupled to the clock. The adapter may include at least one electronic coupler toplace a t-care device in operative communication with the monitoring client.

The patient-care device may slide into the adapter.

In yet another embodiment, an electronic t-care system includes amonitoring client. a patient-care device, and a communication module. The t-care device and/or the communication module are fault-tolerant of the monitoringclient. For example, the monitoring client cannot direct the patient-care device toperform an unsafe ion.

BRIEF DESCRIPTION OF THE DRAWINGSThese and other aspects will become more nt from the followingdetailed description of the various embodiments of the present disclosure withreference to the drawings wherein:Fig. 1 is a block diagram of an electronic patient-care system having twodocks in accordance with an embodiment of the present sure;Fig. 2 is a flow chart m illustrating a method for maintainingcommunications n the monitoring client and a patient-care device of Fig. 1 inaccordance with an embodiment of the present disclosure;Fig. 3 is a block diagram of an onic patient-care system having twodocks for wireless communications therebetween in accordance with anotherembodiment of the present disclosure;Fig. 4 is a flow chart diagram illustrating a method for maintainingcommunications between the monitoring client and a patient-care device of Fig. 3 inaccordance with an embodiment of the present disclosure;Fig. 5 is a block diagram of an onic patient-care system having a dockfor docking together a monitoring client and patient-care devices in accordance withyet another embodiment of the present disclosure;Fig. 6 is a flow chart diagram illustrating a method for maintainingcommunications between the monitoring client and a patient-care device of Fig. 5 inaccordance with an embodiment of the present disclosure;Fig. 7 is a block m of an electronic patient-care system having amonitoring client with an integrated dock for docking patient-care devices thereto inaccordance with yet r ment of the present disclosure;Fig. 8 is a block diagram of an electronic patient-care system having a hub inaccordance with yet another embodiment of the present disclosure;Fig. 9 is a block diagram of an electronic patient-care system having astackable monitoring client and stackable patient-care devices in accordance withyet another ment of the present disclosure;Fig. 10 is flow chart diagram of a method for communicating a patient-careparameter of a patient-care device to a monitoring server in accordance with anembodiment of the present disclosure;Fig. 11 is flow chart diagram of a method for ating patient-careparameters of multiple patients in a monitoring server in accordance with anembodiment of the present disclosure;Fig. 12 is a flow chart diagram of a method of recovery for a patient-caredevice when the ion of the t-care device is upted in accordancewith an embodiment of the present disclosure;Fig. 13 is a flow chart m of a method for pairing a monitoring clientwith a patient-care device in accordance with an embodiment of the presentdisclosure;Fig. 14 is a flow chart m of a method for monitoring operation of apatient-care device using a wearable system monitor paired to the patient-caredevice in accordance with an embodiment of the present disclosure;Fig. 15 is a flow chart diagram of a method for displaying a user aceusing an user-interface template in accordance with an embodiment of the presentdisclosure;Fig. 16 is a flow chart diagram of a method for downloading an applicationfor controlling a patient-care device in accordance with an embodiment of thepresent disclosure;Fig. 17 is a flow chart diagram of a method of ensuring data integrity whencommunicating data for a patient-care device in accordance with an embodiment ofthe present disclosure;Fig. 18 is a block diagram of an electronic patient-care system in accordancewith yet another embodiment of the present disclosure;Fig. 19 is a block diagram of an electronic patient-care system in accordancewith another embodiment of the present sure;Fig. 20 is a block diagram of a dock of the electronic patient-care system ofFig. 19 in accordance with an ment of the t disclosure;Fig. 21 shows an electronic patient-care system having a tablet docked intoa dock having a cable ically coupled to patient-care devices in accordancewith an embodiment of the present disclosure;Fig. 22 shows an electronic patient-care system having a tablet docked intoa dock for wirelessly communicating with patient-care devices in accordance withan embodiment of the t disclosure;Fig. 23 shows an electronic patient-care system having modular infusionpumps that dock into a dock having a monitoring client with a retractable userinterface in accordance with an embodiment of the present disclosure;Fig. 24 shows a side-view of the electronic patient-care system of Fig. 23 inaccordance with an embodiment of the present disclosure;Fig. 25 shows an electronic patient-care system having modular infusionpumps that dock into a dock having a monitoring client with a retractable userinterface. the infusion pumps are ed in a staggered fashion in accordanceIS with another embodiment of the present disclosure;Fig. 26 shows an electronic patient-care system having modular infusionpumps that dock into a dock along a common horizontal plane and the dockincludes a monitoring client with a retractable user interface in accordance with yetanother embodiment of the t disclosure;Fig. 27 shows a side-view of the electronic patient-care system of Fig. 26 inaccordance with another ment of the present disclosure;Fig. 28 shows an electronic patient-care system having a hub coupled to ascanner and a dock. the electronic patient-are system also includes modularinfusion pumps that dock into the dock along a common horizontal plane, and thedock includes a ring client with a retractable user interface in accordancewith yet r embodiment of the present disclosure;Fig. 29 shows a side-view of the onic patient-care system of Fig. 28 inaccordance with another embodiment of the present disclosure;Figs. 30-32 show l views illustrating a clutch system for mounting anelectronic patient-care system on a pole in accordance with an ment of thepresent disclosure;Fig. 33 shows an on pump and a dock coupled to a pole in accordancewith an embodiment of the present disclosure;Fig. 34 shows the infusion pump with another infusion pump coupled to anopen connector and an open connector in accordance with an embodiment of thepresent disclosure;Fig. 35 shows the on pump of Fig. 33 with two additional infusionpumps each coupled to a respective open connector in accordance with anment of the present disclosure;Fig. 36 shows a top view of one of the infusion pumps of Figs. 33-35 and ahub in accordance with an embodiment of the present sure;Fig. 37 shows a square-shaped hub having l connectors inIO accordance with an embodiment of the present disclosure;Fig. 38 shows an electronic patient-care system having a hub coupled to apole in accordance with another embodiment of the present disclosure;Fig. 39 shows an electronic t-care system having a hub coupled to apole and a portable dock that include a quick-release handle to detach the portabledock from the hub in accordance with another embodiment of the presentdisclosure;Fig. 40 shows an electronic patient-care system having a hub coupled to apole and a dock d to the hub in accordance with another embodiment of thepresent disclosure;Fig. 41 shows an electronic patient-care system having a hub coupled to apole in ance with another embodiment of the present disclosure;Fig. 42 shows an electronic patient-care system having a monitoring clientcoupled to a hub having s for receiving patient-care devices in accordancewith another embodiment of the present disclosure;Fig. 43 shows a close-up view of a T-shaped connector for ting withthe notches of the hub as shown in Fig. 42 in accordance with another embodimentof the present disclosure;Fig. 44 shows an electronic patient-care system having stackable patient-care s and a stackable container for housing an infusion bag in accordancewith another embodiment of the present disclosure;Fig. 45 shows an electronic patient-care system having stackable patient-care devices that are ble next to another stack of patient care devices inaccordance with yet another embodiment of the present disclosure;Fig. 46 shows an electronic patient-care system having ble patientcare devices with a syringe pump patient-care device having a single syringe inaccordance with another embodiment of the present disclosure;Fig. 47 shows an electronic patient-care system having stackabie patientcare devices with a syringe pump t-care device having two syringes inaccordance with another embodiment of the present disclosure;Fig. 48 shows an electronic patient-care system having stackable patient-care devices each having a display in accordance with another embodiment of thepresent disclosure;Fig. 49 is a close-up view of the handle of the electronic patient-care deviceof Fig. 48 in accordance with another embodiment of the t disclosure;Fig. 50 is a close-Up view of an infusion line port showing an infusion linepositioned therethrough of the electronic patient-care system of Fig. 48 inaccordance with r embodiment of the present disclosure;Fig. 51 shows another embodiment of an electronic patient-care systemillustrating the removal of a stackable patient-care device in accordance withanother embodiment of the present disclosure;Fig. 52 shows an electronic-patient care system prepared for tranSport inaccordance with another embodiment of the present disclosure;Fig. 53 shows an electronic-patient care system having stackable patient-care devices in accordance with r embodiment of the present sure;Fig. 54 shows an onic-patient care system having ble patient-care devices, stackable from the bottom up. in accordance with anotherembodiment of the present disclosure;Fig. 55 shows an electronic-patient care system d to a pole andhaving stackable patient-care s. stackable from the tap dowm in accordancewith another embodiment of the present disclosure;Fig. 56 shows a perspective-view of a clutch system having a release handlefor frictionally gripping to a pole in accordance with another ment of thepresent sure;Fig. 57 shows a back-view of the clutch system of Fig. 56 showing atransparent back in accordance with another embodiment of the present disclosure;Fig. 58 shows a top, cross-sectional view of the clutch system of Fig. 56 inaccordance with r embodiment of the present disclosure;Fig. 59 is a block m of a system to l an infusion pump inaccordance with an embodiment of the t disclosure;Fig. 60 is a block m of an electronic patient-care system having a hubfor communicating with several electronic patient-care devices in accordance withan ment of the present disclosure;Fig. 61 is a block diagram of an electronic patient-care system having a dockconnectable to t-care devices through USB connections in accordance withan embodiment of the present disclosure;Fig. 62 is a process diagram showing several stages of electronic patient-care in accordance with an embodiment of the present disclosure;Figs. 63-66 show several arrangements of an electronic patient-care systemin accordance with an embodiment of the present disclosure;Fig. 67 shows a timing diagram of electronic t-care treatment using aninfusion pump in accordance with an ment of the present disclosure;Figs. 68A-688 show a flow chart diagram of a method illustrating the timingdiagram of Fig. 67 in accordance with an embodiment of the present disclosure;Figs. 69-70 show additional arrangements of an electronic patient-caresystem in accordance with an ment of the present disclosure;Fig. 71 shows a timing diagram of electronic patient-care ent using aninfusion pump in accordance with an ment of the present disclosure;Figs. 72A-72B show a flow chart diagram of a method illustrating the timingm of Fig. 71 in accordance with an embodiment of the present disclosure;Fig. 73 shows another timing diagram of electronic patient-care treatmentusing an infusion pump in accordance with an embodiment of the presentdisclosure;Fig. 74 shows a flow chart diagram of a method illustrating the timingdiagram of Fig. 73 in accordance with an embodiment of the present disclosure;Fig. 75 shows yet another timing diagram of electronic patient-care treatmentusing an infusion pump in accordance with another ment of the presentdisclosure;Fig. 76 shows a flow chart diagram of a method illustrating the timingdiagram of Fig. 75 is accordance with an embodiment of the present disclosure;Figs. 77-78 show several arrangements of an electronic patient-care systemin accordance with an embodiment of the present disclosure;Fig. 79 shows another timing diagram of an onic patient-care treatmentusing an infusion pump in accordance with r embodiment of the presentdisclosure;Figs. BOA-808 show a flow chart diagram of a method illustrating the timingdiagram of Fig. 79 in accordance with an embodiment of the present disclosure;Fig. 81 shows another timing diagram of an electronic patient-care treatmentusing an on pump in accordance with another embodiment of the presentdisclosure;Figs. 82A—828 show a flow chart diagram of a method illustrating the timingdiagram of Fig. 81 in accordance with an embodiment of the present sure;Figs. 83-89 show several onai embodiments of an electronic patient-care system in accordance with severe! embodiments of the present disclosure;Fig. 90 shows a block diagram of electronic circuitry of embodiments of ahub in accordance with an ment of the present sure;Fig. 91 shows a block diagram of electronic circuitry for interfacing with aninfusion pump in accordance with an embodiment of the present disclosure;Fig. 92 shows r embodiment of an electronic patient-care systemhaving vertically aligned patient-care devices docked in a dock in accordance withan embodiment of the present disclosure;Fig. 93 shows a block diagram of onic circuitry of an embodiment of ahub in accordance with an embodiment of the t disclosure;Fig. 94 shows a block diagram of electronic circuitry of a communicationmodule in accordance with an embodiment of the present disclosure;Figs. 95-98 shows several embodiments of electronic t-care systemshaving an infusion pump coupied with a communications module in accordancewith several embodiment of the present disclosure;Figs. 99-101 show several block diagrams of electronic circuitry of a dock inaccordance with several embodiments of the present disclosure;Fig. 102 shows a block diagram of a battery pack in accordance with anembodiment of the present disclosure;Figs. 103-104 show additional embodiments of electronic try of a dockin accordance with additional embodiments of the present disclosure;Figs. 105-116 show several embodiments of attachable pumps attached to amonitoring client in accordance with additional ments of the presentdisclosure;Fig. 117 shows a backplane for use with infusion pumps in accordance withan embodiment of the present disclosure;Fig. 118 shows a cross-sectional view of the ane panel of Fig. 117 inaccordance with an embodiment of the present disclosure;Figs. 119-120 show several embodiments of attachable pumps attached to amonitoring client in accordance with additional embodiments of the presentdisclosure;Fig. 121 shows a communication module in accordance with an embodimentof the present disclosure;Fig. 122 shows a communication module attached to a patient-monitoringdevice in accordance with an embodiment of the t disclosure;Fig. 123 shows a diagram of electronic circuitry of the communicationmodule of Fig. 121 in accordance with an embodiment of the present disclosure;Fig. 124 shows a diagram of electronic circuitry to translate ieldCommunications to UHF in ance with an ment of the presentsure;Figs. 125-127 show several antennas in accordance with onalembodiments of the present disclosure;Fig. 128 shows a patient wristband with an RFID tag attached thereto inaccordance with an embodiment of the present disclosure;Fig. 129 shows split-ring resonator for use on the wristband of Fig. 128 inaccordance with an ment of the present disclosure;Fig. 130 shows a near-field antenna in accordance with an ment ofthe present disclosure;Fig. 131 shows an equivalent circuit for the Split-ring resonator of Fig. 130 inaccordance with an embodiment of the present disclosure;Fig. 132 shows a 5 R's checklist that may be displayed on a monitoring clientin ance with an embodiment of the present disclosure;Fig. 133 shows an occlusion checklist that may be displayed on a monitoringclient in accordance with an embodiment of the present disclosure;Fig. 134 shows a display of a monitoring client in operative communicationwith several infusion pumps in accordance with an ment of the presentdisclosure;Fig. 135 is an illustration of a display on a health care provider's portablemonitoring client, showing a list‘of patients whose information the provider canaccess in accordance with an embodiment of the present sure;Fig. 136 is an ration of a diSplay on a health care provider's portablemonitoring client, showing devices associated with a particular patient, with currentdata from the devices and one-touch access to some of the patient's medicalinformation in accordance with an embodiment of the present disclosure;Fig. 137 is an ration of a display on a health care provider's portablemonitoring client, showing data entry fields for a prescription for a medication foruse with an intravenous infusion pump in accordance with an embodiment of thepresent disclosure;Fig. 138 is an illustration of a display on a health care provider's portablemonitoring client. showing a risk profile associated with an ordered tion. anda suggested course of action, as generated by the monitoring client in accordancewith an embodiment of the present disclosure;Fig. 139 is an illustration of a display on a health care provider's portablering client. showing a medication prescription ready for sion by theordering provider in accordance with an embodiment of the present disclosure;Fig. 140 is an illustration of a y on a health care provider's portablemonitoring client, showing how the monitoring system can diSplay confirmation tothe ordering provider that the prescription has been transmitted to the cist inaccordance with an embodiment of the present disclosure;Fig. 141 shows a ctive-view of nfusion pump coupled to anadapter in accordance with an embodiment of the present disclosure;Fig. 142 shows a perspective-view of a wireless hub device that wirelesslyrelays data from a patient-care device to a monitoring client, another hub, or a dockin accordance with an embodiment of the present sure;Fig. 143 shows a front, perspective-view of an electronic patient-care systemhaving modular patient care devices coupled to a monitoring client via an adapterand a dock in ance with an embodiment of the t disclosure;Fig. 144 shows a side, perspective-view of the electronic patient-care systemof Fig. 143 in accordance with an embodiment of the t disclosure;Fig. 145 shows a close-up, perspective view of the interface of one of thepatient-care devices shown in Fig. 143 in accordance with an embodiment of thepresent disclosure;Fig. 146 shows a top view of the electronic patient-care system of Fig. 143 inaccordance with an embodiment of the t disclosure;Fig. 147 shows an ration of a system for electronic patient-care systemin accordance with an embodiment of the present disclosure;Fig. 148 shows a block diagram of an electronic patient-care system inaccordance with an embodiment of the present disclosure;Fig. 149 shows a block diagram of a beside portion of the electronic patient-care system of Fig. 147 and/or Fig. 148 in accordance with an embodiment of thepresent disclosure;l5 Fig. 150 shows a block diagram of the dock/hub of Figs. 147, 148, and/or149 in accordance with an embodiment of the present disclosure;Fig. 151 is a block diagram illustrating the infusion pump circuitry of Figs.148 and/or 149 in ance with an ment of the t disclosure; andFig. 152 is a block diagram illustrating the sensors coupled to the icsof an infusion pump in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTIONques for facilitating patient care are disclosed. The techniques can beimplemented, for example, in a system having one or more patient-care devicesthat are communicatively coupled to a monitoring client, in accordance with oneexemplary embodiment. The patient-care devices may include any number ofdiverse functionalities and/or may be produced by different manufacturers. In onesuch case, a ication interface between the client monitoring station and thevarious e patient-care devices allows for discovery and protocol translation,as well as various other functionalities such as power provisioning, regulatorycompliance, and user interface to name a few. A patient-care device may be anon pump, a microinfusion pump. an insulin pump, a syringe pump, a pilldispenser, a dialysis machine, a ventilator, a sonogram, a ECG monitor, a bloodpressure monitor, a pulse oxymeter, a 002 capnometer, a drip counter, a flow-ratemeter, an optical Doppler device, a heart rate monitor, an IV bag, a hemodialysismachine, a peritoneal dialysis machine, intestinal dialysis machine, a patientthermometer, and/or other bedside patient-care device. U.S. Patent ApplicationSerial No. 11/704,899, filed February 9, 2007 and entitled Fluid Delivery s andMethods, now U.S. Publication No. US0228071-A1 published r 4, 2007(Attorney Docket No. E70), U.S. Patent Application Serial No. 11/704,896, filedFebruary 9, 2007 and ed Pumping Fluid Delivery Systems and Methods UsingForce Application Assembly, now U.S. Publication No. US0219496,published September 20, 2007 ney Docket. E71), U.S. Patent ApplicationSerial No. 11/704,886, filed February 9, 2007 and entitled Patch-Sized Fluidry Systems and Methods, now U.S. Publication No. 7-0219481,published ber 20, 2007 (Attorney Docket No. E72), U.S. Patent ApplicationSerial No. 11/704,897, filed February 9, 2007 and entitled Adhesive and PeripheralSystems and Methods for Medical Devices, now U.S. Publication No. US—2007—0219597, published September 20, 2007 (Attorney Docket No. E73), U.S. PatentApplication Serial No. 12/347,985, filed December 31, 2008, and entitled InfusionPump Assembly, now U.S. Publication No. US0299277 published December 3,2009 (Attorney Docket No. G75), U.S. Patent ation Serial No. 12/347,982,filed December 31, 2008 and entitled Wearable Pump Assembly, now U.S.

Publication No. US-2009—0281497, published November 12, 2009 (Attorney DocketNo. G76), U.S. Patent Application Serial No. 12/347,981, filed December 31, 2008and entitled Infusion Pump ly, now U.S. Publication No. US0275896,published November 5, 2009 (Attomey Docket No. 677), U.S. Patent ApplicationNo. 12/347,984 filed December 31, 2008 and entitled Pump ly With Switch,now U.S. Publication No. US0299289, published December 3, 2009ney Docket No. G79), U.S. Patent Application Serial No.12/249,882. filedOctober 10, 2008 and entitled Infusion Pump Assembly, now U.S. ation No.

US0094222, published April 15, 2010 (Attorney Docket No. F51), U.S. PatentApplication Serial No. ,636, filed October 10, 2008 and entitled System andMethod for Administering an lnfusible Fluid, now U.S. ation No. US0094261, published April 15, 2010 (Attorney Docket No. F52), U.S. PatentApplication Serial No. 12/249,621, filed October 10, 2008 and ed OcclusionDetection System and Method, now U.S. Publication No. US—2010-0090843,published April 15, 2010 (Attorney Docket No. F53), U.S. Patent Application SerialNo. 12/249,600, filed October 10, 2008 and entitled Multi-Language/Multi-sor Infusion Pump Assembly, now US. Publication No. US0094221,hed April 15, 2010 (Attorney Docket No. F54), US. Patent No. 8,066,672,issued November 29, 2011 and entitled An Infusion Pump Assembly with a BackupPower Supply ney Docket No. F55), US. Patent No. 8,016,789, issuedSeptember 13, 2011 and entitled Pump Assembly with a Removable CoverAssembly (Attorney Docket No. F56), US. Patent No. 7,306,578, issued December11, 2007 and entitled Loading Mechanism for on Pump (Attomey Docket No.

C54), all which are hereby incorporated herein by reference in their entireties. Thetechniques can be used to allow for seamless communication and failsafeion. Numerous other features, functionalities, and applications will beapparent in light of this disclosure.

General OverviewIS As usly described the process of ing comprehensive care topatients, such as ordering and delivering of medical treatments, is associated with anumber of non-trivial . For instance, there is great potential for alinformation to be miscommunicated, treatment ons to be made without readyaccess to complete information, and/or delay in implementation of prescriptions dueto unnecessarily redundant and inefficient procedures.

In more , medication errors may be responsible for hundreds of deathsand may injure thousands or even millions of people each year in the United Statesalone. Hospitals under financial stress may experience an increased incidence ofmedication errors. Medications associated with the most dangerous errors includeinsulin, narcotics, heparin, and chemotherapy. Sources of medication errorse administering the wrong medication, administering thewrong concentrationof medication. ring the medication at the wrong rate, or delivering themedication through the wrong route (medications can be administered orally,intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, eye orear, intrathecally, intraperitoneally, or even intravesically). Even with properordering and proper labeling, medications may still be administered improperlybecause of illegible handwriting, munication of prescriptions formedications, and mispronunciation of medications having similar names. The trendof using electronic medical records (“EMR”) and bar coding systems fortions has been shown to reduce the nce of medication . EMRs, for example, can facilitate computerized provider order entry ”)and flag prescriptions that do not match a t's diagnosis, allergies, weight,and/or age. However, these systems have not been widely adopted and theirimplementation can result in significant delays and inefficiencies in ordering,preparing, and administering medications.

In addition, medication infusion devices, e.g., infusion pumps, are involved ina substantial number (e.g., up to one third) of all medication errors that result insignificant harm. The wrong medication may be hung, incorrect parameters (e.g.,medication concentration or infusion rate) may be entered, or existing infusionparameters may be improperly changed. Of the deaths related to infusion pumps,nearly half may be due to user error and most of these errors may be due to errorsin programming the infusion pump.

An effective monitoring system may monitor and intercede at any phase ofthe medication ordering and administration process to help minimize any of anumber of e events that could result from the treatment. The medicationtreatment s may be conceptually separated into three phases: a prescriptionphase, a tion preparation phase, and a medication administration phase.

Errors can occur when a iption for a medication is written or entered, whenthe medication is retrieved for use or mixed in a solution, or when the medication isadministered to the t.

Thus, in ance with an embodiment of the present disclosure, anelectronic patient-care system is disclosed that includes a monitoring clientconfigured to communicate at least one patient-care parameter, a patient-caredevice configured to communicate the at least one patient—care parameter, and acommunication interface configured to facilitate communication between themonitoring client and the at least one patient care device, by discovering thepresence of the at least one patient-care device and translating communicationsignals from that device into a communication protocol associated with themonitoring . In some embodiments. the monitoring client passively monitorsthe operation of a patient-care device. The communication interface may beimplemented by a communication module described below. The communicationinterface may be further configured to discover the presence of additional otherpatient-care devices that are ent from one another (e.g., diversemanufacturers, functions, and/or communication protocols, etc), and to translatecommunication signals from those devices into the communication protocolassociated with the monitoring client or a hub. Thus, the communication interfaceallows the monitoring , such as a tablet computer, to effectively be used ascommon generic user interface that healthcare providers can use when providingtreatment to a patient ated with the monitoring client. One or moredatabases accessible by the monitoring client allow for central storage of patientinfo (in any format and database structure, as desired by the healthcare facility ordatabase maintainer), as well as for downloading ation that can be used bythe healthcare providers in treatment of the patient associated with the monitoringclient. The communication interface can be implemented in a number of ways,using wired and/or wireless technologies, and allows for seamless communicationand failsafe operation of multiple t-care devices. Some patient-care devices,hubs, docks, and/or monitoring clients may icate simultaneously over twoor more communications links andlor simultaneously over two frequency ls(in some embodiments, the data may be redundant). In some embodiments, thecommunication module may allow a patient-care device to be portability used,e.g.,by including a battery and sufficient circuitry for mobile operation of the patient-caredevice, such as an infusion pump. onally or alternatively, a t wristbandmay include batteries that can plug into the communication module to power thepatient-care device (or in some embodiments, it may be plugged directly into thepatient-care device). The communication module may be vvirelessly charged.

In some embodiments, data such as patient-care parameters (e.g., imeters, in some ments) may be transmitted to a cloud server forstorage and may be de—identified.

System ArchitectureAs shown in Fig. 1, an onic patient care system 100 includes one ormore monitoring clients 1,4, each of which may be assigned and in physicalproximity to an individual patient 2, and a remote monitoring sewer 3 for theuploading of information from a number of the various monitoring clients 1,4, andfor downloading information and instructions from various sources to the monitoringclients 1.4. When in the patient's room, a health care provider can interact lywith a monitoring client 1 to obtain information about the patient 2 or to enter ordersning to the patient 2. Multiple monitoring clients 1 may interact with a singlemonitoring server 3. The ring server 3 may include middleware (e.g.,middleware on the monitoring server 3 of Fig. 1). Additionally or alternatively,ers at remote locations (e.g., 's office, nursing station 5. hospitalpharmacy 6) may interact with an individual monitoring client 1 through acommunications link with the monitoring server 3 or directly via a hospital local areanetwork having each of the monitoring clients 1,4 as a node.

A remote communicator 11, other monitoring clients 4, a nursing station 5, ora doctor's office may enter in prescriptions which are sent to update the Patient'sPersonal EHR 19 or are sent to the pharmacy 6 for filling. The prescription may bea prescription for pills. for infusing a fluid, or other treatment. The prescription maybe a prescription for ng a fluid using the infusion pump 7, the syringe pump126 or the microinfusion pump 130, or for dispensing pills using the pill dispenser128.

The pharmacy 6 may include one or more computers connected to anetwork, e.g., the et, to receive the prescription and queue the prescriptionwithin the one or more computers. The pharmacy may Use the prescription: (1) tocompound the drug (e.g., using an automated compounding device that cannd a fluid or create a pill that is coupled to the one or more computers, ormanually by a pharmacists viewing the queue of the one or more ers); (2) topre-fill a fluid reservoir of a syringe pump 126; (3) to program the syringe pump 126(e.g., a treatment regime is programmed into the syringe pump 126); (4) to pre-fillthe microinfusion pump 130; (5) to program the microinfusion pump 130; (6) to pre-fill the IV bag 170; (7) to program the infusion pump 7; (8) to pre—fill the pilldispenser 128; (9) or to program the pill dispenser 128 at the cy inaccordance with the iption. The automated compounding device mayautomatically fill the fluid within one or more of the syringe pump 126, the IV bag170 or the microinfusion pump 130, andior may automatically fill the pill dispenser128 with pills. The ted compounding device may generate a barcode, anRFID tag and/or data. The ation within the barcode, RFID tag, and/or datamay include the treatment regime, prescription, and/or patient information.

The automated compounding device may: (1) attach the barcode to theinfusion pump 7, the syringe pump 126, the microinfusion pump 130, the pilldispenser 128, or the IV bag 1m; (2) attach the RFID tag to the infusion pump 7,the syringe pump 126, the microinfusion pump 130, the pill dispenser 128, or the IVbag 170; and/or (3) program the RFID tag or memory within the infusion pump 7,the e pump 126, the microinfusion pump 130, the pill dispenser 128, or the IVbag 170 with the information or data. The data or information may be sent to adatabase (e.g.. the patient’s EHR 19 or the t's personal EHR 19') thatassociates the prescription with the infusion pump 7, the syringe pump 126, themicroinfusion pump 130. the pill dispenser 128, or the IV bag 170, e.g., using aserial number or other fying information within the barcode, RFID tag, ormemory.

The on pump 7, the syringe pump 126, the microinfusion pump 130, orthe pill dispenser 128 may have a scanner (e.g.. an RFID interrogator or barcodescanner) that determines: (1) if the syringe pump 126 or the IV bag 170 has thecorrect fluid; (2) if the microinfusion pump 130 has the correct fluid; (3) if the pilldispenser 128 has the correct pills; (4) if the treatment programmed into theinfusion pump 7, the syringe pump 126, the microinfusion pump 130, or the IV bag170 ponds to the fluid within the syringe pump 126, the microinfusion pump130 or IV bag 170; (5) if the treatment programmed into the pill dispenser 128corresponds to the pills within the pill dispenser 128; and/or (6) if the treatmentmmed into the infusion pump 7, the e pump 126, the microinfusionpump 130, or the pill dispenser 128 is correct for the particular patient (e.g.. asdetermined from a patient's barcode, RFID, or other patient identification). That is,in some specific embodiments, the infusion pump 7, the syringe pump 126, themicroinfusion pump 130 and/or the pill dispenser 128 may read one or more serialnumbers off of an RFID tag or barcode and ensure that the value matches a valueas found in internal memory (e.g., downloaded via the automated compoundingdevice, for example) or that the value matches a value as found in electronicmedical records of a patient (e.g.. via a patient’s serial number as determined by ascan of an RFID tag of a patient or a scan of a barcode by the patient as stored inthe patient's EHR 19 or the patient's personal EHR 19').

For example, the scanner of the infusion pump 7, the syringe pump 126, themicroinfusion pump 130, or the pill dispenser 128 may scan a barcode of anotherpatient-care device to obtain a serial number of the t care device and apatient's barcode to determine a serial number of the patient, and may query theonic l records data to determine if the serial number of the patient-caredevice corresponds to the serial number of the patient as stored within theelectronic medical s (e.g., which may have been updated by the pharmacy22 or the automated compounding device of the pharmacy).

Additionally or alternatively, the monitoring client 6 may scan the onpump 7, the syringe pump 126, the pill dispenser 128, the microinfusion pump 130,or the IV bag 170 to ine: (1) if the syringe pump 126 or the IV bag 170 hasthe correct fluid; (2) if the microinfusion pump 130 has the correct fluid; (3) if the pilldispenser 128 has the correct pills; (4) if the treatment programmed into theinfusion pump 7, the syringe pump 126, the microinfusion pump 130, or the IV bag170 corresponds to the fluid within the syringe pump 126, the microinfusionpump130 or IV bag 170; (5) if the treatment programmed into the pill dispenser 128corresponds to the pills within the pill dispenser 128; and/or (6) if the treatmentprogrammed into the infusion pump 7, the syringe pump 126, the microinfusionpump 130, or the pill dispenser 128 is correct for the particular patient (e.g., asdetermined from a t's barcode, RFID, or other patient identification).

Additionally or alternatively, the monitoring client 1, the infusion pump 7, the syringepump 126, the microinfusion pump 130, or the pill dispenser 128 may ogatethe electronic medical records database 19 or 19' and/or the pharmacy 22 to verifythe prescription or download the prescription, 3.9., using a barcode serial numberon the infusion pump 7, the syringe pump 126, the microinfusion pump 130, the pilldispenser 128, or the IV bag 170.

Optionally, the ring client 1, the other monitoring client 4, and/or theremote communicator 11 may be used to send commands or requests to thepatient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 such as for example,a bolus amount, an on flow rate. a total fluid for ry, a start time for drugdelivery, a stop time for drug delivery or a flow-delivery-rate profile to the infusionpump 7, the syringe pump 126 and/or the microinfusion pump 130. In someembodiments. one or more of the monitoring clients 1, 4, 11 may be used to sendcommands or requests to the pill dispenser 7, such as, for example, a pill dispensecommand to se a pill, a ype, a pill dispensing schedule, and/or a maxpill-dispensing criteria. The max pill-dispensing criteria may be a mamount of a medication that may be delivered within a predetermined interval oftime; for example, certain medications are taken as needed (i.e., pro re nata);however, the medication may not be safe if taken in excess and the max pill-sing criteria may prevent the medication from being taken at unsafe levels bythe patient, e.g., a predetermined amount during a predetermined interval of time.

Optionally, the patient-care s 7, 14, 15, 16, 17, 35, 126, 128, 130,, 148may also communicate data back to the monitoring client 1, the other monitoringclient 4 and/or the remote communicator 11 for: determining if an alarm or alertshould be issued or sent; determining if the treatment or condition is safe for thet; determining if the system 100 is Operating ly or within predeterminedbounds; and/or for displaying the data on a display of the monitoring client 1, theother monitoring client 4 andlor the remote communicator 11. For e,optionally, the infusion pump 7, the syringe pump 126, and/or the microinfusionpump 130 may communicate (where applicable): upstream pressure; supstream pressure; pressure downstream to the patient 2; changes in pressuredownstream to the patient 2; the presence or absence of air within an infusion line;an actual bolus amount delivered; an actual infusion flow rate; an actual total fluiddelivered; an actual start time for drug delivery; an actual stop time for drugdelivery; or an actual flow-delivery-rate profile to one or more of the monitoringclient 1, the other monitoring client 4 and/or the remote communicator 11. Inanother embodiment, the pill dispenser 128 may Optionally communicate data backto the monitoring client 1, the other monitoring client 4, and/or the remotecommunicator 11. such as, for example, an actual pill dispensed, an actual ypedispensed, an actual pill dispensing schedule as sed, or r or not amax pill-dispensing criteria was exceeded.

The data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126,128, 130, 148 may be analyzed for any predefined conditions to issue an alarmand/or an alert. For example, one or more of the monitoring clients 1, 4, 11 mayuse an increase in pressure downstream of the on pump 7, the syringe pump126 and/or the microinfusion pump 130 to be an indication of one of: excessiveclotting, infiltration, occlusion or kinking of the tubing to the patient; or occlusioncaused downstream by material, e.g., such as ination found within the IVbag 170. In response to the sudden increase in downstream pressure, one or moreof the monitoring clients 1, 4, 11 may visually or y alarm or alert a user.

These alarms and/or alerts may also inform a nurse to take other appropriateactions, e.g., a suggestion to change a needle in response to an occlusion (e.g.,one caused by clotting) when the pressure downstream to the patient rises above apredetermined threshold, or a suggestion to check for a kink in the line when thepressure downstream to the patient rises above a ermined thresholdAdditionally or alternatively, a sudden decrease in pressure downstream tothe patient 2 may be an indication that the tubing has become detachedfrom theneedle and/or the needle is now out of the patient; and, in response, one or more ofthe monitoring clients 1, 4, 11 may visually or audibly alarm or alert a user toreattach the tubing to the needle or insert a new needle for continued infusion. Thealarm may also indicate that action needs to be taken quickly,e.g., because thepatient may be bleeding such as when the tubing becomes ed from theIO needle and the patient is bleeding through the unattached needle coupler.

In some embodiments, additionally or alternatively, there upstream toone or more infusion pumps 7 may be monitored for any upstream occlusions. Forexample, contamination with the IV bag 170 may clog the tubing upstream of theinfusion pump 7. During each time the infusion pump 7 attempts to pump fluid fromthe IV bag 170, the pressure am to the infusionpump 7 may drop lower thanwould occur when there is no occlusion upstream. ore, one or more of themonitoring clients 1, 4, 11 may issue an alarm or alert when the upstream redrops below a predetermined threshold and suggest or require a caregiver toalleviate the ion, e.g., by changing tubing or a IV bag 170.

One or more of the monitoring clients 1, 4, 11 may, ally, send acommand to one or more of the infusionpump 7, the syringe pump 126, andior themicroinfusion pump 130 to step delivery of fluid inresponse to the sudden increaseand/or decrease of pressure downstream to the patient 2.

As shown in Fig. 1, and as in some embodiments, the system 100 includes amonitoring-client dock 102 and a device dock 104. The monitoring-client dock 102is configured to receive the monitoring client 1, and the device dock 104 isconfigured to receive one or more t-care devices to facilitate bedside tcare (described in more detail below). Although the device dock 104 is shone. asbeing capable of receiving several patient-care devices, in other embodiments, thedevice dock 104 can receive one patient-care . a plurality of patient-caredevices, or any ary number of patient-care devices. Additionally, althoughthe monitoring-client dock 102 is shown as be capable of receivingone monitoringclient 1, in other embodiments, the monitoring-client dock 102 can receive twomonitoring clients 1, more than two monitoring clients 1, or any arbitrary number ofmonitoring clients 1.

In this e embodiment, a cable 110 is coupled to both of the docks102, 104 to provide a communications link therebetween. The cable 110 may bepermanently attached to or is attachable to one or both of the docks 102, 104.

Additionally or alternatively, the cable 110 may include one or more connectors (notexplicitly shown) for plugging the cable into one or both of the docks 102, 104.

In some embodiments, the docks 102, 104 can communicate with each otherusing one or more wires andlor waveguides within the cable 110. For example, inan embodiment of the present disclosure. the cable 110 includes a fiber-opticwaveguide to provide an l communications link between the docks 102, 104.

In other embodiments, and as will be appreciated in light of this disclosure. cable110 can be ed with one or more wireless communication links (e.g.,Bluetooth, etc), if so desired. Still other embodiments may employ a combination ofwired and wireless communication channels n docks 102. 104. Any numberof suitable wired connection types can be used in various embodiments.

In some embodiments, the communications link between the docks 102, 104may use any know communications links, such as serial communications. elcommunications, synchronous communications, asynchronous communications,packet-based communications. virtual-circuit based ications, and the like.

Additionally or alternatively, in some embodiments, the communications linkestablished n the docks 102, 104 may utilize a wireless connection, a wiredconnection, a connectionless protocol, e.g., User Datagram Protocol ), or aconnection-based protocol, e.g., Transmission Control Protocol (“TOP"). Forexample, the communications between the docks 102. 104 may be based uponone or more of a Universal Serial Bus standard, SATA, eSATA, firewire, anEthernet standard, Fibre Channel. Bluetooth, Bluetooth Low Energy, WiFi, anyphysical layer technology, any OSl-layer technology, and the like.

When the monitoring client 1 is docked to the monitoring-client dock 102, themonitoring client 1 has access to the communications between the docks 102, 104.

For e, in some embodiments of the present disclosure, the ring client1 can communicate with electronic circuitry within the device dock 104, e.g., a, via the communications link provided by the cable 110. Additionally oralternatively, the monitoring client 1 can communicate with any device docked tothe device dock 104 through the communications link provided by the cable 110and/or one or more wireless ication links (described in more detail below).

With further reference to the e embodiment shown in Fig. 1. thedevice dock 104 may include a variety of accessories, each of which is optional.such as an attachable display 134, a camera 136. and a microphone 138. Likewise,the monitoring-client dock 102 may include a variety of accessories. each of whichis al. such as a camera 140 and a microphone 142. The monitoring client 1may include a variety of accessories. each of which is al. such as a camera144 and a microphone 146. The cameras 136. 140, 144 may be used. forexample. by facial-recognition software to authenticate or identify the presence of aprovider (e.g.. a nurse. nurse tioner. doctor. etc.) and/or a patient.

Additionally or alternatively. the microphones 138, 142. and 146 may be used. forinstance, by voice-recognition software to authenticate or identify the presence ofthe er andlor a patient. As will be appreciated in light of this disclosure. thecameras 136. 140. 144 and microphones 138. 142. and 146 can also be used. forexample. to allow a patient to communicate with a remote care provider andlor toconfirm the identity of a patient (e.g.. using voice andlor facial recognitiontechniques, retinal scans. etc) prior to commencing a treatment. so as to ensure theright patient receives the right treatment.

As shown in Fig. 1, in some embodiments. the monitoring client 1. themonitoring-client dock 102, and the device dock 104. each have a respectiveantenna 112. 106. and 108 for wireless communications (each of the antennas 112.106. and/or 108 is al). If the cable 110 is unplugged or the communicationsbetween the docks 102. 104 via the cable 110 is otherwise upted or impaired.the ring-client dock 102 and the device dock 104 can ue tocommunicate with each other using a wireless communications link establishedthrough the antennas 106. 108. Additionally, when the monitoring client 1 isremoved from the monitoring-client dock 102, the monitoring client 1 cancommunicate. for example. directly to the device dock 104 and/or the monitoringclient 1 can icate with the device dock 104 by wirelessly communicatingwith the monitoring-client dock 102. which relays the communications via the cable110 or via a wireless communications link between the docks 102. 104. Aspreviously mentioned. communications between the monitoring client 1 and thedevice dock 104 may be utilized by the monitoring client 1 to communicate with thes s docked to the device dock 104.

In some embodiments. the monitoring client 1 may electrically determine ifone or more electrical contacts of one or more connectors are in electricalment with the monitoring-client dock 102 to determine if the cable 110 isavailable as a communications link, e.g., by measuring a voltage or an ncebetween two electrical contacts of a connector of the monitoring client 1 used fordocking to the monitoring-client clock 102 and for providing electricalcommunication n the monitoring-client dock 102 and the monitoring client 1.

Also. the monitoring client 1 may determine the cable 110 is unavailable if thering client 1 determines it is not ically coupled to the cable 110.

Additionally or alternatively, in some embodiments, a magnet in the dock 102engages a Hall-Effect sensor in the monitoring client 1. which the ring client1 uses. in turn. to determine if it is docked such that the monitoring client 1assumes the cable 110 is unavailable as a communications link when themonitoring client 1 is undocked. Additionally or alternatively, circuitry within themonitoring-client dock 102 may signal the monitoring client 1 when the cable islable as a communications link. In some embodiments, the monitoring client1 may periodically “ping" the device dock 104 via the cable 110; if the monitoringclient does not receive a response from the device dock 104 within apredetermined amount of time, the monitoring client 1 will assume the cable 110 isunavailable as a communications link.

In the event the monitoring client 1 determines the cable 110 is unavailableas a communications link, the monitoring client 1 may issue an alarm or alert usinga speaker and/or a vibration motor. an alarm or alert signal may be sent to theremote communicator 11 to alarm or alert the remote communicator using aspeaker and/or a vibration motor. andfor the monitoring client 1 may t tocommunicate with the patient-care devices via other communications links. Theterm "alert" as used herein is intended to include “soft" alerts, such as, for example,an alert that is not brought to a person's attention until after a predeterminedamount of time has passed and the cause of the alert remains.

In some embodiments of the t disclosure, the monitoring-client dock102 includes one or more wires or waveguides from the monitoring client 1 to thecable 110 using minimal or no circuitry. For example. in some embodiments of thet disclosure, the monitoring-client dock 102 is a cradle which provides directelectrical coupling from the monitoring client 1 to the cable 110. Additionally oralternatively, in some embodiments of the present disclosure. the device dock 104includes one or more wires or waveguides to facilitate communications amongvarious docked devices and/or the monitoring client 1 via the ring-client dock102 using minimal or no circuitry. The device dock 104. in some embodiments.may be a cradle.

In an embodiment of the present disclosure, each monitoring client 1 isassigned to a specific patient 2 and may be a desk-based, portable, or hand-heldand may have a display and user input capability. The ring client 1 may beportable and can facilitate ent data viewing and data entry; the monitoringclient 1 may be a notebook PC, a netbook PC, a tablet PC, a “smart-phone,"with orwithout a touchscreen. Additionally or alternatively. in some embodiments, themonitoring client 1 andlor the remote communicator 11 may be docked or coupledto a cable that is connected to a much larger display thereby turning the muchlarger display (e.g., a 24—inch display) into the display of the monitoring client 1and/or the remote communicator 11; the much larger display may having inputcapabilities. such as touchscreen capabilities, stylus-input capabilities, keyboardinput capabilities, remote-control input capabilities. and the like that arecommunicated to the monitoring client 1 andior the remote communicator 11. Forexample, the viewing of X-ray or patient imaging files may be facilitated by dockingthe monitoring client 1 and/or the remote communicator 11 to a viewing-dockcoupled to a larger display such that the care giver can see the patient imaging fileusing the larger display. The viewing-dock may also charge the monitoring clientand/or remote communicator 11.

The monitoring client 1 may run a based operating , anAndroid-based ing system. a erry-based operatingsystem, a tablet-based operating system. iOS. an iPad 08, an iPhone OS, and the like. Thedesignation of a particular monitoring client 1 to a particular patient 2 may be madeusing any of a number of methods. ing (but not limited to) a unique patientidentifier encoded on a bar code 114 or an RFID tag 116 embedded ina wristband118. for example. The device dock 104 es a scanner 120 to determine theunique t fier of the bar code 114 or RFID tag 116. The scanner 120may be a laser barcode scanner, a COD-based barcode scanner, a near fieldcommunicator or interrogator, an RFID reader, and the like. In other embodiments.note that the unique patient identifier can be based on biometric data of the patient.

In one such example case. biometric capability (e.g.. facial and/or voice recognition.retina scan. blood type monitor. finger print scan. etc) can be embedded in orothenivise associated with the monitoring client 1. The device clock 104 cancommunicate the unique t identifier to the ring-client dock 102. themonitoring client 1. the monitoring sewer 3. the remote communicator 11, othermonitoring clients 4, another server, or an electronic computing apparatus tofacilitate the treatment of the patient 2.

The monitoring client 1 may include one or more of microprocessors.ontrollers. logic devices. digital circuitry, analog circuitry. and the like tocommunicate (e.g.. send or e) information relevant to the patient's 9 care.condition. disease. or ent. For example, the monitoring client 1 may send orreceive patient-care parameters. such as patient-condition parameters andlorpatient-treatment parameters. Some exemplary patient-condition parameters aremeasurements of blood pressure. body ature. heart rate. a pulse er.002 levels. blood oxygen . patient alertness. patient consciousness. patientresponsiveness. and the like. Some exemplarily patient-treatment parametersinclude a drug to be administrator. a flow rate of a drug or liquid. a drugadministration schedule, or other bedside treatment ter.

In some embodiments, for e. the monitoring client 1 may bephysically associated with. permanently attached to. is attachable to. is detachablefrom. or is attachably detachable from the infusion pump 7. This can beaccomplished by a docking interface between the two devices. e.g.. the monitoring-client dock 102 and the device dock 104. In one such embodiment. the monitoringclient 1 communicates with the pump 7 (or other patient-care device) in a number ofways, including. for example. through ical contacts in the docks 102, 104, bymeans of an electrical connector. or wirelessly by means of transceivers on eachdevice using a respective antenna 112. 122A. Additionally or alternatively. theinstion pump may include grammed treatment data indicating a particulartreatment for a particular patient that is uploaded to the monitoring client 1 whenthe infusion pump 7 becomes in operative communication with the monitoring clientThe ring client 1 may also communicate with one or more databasesin the facility 8, with databases external to the facility 9, 10. and/or with health careproviders using le communicators 11 (including. for example, physicians.nurses, and pharmacists). This can be accomplished by a wired connection to afacility server 8 through a connector in the patient's room (such as, for example, aCategory 5 local area network connector. USB. wired Ethernet. and the like), orwirelessly 12 (such as, for example, WiFi, 36. 4G, EVDO, WiMax. and the like). Inone embodiment. access to intra- and extra-facility ses is mediated 13through the monitoring server 3 (e.g., using middleware), which can then centralizethe software and application programming interfaces to communicate withdatabases having disparate organization, formatting, and communicationsprotocols. Thus, in an embodiment of the present disclosure, any software smay be largely limited to the monitoring server 3. reducing the maintenancerequirements on the individual monitoring s 1. 4, 11. Optionally. a monitoringclient 1 can icate with patient-treatment devices, such as an infusionpump7, to receive information about the progress of treatment (such as operatingparameters) and to provide operational instructions to the patient-treatment device.

In another embodiment, the monitoring client 1 may also communicate with patient-care devices for diagnostic or monitoring purposes to receive t-conditionparameters (such as, for example. an electrocardiographic ("ECG") monitor 14. ablood pressure (“BF") monitor 15, a pulse oximeter or 002 eter 16, or otherdevices such as temperature monitors, etc) to receive readout information from thes and potentially to instruct the devices 14, 15, 16. 17 to take a reading whendesired by a provider or by an algorithm.

In an embodiment of the present disclosure. the facility es 8 and/or thedrug e event network 9 may also include a Drug Error Reduction System("DERS"). The DERS system may e a first set of predetermined criteria totrigger soft alarms and/or a second set of predetermined criteria to trigger hardalarms. Soft alarms may be overridden (e.g,, turned off) by a ver using auser interface of an infusion pump 7 and/or a monitoring client 1 (and may be onlyan audible andlor vibratory alarm) while hard alarms cause the treatment to ceaseuntil the source of the hard alarm is removed.

In yet an additional ment of the present disclosure. the DERS systemmay include a first set of predetermined criteria defining soft limits and/or a secondset of predetermined criteria defining hard limits. The hard and soft limits definetreatment limits. such as drug dosage limits based upon size. weight. age, otherpatient parameters. or other criteria. Soft limits may be overridden by a caregiverusing a user interface of the on pump 7 andlor the monitoring client 1 to starttreatment despite that the treatment is outside of the first set of predeterminedcriteria while the hard limits prevent the treatment from starting until the settings arechanged to confirm to the second set of predetermined criteria defining the hardlimits.

As can further be seenin the example ments of Fig. 1. system 100also includes communication modules 124A—124K, each having a respectiveantenna of the antennas 122A—122K. In some embodiments. each of thecommunication modules 124A-124K is optional and/or each device may haveintegrated communications capability. Each of the communication modules 124A-124K includes a connector for coupling to a respective device. In otherembodiments. each of the communication modules 124A—124K is permanentlyintegrated with the device it is shown as being attached to in Fig. 1.

Each of the communication modules 124A-124K optionally includes one ormore eivers for ally icating over one or more wireless links toeach other. to the device dock 104. to the monitoring-client dock 102. to themonitoring client 1. to the remote icator 11. to the monitoring server 3. overthe local area network and/or wide area network (e.g.. the Internet). to a hub 802(see Fig. 8) and/or othewvise to communicate with any other device havingsufficient wireless communications capability. In some specific embodiments. theication s 124A-124K may operate. for example, as a ss meshnetwork, e.g.. using IEEE 80214.4. Zigbee, XBee. Wibree. IEEE 802.11. and thelike. In a more general sense. communication between modules 24K andother components of system 100 (e.g.. docks 102 and 104, monitoring clients1.4.11. etc.) can be implemented using any wireless communication protocol that,for example. allows for device discovery. handshaking, and/or inter-devicecommunication as bed herein. whether in a static, dynamic. or ad hoctopology (to accommodate mobility of, for example. monitoring clients 1. 4. 11andlor the various medical devices associated with the dock 104).

In other embodiments. each patient-care device may include no s ormore than two s (e.g.. communication modules). For example, each modulemay have a specific function, e.g., WiFi, and a user can select a plurality ofmodules each having a specific function and couple them together. The group ofmodules may then be applied to the patient-care device.e.g., an infusion pump.

Consider yet another example: each module may have a primary sor, abackup processor, and functional circuitry, all in operative communication with eachother. The functional circuitry may be a ss transceiver, a battery, an aceto a touchscreen or display (the y may be attached to the housing),a wireconnection, Bluetooth. Bluetooth Low , WiFi, 36, 4G. a co-processor, acontrol system (e.g., to control an infusion pump), a medication with fluidement circuitry. and the like. The selected modules may be connectedtogether, e.g., in a daisy chain. and thereafter connected to an infusion pump. Theselected modules, in this example, may be in operative communication with eachother to coordinate their action and/or function. e.g., via a CAN bus. wiredconnection. wirelessly, andlor the like.

The modules may each e a speaker and a microphone. When severalmodules are ted to together, the modules may coordinate their operationsuch that one module audibly signals a speaker while another moduleuses amicrophone to determine if the speaker is functioning properly. Several modulesmay each use their speaker on a different frequency such that any one of themodules may sense the sound via its microphone and demodulate the differentfrequencies to test several of the speakers simultaneously. The test may berequested by a first module to a second . and the second module may sendthe results from the test to the first module.

Continuing to refer to Fig. 1, one or more of the communication modules124A-124K may also optionally include one or more batteries to providepower tothe device coupled thereto. For example, the ication module 124Amay becoupled to the infusion pump 7 to provide power thereto. Other structure andonality of the communication modules 124A-124K may be included,depending on the purpose and onality of the device with which it isassociated. For instance. in some embodiments, l of infusion takes place atthe infusion pump and inputs regarding desired delivery take placeon the infusionpump; therefore, in some embodiments of the present disclosure, thecommunication module 124A implements a control thm,e.g., a proportional—integral—derivative ("PID") control loop, to control the infusion pump 7. In suchcases, the monitoring client 1 may communicate, for instance. a fluid-flow ratesignal to the communication module 124A (e.g., via a wireless link), which thenapplies a signal corresponding to the fluid-flow rate signal through electricalcontacts coupled to the motor (not explicitly shown) of the on pump 7 toachieve the desired flow rate. In some embodiments, the infusion pump 7 esone or more feedback signals from a flow-rate meter provided within the infusionpump 7 to the communication module 124A so the communication module 124Acan control the operation of the infusion pump 7 (e.g.. some aspects of theion. such as a PID control system. etc). The results may be red to themonitoring client 1 for being displayed to a user using a GUI. such as a QT-basedGUI (in some embodiments. the monitoring client 1 is a tablet). Additionally oralternatively, in some embodiments. a drip flow meter 148 can be used to wirelesslycommunicate the flow rate to the communication module 124A via thecommunication module 124K and antenna 122K associated with the drip flow meter148.

As will be appreciated in light of this disclosure. the communication modules124A-124K can be operatively d to a variety of patient-care devices 7. 14., 16, 17, 35. 126. 128, 148. For example and with further reference to Fig. 1. thecommunication module 124B is ively coupled to a syringe pump 126. and thecommunication module 124C is operatively coupled to a pill dispenser 128.

Additionally or alternatively, the communication module 124E is operatively coupledto the ECG monitor 12, the communication module 124F is operatively coupled tothe blood pressure r 15, the communication module 124G is ivelycoupled to the pulse oximeten’COZ capnometer 16, the communication module124H is operatively coupled to the other monitor 17. the communication module124i is operatively coupled to the patient's IV access 35, and the icationmodule 124K is operatively coupled to the drip flow meter 148. Each respectivecommunication module 124A-124K can provide, for instance, an appropriatecontrol system. control thm, battery power, or other functionality for itsrespective t-care device 7. 14. 15, 16, 17, 35, 126. 1.28, or 148 coupledthereto.

Additionally or alternatively. in some embodiments, the communicationmodule 124D is clocked in the device dock 104 and is operatively d to thedevice dock 104 via, for example, a bus or backplane for communicating with anydevice attached to the device dock 104, as well as for communicating withelectronic circuitry within the device dock 104. electronic circuitry within themonitoring-client dock 102, andior the monitoring client 1. Optionally, thecommunication module 1240 can provide communications for andlorpower to anydevice docked within the device dock 104, e.g., the on pump 7, the syringepump 126. the pill dispenser 128, or a microinfusion pump 130. Note thefunctionality of communication module 124D can also be integrated into the circuitryof the device dock 104 itself.

Additionally or alternatively, in some embodiments, it is al for thecommunication modules 124 to each be configured to provide a sufficient powersupply for their respective device 7. 14, 15. 18. 17, 35, 126, 128. 148 which may besupplemented by one or more wired power s, for example, a power sourceaccessible through the bus or ane within the device dock 104. As previouslyned. in some embodiments of the present disclosure, the icationmodule 124D provides sufficient power to the devices 7, 126, 128. 130. and 133.

As previously mentioned, in some embodiments, the communicationmodules 124 are each configured with power circuitry (e.g.. a voltage converter,regulator circuitry, rectification and filtering circuitry, a buck t, a boost circuit. abuck-boost circuit, a switched-mode power supply, etc.) that provides sufficientpower to the corresponding devices 7, 126, 128, and 130. In some such cases,this power try may be configurable so as to allow for provisioning of spower supply characteristics (e.g.. voltage level. maximum loadfcurrentrequirements, and NC frequency) associated with the different and diverse patient-care devices 7, 14, 15, 16, 17, 35, 126, 128. 148. Any number of powerprovisioning and management schemes will be apparent in light of this sure.

Optionally, in other embodiments of the present disclosure, a power module132 having one or more battery cells. e.g., lithium-ion battery cells, is attached tothe device dock 104 to provide sufficient power to the devices 7, 126, 128. 130, 133for the full treatment duration. Additionally or alternatively, the power module 132may be plugged into an outlet in the patient's room (generally depicted in Fig. 1 asan AC source), when available. In such cases, the outlet power can be used,where available, to power the devices in dock 104 and to charge batteries includedin the power module 132 (this may occur simultaneously); when outletpower is lostor is othenNise unavailable, the power module 132 and/or batteries within thecommunication modules 124A, 124B, 1240 can provide power to the dockeddevices.

The example system 100 may optionally include a dongle 133. The dongle133 is clocked in the device dock 104 in Fig. 1 or, in other embodiments, may beremote to the device dock 104 andfor the ring client 1. The dongle 133 canprovide a communications link or protocol for wireless devices not iseavailable. For example. as new wireless protocols, technologies, standards, andtechniques become available with the passage of time, the dongle 133 can be usedto provide a bridge, router, or repeater between the new communications protocoland translate the information transmitted under one protocol to the other protocolso that the new protocol device can communicate with the patient-care devices 7,14, 15, 17, 35, 126, 128, 130, the device dock 104, the communication module124D, the ring-client dock 102, the monitoring client 1, a hub 802 of Fig. 8,and/or other devices. The dongle 133 may retransmit the data received from thenew communications link using a wireless protocol, technology, standard, orque used by any one or more of the patient-care devices 7, 14, 15, 17, 35,126, 128, 130, the device dock 104, the communication module 124D, themonitoring-client dock 102, the monitoring client 1, the hub 802 of Fig. 8, and/orother devices in a format known or used by r one, such as, for example, themonitoring server 3 or the monitoring client 1. The dongle 133 may also provide aications bridge to cellular-based communications links, such as EVDO- orCDMA-based cellular systems.

In some embodiments, the dongle 133 may communicate patient-careparameters, e.g., patient-treatment parameters or patient-condition parameters,from one or more patient-care devices and retransmit them to the monitoring client1, the hub 802 of Fig. 8, and/or the monitoring server 3, and vice versa. Optionally,in some ments, the dongle 133 may include a wired ment connector,e.g., a RS-232 connector, and is table to a legacy device to providecommunications from the legacy device to one or more other patient-care devices,the monitoring client 1, the hub 802 of Fig. 8, and/or the monitoring server 3, andthe like. The legacy device may be, for example, a legacy patient-care device, alegacy computing device, other device using a legacy wired icationsprotocol, or the like.ally, the system 100 may also include a wearable system monitor 131for monitoring the operation of various devices, docks, monitoring clients, and/orsewers. A ring client 1, a remote communicator 11, and/or a hub 802 of Fig.8 may be used to program, interact with, andlor pair with the wearable systemmonitor 131. The wearable system monitor 131 may be worn by the patient 2 or byproviders, and multiple wearable system monitors 131 may be used. The wearablesystem monitor 131 can interrogate various devices to ensure their properoperation. For example. in one example embodiment, the wearable system monitor131 communicates with the patient-care devices 14, 15, 16, 17, 35, 126, 128, 130,the monitoring client 1, the monitoring-client dock 102, the device dock 104, and/orthe hub 802 of Fig. 8 to determine if any faults, , larities, data corruption.communication degradation, incomplete operation, slow operation, or other issuesexists.

The communications from the le system monitor 131 may eone or more interrogation signals to ine if the device being interrogated isfunctioning properly, is functioning within predetermined operating parameters,andfor is otherwise in a condition or state that is undesirable. The system monitor131 can communicate the detected condition or error to one or more devices, suchas to the monitoring server 3, the monitoring client 1 or the hub 802 of Fig. 8, toalert a provider, to initiate a shut-down procedure, andlor to te other leremedial action directed to the malfunctioning device. For example, the systemmonitor 131 can use the transceiver of the communication module 124.] forcommunicating with the monitoring client 1, the monitoring server 3 via a WiFi-router coupled to the network andfor the internet, other monitoring clients 4, otherdevices configured with a communication module 124, or with the remotecommunicator 11 to signal an alert andior alarm resulting from an abnormal orabsent interrogation response. The alert and/or alarm may cause the device toaudibly sound or visually indicate an alert and/or an alarm. In some mentsof the present disclosure, the system monitor 131 includes a call button (notexplicitly shown) for allowing the patient 2 to request a care provider, e.g., therequest is routed to the monitoring client 1 or the remote communicator 11 forvisually andlor audibly ting the request to the user in possession of thedevice.

The system monitor 131 can implement its functionality in various ways,including, for example: (1) anticipating a response to an interrogation within apredetermined amount of time; (2) incrementing a counter within the device beinginterrogated, and requesting the value of the counter from the device after beingincremented; (3) a challenge-response interrogation; and/or (4) other systemmonitoring technique or method.

As previously mentioned, in some embodiments, the system monitor 131anticipates a response to an interrogation within a predetermined amount of timeafter interrogating a patient-care device paired to the system r 131. Fore. the system monitor 131 may send a text-string message to the infusionpump 7 of "system monitor interrogation.” In this example, the infusion pump 7receives the message from the system r 131 d “system monitorinterrogation.” and processes the message using one or more processors n.

When the infusion pump 7 processes the e, a software routine thereinexecutes code that sends a response message back to the system monitor 131; forexample, the response message may be a text-string message of m monitorre5ponse" that is sent to the system monitor 131. In this example, the systemmonitor 131 may expect to receive the response message within a predeterminedamount of time, such as 2 seconds, which if the system r 131 does notreceive the response message within 2 seconds, the system monitor 131 alarmsand/or sends an alert to other devices (e.g., the system monitor 131 may broadcastan alert or error e. or may cause can alarm or alert, audibly or visually, tobe ed to the possessor via the remote communicator 11).

As previously mentioned, in some embodiments, the system monitor 131causes a counter within the device being interrogated to increment and tsthe value of the counter from the device after being incremented. For example, thesystem monitor 131 may send a request to a patient-care device. e.g.. infusionpump 7, by sending it a message, such as ”increment counter,” to the device. Thedevice's processor receives the "increment counter” e and reads a valuefrom a memory location of the device, increments the value found in the memorylocation. and stores the new value in the same memory location by ovenivriting theprevious value. Thereafter. in this example, the processor reads the new valuefrom the memory location and sends that new value to the system monitor 131,e.g., via a wireless transceiver on the device being interrogated. The systemmonitor 131, in this example, will expect a certain value from the device beinginterrogated (this expected value may be stored in a memory of the system monitor,such as, for e, in a table). For e, the system monitor 131 may havestored within its memory that a value of 48 that was previously received from the, and after requesting the value be updated within the interrogated ,expects to receive a value of 49 from the device.

Also as previously mentioned, a challenge-response interrogation may beused by the system monitor 131. For example, the system monitor 131 may sendan encrypted message to a patient-care device. The patient-care device is thentasked to decrypt the message, e.g., using an encryption key, and send themessage back to the system monitor 131. The system monitor 131 may expect theunencrypted message to return within a predetermined amount of time. In thisexample, if the system monitor 131 does not receive the response message withinthe predetermined amount of time, the system monitor 131 alarms andlor sends analert to other devices (e.g.. the system monitor 131 may broadcast an alert or alarmmessage and/or transmit them to the monitoring client 1, the monitoring server 3, tothe hub 802 of Fig. 8 or to the remote communicator 11, which in turn ys oraudibly indicates the alert or alarm).

In an embodiment of the present disclosure, the ring client 1 has they to communicate and interact directly with a health care provider using ahand-held or portable remote communicator 11 (which can be, for example, asmartphone, a tablet computer, a PDA, a laptop. or other portable computingdevice). This may be accomplished wirelessly 12. so that communications can bemaintained regardless of the patient’s location in the facility. or the provider’slocation either within or outside the ty. In one aspect, ation specific tothe patient 2 can be stored locally in the ring client 1. so that the patient'shealth care provider can access the information directly without having to accessthe monitoring server 3.

In some embodiments, ally, by incorporating appropriate safety andsecurity clearances, changes to the settings or flow parameters of a connectedinfusion pump 7 or patient—monitoring device 14-17, 35, 126, 128. 130, 148 can beaccomplished directly between a provider’s monitoring client 11 and the monitoringclient 1 (via wired or wireless communications), with ed changes also beingcommunicated to the monitoring server 3, and thence optionally to otherappropriate locations, such as the nursing n 5 andlor the pharmacy 6.

Furthermore, any new order pertaining to the patient 2 may be entered in theordering provider's remote communicator 11 (e.g., smartphone) and transmitted tothe monitoring client 1, which in turn can then notify the care giver (e.g. a nurse,nurse practitioner, doctor, physician, or other health-care sional) via the caregiver's own portable communicator 11. Additionally or alternatively, in someembodiments, the new order may also be communicated to the infusion pump 7 orpatient-monitoring device 14-17, 35, 126, 128, 130, 148 such that the controlsystem therein or coupled thereto can change its operation, e.g., setpoint, inresponse to the new order. In some embodiments, any information acquired andstored in the monitoring client 1 is periodically uploaded to the monitoring server 3and stored in a patient-specific se. Thus, if a patient's monitoring client 1 istaken out of service, a new device can be assigned to the patient 2 and quickly re-populated with the patient's current ation from the monitoring server 3.

Orders, medications, progress notes, monitoring data, ent data, patient-treatment parameters, patient-monitoring parameters, and/or operating parametersfrom the patient's attached devices may also be uploaded from the monitoring client1 to the patient's EHRs 19, any applicable remote communicators 11, the hub 802of Fig. 8 and/or the monitoring server 3 for permanent, temporary or ephemeralstorage, and/or for analysis to confirm it is in accordance with predeterminedcriteria, e.g., ranges, threshold values, and the like.

In some embodiments, the ring server 3 may se a computerthat can communicate with and provide some elements of control for a number ofmonitoring clients 1, 4, 11 in the facility 8. The monitoring server 3 may provide themonitoring s 1, 4, 11 with data extracted from a number of ses bothwithin 8 and outside 9 of the facility. In an ment of the present disclosure,the ring server 3 can interrogate the facility’s EHR system 19 for targetedinformation pertaining to a patient 2, and then populate that patient's monitoringclient 1 with a pre-defined set of information (such as, for example, the patient’sage, , weight, categories of diagnoses, current medications and medicationcategories, medication allergies and sensitivities, etc.). In accordance with onesuch example, the monitoring server 3 may establish a communication link to theEHR 19, laboratory 20, radiology 21, pharmacy 22, and/or other systems (such as,e.g., logy 23 or scheduling database 24) in the facility when, for example, amonitoring client 1 has been assigned to a patient 2. With a unique patientidentifier. the monitoring sewer 3 can obtain electronic access (permission) toreceive and send patient-specific data from and to these systems. A predetermined(but selectable) subset of the data may be downloadable into the monitoring client1's memory (not explicitly shown in Fig. 1).

The information thus acquired can then serve as a key database twhich new orders can be analyzed. Orders entered into a monitoring client 1 canbe checked for compatibility with the patient-Specific information obtained by thering server 3. Optionally. for safety redundancy, orders entered lyfrom a communicator 11 can be intercepted by the monitoring server 3 and similarlycan be checked. The monitoring server 3 may also obtain information frommedication databases residing in the ty’s pharmacy 22 or externally 9 todetermine whether a new patient order may generate an incompatibility with apatient's existing medications, for example. In an embodiment of the presentdisclosure, the monitoring server 3 may be programmed to access publiclyavailable internet sites 25 to determine whether new information pertaining to thepatient’s ordered medication should be downloaded and transmitted 13 in an alertor alarm to the patient’s health care er(s). The monitoring server 3 may alsoroute information between remote portable communicators 11 and a patient’smonitoring client 1.

In an embodiment of the present sure. the patient's physician, nursepharmacist may have access to the patient’s monitoring client 1 to relay or receivenew orders (such as medication , for example) pertaining to the patient 2,.

The monitoring client 1 or server 3 may then log the new order and relay therequest to the cist 6, and the patient’s nurse via the nurse's lecommunicator 11 and/or via a fixed terminal at the nursing station 5. A 'smartphone‘ having a ized communications application with the monitoring client1 (such as, e.g., a Google‘s Nexus One phone, Apple's iPhone, or RIM’s Blackberry08, among others) may serve as a ient portable communicator 11 forproviders who are not at a fixed location (such as at an office or remote nursingstation). A tablet PC. netbook, or laptop computer may also serve as a convenientportable communicator 11 for both portable and fixed locations. A PC may act as aconvenient communication device 11 for fixed or p locations. If a provider islocated in the patient's room, he or she may enter or receive information pertainingto the patient 2 using a direct input through a keyboard or touchscreen on thering client 1.

A monitoring client 1 can receive, process, and transmit information about aspecific patient 2 to which it has been ed or ated. The monitoringclient 1 can most conveniently be attachable or dockable to the monitoring-clientdock 102 to communicate with the infusion pump 7, or any other device to whichthe patient 2 may be connected or associated. The monitoring client 1 can be ahand-held device about the size of a wireless phone or tablet-style k, forexample. Conveniently, it may have a creen interface for use by thepatient's provider. It may also be capable of providing output to a larger narydi5play in the patient's room or at a nursing station 5 or other convenient location,either through a wired or wireless connection. Each monitoring client 1 maycommunicate with a central monitoring server 3, through which it can accesspatient data from the facility's EHR database 19, a laboratory database 20, aradiology database 21, a pharmacy se 22, or other databases in variousother facility departments. In some cases, the monitoring client 1 can uploadinformation it receives from t monitoring devices 14-17 or from provider inputsto the patient's EHR 19 via the Monitoring Server 3. Monitoring s 1.4 mayalso e information from databases outside of the facility through a monitoringserver 3 having an internet connection 25. Various external databases 9 may thusbe accessible, including various drug information databases and alert networksdealing with adverse tion-related events.

The monitoring server 3 could be arranged, for example. to manage variouslevels of external database information helpful in keeping the monitoring client 1contents as up-to-date as possible. This can be accomplished, for example, bycomparing safety and drug information d to the patient as it becomesavailable, and prioritizing for updatesidownloads on a data transfer schedule. Themonitoring clients 1.4 may also communicate either directly or through themonitoring server 3 with portable communicators 11 used by health care providerssuch as nurses, physicians and cists. In some cases, these devices canhave wired connections to the monitoring server 3 (if used, for e, in fixedlocations such as hospital pharmacies or nursing stations). In other cases, aportable communicator 11 may communicate with the monitoring server 3 throughsecure internet tions (e.g., a VPN-based internet connections, UPN, Https, aprivate key mechanism, etc.) using a computer and a wired or wireless (e.g.,Bluetooth or WiFi 802.11) connection 13 with the device 11. Alternatively, a hand-held remote communicator 11 (such as a smart-phone or tablet netbook) maycommunicate directly 12 with the facility’s monitoring client 1 via a cellularone network and/or the facility may include a private cell network that mayinclude a WiFi network (e.g., 2.4 GHz to 2.4835 GHz unlicensed ISM band, forexample).

In some embodiments, the communication link between the monitoringclients 1,4 and the monitoring server 3 may exist via an Ethernet network if widelyavailable in the facility, or via wireless transmission using one of a number ofstandards, linking all the patient-specific monitoring s 1,4 with the centralmonitoring server 3. The server 3 may then serve as a relay for communicationswith other facility servers 8, with the web-based sewers 25, and with inside ande portable communicators 11 carried by medical care ers. In someembodiments, a wireless network provides the additional onality of being ableto communicate with the monitoring server 3 no matter where in the facility thepatient 2 may be.

One method of blanketing an entire facility with wireless coverage involveshaving the facility obtain a license for a private cell-phone network. It may obtain orlease one or more micro-cellular frequencies to provide for a local icationsk throughout the ty. This arrangement can preserve communicationswhen patients and their monitoring clients 1,4 are moved from one location toanother within the facility, maintaining communications with a monitoring server 3,various in-hospital and out-of-hospital databases 8, 25, and users at fixed ns(e.g., in some embodiments, the nursing station 5 and the pharmacy 6) or with amonitoring client 11 (e.g., mobile smart-phone, laptop or tablet—type devices) eitherinside or outside the hospital. In some embodiments, this type of system providesonal security via a licensed cellular communications infrastructure. Inaddition, in some embodiments, an active wireless system can monitor the intensityof use in an area and direct onal channel frequencies to that area. r,in some embodiments, the bandwidth capacity of the networkmay not allow forefficient transmission of large data files, such as those containing radiology images,for example. Such dth-heavy data files can be communicated moreently via wired connections.atively or additionally, a hospital may implement an internet- orintranet-based communications system, in which an 802.11 WiFi-type protocol isused for wireless communications between individual monitoring clients 1,4 andmonitoring sewer 3. To ensure adequate signal reception hout the facility, abroadband antenna may be mounted on the roof of the building to collect cellphone signals from local wireless phone companies. A fiber-optic or cable networkmay then distribute the signals throughout the facility. Additionally or alternatively,the monitoring server 3 may use the private cell-phone network ned above.

Such systems typically allow for provisioning of secure ications, and arecapable of efficiently communicating large files, such as. for example, radiologyimages stored in the ogy database 21. Home or office-based users may beable to connect to the hOSpital server through, for example, VPN or other secureaccess using wired or optic cable. or a DSL phone line. Data encryption maybe used to e patient data security. In some applications it may beadvantageous to implement an asymmetric bandwidth communications networkorder to optimize infrastructure capabilities. An example of this would be usinglicensed cellular frequencies in the “upstream" direction from the monitoring client 1the monitoring server 3 and the unlicensed 802.11 WiFi frequencies in the"downstream" direction from the monitoring server 3 to the ring client 1. Inthis example, the upstream dth and data rate requirements are relativelysmall compared to the downstream requirements. In low priority upstreamtransmissions, the monitoring client 1 may allow data to be sent over a moredistributed and cost-efficient k, such as, for example, a ZigBee network, aBluetooth network, a mesh network, or the like.

As usly mentioned, communications between various monitoringdevices, such as patient-care devices 14, 15, 16, 17, 35, and the monitoring clientmay be achieved in a cost effective manner using, for example, a ZigBee wirelessmesh network and/or a Bluetooth network. Exemplary monitoring devices includeECG monitors 14, blood pressure monitors 15, pulse oximeters/capnometers 16,thermometers, and weight scales, among others. A common characteristic of mostof these devices is that they e periodic readouts of a single or small numberof parameters. An intra-hOSpital device communications system such as thewireless mesh network provides for low-power digital radio connectivity amongs, and may employ a widely available, license-free frequency band (e.g.,2.4GHz in some jurisdictions). High-level communications protocols may beemployed to ensure data fidelity and security, such as, for example, TCP. UDP, andthe like. For example, symmetrical tion keys may be used to securecommunications n the monitoring client and patient-care devices, such asthose generated for the encryption algorithms of Twofish,Serpent, AES (Rijndael),Blowfish, CASTS. RC4, SDES. lDEA, and the like. Additionally or alternatively,various data integrity techniques may be used, for example, CRO, oddparity-bitng. or even parity-bit checking, and the like.

Mesh networks are highly scalable, ngmany devices to be used on asingle orming, self-healing mesh network. Devices connected to the networkmay communicate with one another and serve as repeaters to transfer data. Meshnetwork may be vely low cost, scalable and mobile for the t beingmonitored. In some embodiments, the wirelessrange for devices linked to thewireless mesh network can approach 70 meters fromeach node of the systeminside a facility. A similar networkmay be used in providing a wireless link withinthe facility between portable communicators 11 carried by health care providersand their assigned patients through the patients' monitoringclients 1,4.

In many cases, the information being transmitted tothe monitoring client 1may include a single parameter value (such as, for example, blood pressure) andtime stamp. The monitoring client 1 can be programmed to determine whether thevalue is outside a predeterminedrange, record the value in the patient's EHR 19,and notify the appropriate provider via their monitoring client11. Furthermore, thek may enable bidirectional communications, andmay allow the monitoringclient 1 to query the patient-monitoring device (e.g., BP monitor), instructing it totake an unscheduled reading. This can be useful, for example, when an alreading is received, and its authenticity needs to be verified. The monitoring client1 may be programmed to request a repeat readingto verify the abnormal reading.

In a further embodiment, the monitoring client 1may be programmed to interrupt oradjust the on pump 7 flow rate, operating parameter, and/or treatmentparameter depending on the value of the reading received from a monitoring device14-17. For e, if the BP monitor 15 tes a blood pressure below apredetermined acceptable range. the monitoring client 1 may be programmed toinstruct the infusion pump 7 to stop the infusion, and it can transmit an urgentation 12 to the health care provider(s)’ monitoring clients 11. In anotherembodiment, if the infusion pump 7 is capable of determining the volume of fluidthe cumulative amount of fluidbeing delivered to the patient 2 (e.g., the flow rate orpumped during an interval), a processor in the monitoring client1 may track theestimate the amount of fluid remaining in thetive volume delivered and(Alternatively, a in the monitoring client 1 ormedication bag 170. processorfrom the infusion rate andon pump 7 may calculate the volume deliveredelapsed time of infusion).

Once the estimated residual volume reaches a predetermined amount,rate to keepmonitoring client 1 may signal the infusion pump 7 to reduce its flowFor example, the monitoring client 1the patient's IV access 35 from running dry.is scheduled to return at a c time to change themay determine that a nursealarm that the IV fluid will run outbag, and rather than ng andlor sending anclient 1 may signal the infusionprior to the nurse's scheduled return, the monitoringsuch that the IV bag will run out when the nursepump 7 to slow the infusion ratethe nurse's scheduled returnarrives or after a ermined amount of time fromtime. It may also send a notification to the nurse's monitoring client 11,recommending replenishment of the IV bag 17.device progresses isIn some embodiments, the operation of a patient-careclient 1 to show theindicated by an outer border on a display of the ringFor example, an outer border willstatus andlor progress of the patient-care device.of the border that lightsbe display on the monitoring client 1 such that a percentagefilled outer periphery as the border fills in) to indicateup (e.g., starts to form a fullydevice, such as thethe progress of a treatment being performed by a patient-careinfusion pump 7. The border may be transmitted in image format (e.g., JPEG,BMP, etc.) to the monitoring 1 from the infusion pump 7 and/or as a tagecompleted to the monitoring client 1. in which case monitoring client 1generates the border.

In some embodiments, a GPS andior a g module (e.g., ultrasonicranging module using time-of-flight estimations) may be installed on the infusionand/or a7, the monitoring client 1, a caregiver, patient. Predeterminedpumpe that a predetermined group of the on pump 7, thesettings mayring client 1, the hub 802 of Fig. 8, the caregiver, and/or the patient must,in a predetermined distance relative to each otherthis specific embodiment. beprior to starting treatment and/or prior to configuringone of the infusion pump 7andlor the monitoring client 1.

In some embodiments, a patient-care device7, 170, 126. 128, 130, 14, 15,16, 17, 124, or 148, a dock 102 or 104, a monitoring client1, the hub 802 of Fig. 8may send a soft alarm, hard alarm, andlor non-critical alarms to the remotecommunicator 11 without alarming on the device that issuesthe alarm and/or onthe monitoring client 1 until after a ermined amount of times haspassed (toallow a ver to find a solution to remove the cause of the alarmwithoutdisturbing a patient, for example}. If the cause of the alarm is removed prior to thepredetermined amount of time, the device that issues the alarm andlor on thering client 1 may not alarm thereby avoiding an additional disturbance of theIn some embodiments, the AC cable of Fig. 1 includes clips such that Ntubes can be clipped thereto.

IS In some embodiments, the infusion pump 7 es status LED lightsindicating one or more of: safety-checks have ; thepump is flowing; there isan occlusion; and/or the pump is being disconnected). A user can use themonitoring client 1 to read a bar code on the IV bag 170 (e.g.,using the camera144 or the camera 136, andlor thescanner 120) at which time an LEDover a plugmay flash to indicate to the user that the tube connected to the IVbag 170 shouldbe inserted therein.

In some ments, each item,component, device, patient-care ,dock, and computing device, numbered or unnumbered, as shownin Fig. 1 ordescribed therewith is optional. For e, in some embodiments, themonitoring client 1 is optional, the monitoring server 3 is optional, the facilityservices 8 is optional, each of the services 19, 20, 21,. 22. 23, 24 is optional, thecloud server 25 is optional, each of the other monitoring clients4 is optional, theonline drug databases 9 is optional, the drugadverse event network is optional, thepatient's personal EHR 19' is optional, andior the treatment outcomesdatabase 10is optional. Additionally or alternatively. in some embodiments. each of thepatient-care devices 7, 14, 15, 16, 17,35, 126, 128, 130, 148 is optional.

Likewise, each ofthe system monitor 131, the wrist band118, the RFID 116, the barcode 114, thescanner 120, the display 134. andior ACpower, is optional in some embodimentsof the present disclosure.

Additionally, in some ments, gh some items, components,devices, patient-care devices, docks, and computing devices, numbered orunnumbered, as shown in Fig. 1 or described therewith are shown as being thesole item, ent, device, patient-care device, dock or ing device,le items, components, s, patient-care devices, docks and computingdevices, are contemplated; for example, although a single infusion pump 7 isshown in Fig. 1, in some embodiments, two infusion pumps 7 may be used, multipleinfusion pumps 7 may be used, or any arbitrary number of infusion pumps 7 may beused. Additionally or alternatively, in some embodiments, multiple device docks104 and/or multiple monitoring-client docks 102 may be used.

Additionally or alternatively, although ular patient-care devices 7, 14,, 16, 17, 126, 128, 130. 148 are shown, other combinations, subsets, multipleones of a particular patient-care device, or combinations f may be used. Forexample, in some ments. only an infusion pump 7 is used of the patient-careIS devices, and, in this c example, the other patient-care devices 14, 15, 16, 17,126, 128, 130, 148 may be disabled, may not be present or available for systemuse, may be turned off, or may not be part of system 100 of Fig. 1. Additionally oralternatively, in some specific embodiments, only the patient-care devices used aredockable to the device dock 104; for example, in this specific ment, theinfusion pump 7 is the only device docked into the device dock 102 and the devicedock 102 only receives one device, e.g., the infusion pump 7. Additionally,atively, or optionally, in some specific embodiments, the patient-care devices7, 14, 15, 16, 17, 35, 126, 128, 130, 148. are dockable, may operate undocked,and/or may 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, 126,128, 130, and/or 148, the monitoring client 1, the remote communicator 11, anddocks 102 and/or 104 may include a secure data class, e.g., via an API.

Any function described with reference to Fig. 1, may be performed by thehub 802 of Fig. 8, in some embodiments.

Fig. 2 shows a flow chart diagram illustrating a method 150 for maintainingcommunications between a monitoring client, e.g., the monitoring client 1 of Fig. 1,and one or more of patient-care devices, e.g., one or more of the patient-caredevices 7, 14, 15, 16, 17, 35 126, 128, 130, 148 of Fig. 1. in accordance with anembodiment of the present disclosure. The method 150 of this example includesacts 152-169. The monitoring client 1 may y an icon indicating whencommunications are ished to the paired andlor designated patient-caredevices. The monitoring client 1 may check to determine that communications withthe paired andlor designated patient-care devices is available at predeterminedintervals, and if communications to a paired or designated patient-care device islable for a predetermined amount of time, the monitoring client 1 may soundan alarm or alert.

Act 152 determines if the monitoring-client dock is available as acommunications link n the monitoring client and the ring-client dockthrough a dock connector. If the communications link of act 152 is available, themethod 150 continues to act 154, otherwise the method 150 continues to act 156.

Act 156 determines if the monitoring-client dock Is ble as acommunications link between the monitoring-client and the monitoring-client dockthrough a wireless link. If the link of act 156 is available, the method 150 continuesIS to act 154, othenNise, the method 150 continues to act 158.

Act 154 determines if the monitoring-client dock is available as acommunications link between the monitoring-client dock and a device dock using acable. lf the communications link of act 154 is available, the method 150 uesto act 160, othenNise, the method 150 continues to the act 158. The act 160determines if the device dock is available as a communications link between thedevice dock and the patient-care device, e.g., through a wireless or wiredcommunications link. If the communications link of act 160 is ble, the method150 continues to the act 166, ise. the method 150 continues to the act 162.

The act 162 determines if the patient-care device is available as a communicationslink between the monitoring-client and a patient-care device dock through a directwireless link. If the communications link of act 162 is available, the methodcontinues to act 166, otherwise, the method 150 continues to act 164.

Act 158 determines if the device dock is available as a communications linkbetween the monitoring client and the device dock through a wireless link. If thecommunications link of act 158 is not available, the method 150 continues to act162, othenrvise, the method 150 continues to act 160.

Act 166 attempts a handshake between the monitoring client and thet-care device using the available communications link. In alternativements, no handshaking is used; for example, not all protocols useaking between ication endpoints. Decision act 168 determines ifthe handshake of act 166 was successful. If the decision act 168 determines thehandshake of act 166 was unsuccessful, then act 164 determines thatcommunication with the patient device is unavailable andlor method 150 attemptsto establish communications using other links (not explicitly shown). Othenrvise, ifdecision act 168 ines the handshake of act 166 was successful, act 169communicates data using a sufficient number of communications links inedto be available by method 150.

Method 150 is an ary embodiment of the t disclosuredescribing a method of maintaining communications between a monitoring clientand one or more patient-care devices. In some ments, although method150 includes a le of communications links, other schedules may be used,broadcasting, anycast, multicast or unicast may be used, routing algorithms may beused, a distance-vector g protocol may be used, a link-state routing protocolmay be used, an optimized link state routing protocol may be used, a path-vectorprotocol may be used, static routing with predefined alternative communicationspaths may be used. andlor adaptive networking may be used. For e, inof the present disclosure, weights may be assigned to each some embodimentscommunications path and Dijkstra's Algorithm may be used to communicatebetween the monitoring client 1 and one or more patient-care devices; the weightsmay be determined in any know way, including as a function of bandwidth, signalquality, bit-error rate, may be linear to the available data throughput or y,and/or the like.

Referring to the drawings, Fig. 3 shows a block diagram of an electronicpatient-care system 300 having two clocks 102. 104 for wireless communicationstherebetween in accordance with another embodiment of the present disclosure.

The system 300 is similar to the system 100 of Fig. 1; however. thecommunications between the monitoring-client clock 102 and the device dock 104are through a wireless link. For example. in some embodiments,~~ system 300 ofFig. 3 may be system 100 of Fig. 1 with the cable 110 of Fig. 1 absent or non-ive; additionally or alternatively, system 300 of Fig. 3 may have docks 102and 104 that are not connectable together using a cable.

Optionally, the monitoring client 1. other monitoring client 4, andlor theremote communicator 11 may be used to send commands or requests to patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148 such as for example, a bolusamount, an infusion flow rate, a total fluid for delivery, a start time for drug delivery,a stop time for drug delivery or a livery—rate profile to the infusion pump 7.the syringe pump 126 and/or the microinfusionpump 130. In some embodiments,one or more of the monitoring clients 1, 4, 11 may be used to send commands orrequests to the pill dispenser 128, such as, for example, a pill dispense commandto dispense a pill, a pill-type, a pill dispensing schedule, and/or a max pill-diapensing criteria. The max pill-dispensing criteria may be a maximum amount ofa medication that may be delivered within a ermined interval of time; fore, certain medications are taken as needed (i.e., pro re nata), however, themedication may not be safe if taken in excess and the max pill-dispensing criteriamay prevent the medication from being taken at unsafe levels by the patient,e.g., apredetermined amount during a predetermined interval of time.

In some embodiments, the remote communicator 11may be used to initiateIS two-way audio/visual communications between the remote communicator 11 andthe ring client 1 (e.g., a video call). Additionally or alternatively, themonitoring client 1 may be used to initiate two-way audio/visual communicationsbetween the monitoring client 1 and the monitoring client remote communicator 11.

Optionally, the patient-care s 7, 14, 15, 16, 17, 35, 126, 128, 130, 148may also communicate data back to the monitoring client 1, the other monitoringclient 4 and/or the remote communicator 11 for: determining if an alarm or alertshould be issued or sent; determining if the ent or condition is safe for thepatient; determining if the system 300 is operating properly or within predeterminedbounds; andlor for displaying the data on a display of the ring client 1, theother monitoring client 4 andior the remote icator 11. For example,optionally, the infusion pump 7, the syringe pump 126, and/or the microinfusionpump 130 may communicate (where applicable): upstream pressure; changes inupstream pressure; pressure ream to the t 2; changes in pressuredownstream to the patient 2; the presence or absence of air withinan infusion line;an actual bolus amount delivered; an actual infusion flow rate;an actual total fluiddelivered; an actual start time for drug delivery; an actual stop time for drugry; or an actual flow-delivery-rate profile to one or more of the monitoringclient 1, the other ring client 4 andlor the remote communicator 11. Inanother embodiment, the pill dispenser 128may optionally communicate data backto the monitoring client 1, the other monitoring client 4, and/or the remotecommunicator 11, such as for example, an actual pill‘dispensed, an actual pill-typedispensed, an actual pill dispensing schedule as dispensed, or whether or not amax pill-dispensing criteria was exceeded.

The data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126,128, 130, 148 may be analyzed for any predefined conditions to issue an alarmand/or an alert. For example, one or more of the monitoring clients 1, 4, 11 mayuse an se in pressure downstream of the infusion pump 7, the syringe pump126 and/or the microinfusion pump 130 to be an indication of one of: excessiveng, infiltration, occlusion or kinking of the tubing to the patient; or ion byother material within the IV bag 170. In response to the sudden increase indownstream pressure, one or more of the monitoring clients 1, 4, 11 may visually oraudibly alarm or alert a user. Additionally or alternatively, a sudden decrease inpressure downstream to the patient 2 may be an indication that the tubing hasbecome detached from the needle and/or the needle is now out of the patient; and,in response, one or more of the monitoring clients 1, 4, 11 may visually or audiblyalarm or alert a user. One or more of the monitoring clients 1, 4, 11 may,optionally, send a command to one or more of the on pump 7, the syringepump 126, andlor the microinfusion pump 130 to stop delivery of fluid in responseto the sudden increase and/or decrease of re downstream to the t 2.

In some embodiments, each item, ent, device, patient-care device,dock, and computing device, numbered or ered, as shown in Fig. 3 ordescribed therewith is optional. For example. in some embodiments. themonitoring client 1 is optional, the monitoring server 3 is optional, the tyservices 8 is optional, each of the es 19, 20, 21, 22, 23, 24 is optional, thecloud server 25 is optional, each of the other monitoring clients 4 is optional, theonline drug databases 9 is optional, the drug adverse event network is optional, thepatient's personal EHR 19' is optional, andior the treatment outcomes database 10is optional. Additionally or alternatively, in some embodiments, each of the t-care devices 7. 14, 15, 16, 17, 35, 126, 128, 130, 148 is optional. Likewise, each ofthe system monitor 131, the wrist band 118, the RFID 116, the barcode 114, thescanner 120, the display 134, andfor AC power. is al in some embodimentsof the present disclosure.

Additionally, in some embodiments, although some items, components,devices, patient-care devices, docks, and computing devices, numbered orered. as shown in Fig. 3 or bed therewith are shown as being thesole item, component, device, patient-care device, dock or computing device,multiple items, components, devices, t-care s, docks and computingdevices, are plated; for example. although a single infusion pump 7 isshown in Fig. 3, in some embodiments. two infusion pumps 7may be used. multipleinfusion pumps 7 may be used, or any arbitrary number of infusionpumps 7 may beused. Additionally or alternatively, in some embodiments, multiple device docks104 and/or multiple ring-client docks 102 may be used.

Additionally or alternatively, although particular patient-care devices 7, 14,, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets, multipleones of a particular patient-care device, or combinations thereof may be used. Forexample, in some embodiments, only an infusion pump 7 is used of the patient-careIS devices, and, in this specific example, the other patient-care devices 14, 15, 16, 17,126, 128, 130, 148 may be disabled, may not be present or available for systemuse, may be turned off, or may not be part of system 300 of Fig. 3. Additionally oralternatively, in some specific embodiments, only the t-care devices used aredockable to the device dock 104; for example, in one specific embodiment, theinfusion pump 7 is the only device docked into the device dock 102 and the devicedock 102 only receives one device, e.g., the infusion pump 7. Additionally,alternatively, or optionally, in some specific embodiments, the patient-care devices7, 14, 15, 16, 17, 35, 126, 128, 130, 148, are dockable, may operate ked,and/or may not be le and can operate as a stand-alone patient-care device.

In Fig. 3, although the device dock 104 is shows as being capable ofreceiving several patient-care devices, in other embodiments, the device dock 104can receive one patient-care device, a plurality of patient-care devices, or anyarbitrary number of t-care s. Also, bays of a dock may be unused, forexample, as shown in Fig. 3, empty bay 170 is shown in device dock 104.

Additionally, although the ring-client dock 102 is shown as be capable ofreceiving one monitoring client 1, in other embodiments, the monitoring-client dock102 can e two monitoring clients 1, more than two monitoring clients 1, or anyarbitrary number of monitoring clients 1.

Fig. 4 shows a flow chart diagram illustrating a method 202 for maintainingications between a monitoring client, e.g., the monitoring client 1, and oneor more of devices, e.g., the patient-care devices 7, 14, 15, 16, 17, 35 126, 128,130, 148 of Fig. 3 in accordance with an ment of the present disclosure.

Act 204 determines if the monitoring-client dock is available as acommunications link between the monitoring client and the monitoring-client dockthrough a dock connector. If the communications link of act 204 is available, themethod 202 continues to act 206, otherwise the method 202 ues to act 208.

Act 208 determines if the monitoring-client dock is available as a communicationslink between the monitoring client and the monitoring-client dock through a wirelesslink. If the communications link of act 208 is available, the method 202 continues toact 206, vise, the method 202 continues to act 210.

Act 206 determines if the monitoring-client dock is available as acommunications link between the monitoring-client dock and a device dock throughIS a wireless link. If the communications link of act 206 is available, the method 202continues to act 212, othenivise, the method 202 continues to act 210.

Act 210 determines if the device dock is available as a communications linkbetween the monitoring client and the device dock through a wireless link. If theications link of act 210 is available, the method 202 ues to act 212,othenivise, the method 202 continues to act 214.

Act 212 determines if the device dock is available as a communications linkbetween the device dock and the patient-care device. If the communications link ofact 212 is available, then method 202 continues to act 216, othenivise, the method202 continues to act 214.

Act 214 determines if the patient-care device is available as acommunications link between the monitoring client and the patient-care devicethrough a direct wireless link. If the communications link of act 214 is available, themethod 202 continues to act 216, othenivise, act 218 determines thatcommunication with the patient-care device is unavailable.

Act 216 attempts a handshake between the ring client and thet-care device using the available communications link(s). In alternativements, no handshake is attempted; for example, some communicationprotocols do not e handshaking. Decision act 220 determines if the handshakewas successful and communications n the monitoring client and the devicehave been established. If act 220 ines a communications link has beenestablished, the method 202 communicates data between the monitoring client andthe device during act 222 using the available communications ). If decisionact 22!) determines the handshake was not successful, either method 202determines that communication with the device is unavailable in act 218or method202 attempts communications between the monitoring client h untriedcommunication links (not explicitly shown).

Method 202 is an exemplary embodiment of the present disclosuredescribing a method of ining communications between a monitoring clientIO and one or more patient-care devices. In some embodiments, although method202 includes a schedule of communications links. other schedules may be used,broadcasting, anycast, multicast or unicast may be used, routing algorithms may beused, a ce-vector routing ol may be used, a link-state routing protocolmay be used, an optimized link state routing protocol may be used, a path-vectorprotocol may be used, static routing with predefined alternative communicationspaths may be used, and/or adaptive networking may be used. For example, insome ments of the present disclosure, weights may be assigned to eachcommunications path and Dijkstra's Algorithm may be used to communicatebetween the monitoring client 1 and one or more patient-care s; the weightsmay be determined in any know way, including as a function of bandwidth, signalquality, ror rate, may be linear to the available data throughput or y,andlor the like.

Referring now the Fig. 5, an electronic patient-care system 500 in blockdiagram form is shown having a dock 502 for docking together a monitoring client 1and various patient-care devices (e.g., patient—care devices 7, 126, 128, or 130), acommunication module 1240, and a dongle 133 in ance with yet anotherembodiment of the present disclosure. The electronic patient-care system 500 ofFig. 5 is similar to the electronic patient-care system 100 of Fig. 1; r, each ofthe monitoring client 1, the patient-care devices 7, 126, 128, 130, a communicationmodule 1240, and a dongle 133 are all dockable to a dock 502. As will beappreciated in light of this disclosure, the dock 502 may include one or more buses,backplanes, communications paths, electronic circuitry, and the like to facilitatecommunications.

Optionally, the ring client 1, other monitoring client 4, and/or theremote communicator 11 may be used to send commands or requests to patient-care devices 7, 14, 15, 16. 17, 35, 126, 128, 130. 148 such as for example, a bolusamount, an infusion flow rate, a total fluid for ry. a start time for drug delivery,a stop time for drug delivery or a flow-delivery-rate profile to the infusion pump 7,the syringe pump 126 and/or the microinfusion pump 130. In some embodiments.one or more of the monitoring clients 1. 4, 11 may be used to send commands orrequests to the pill dispenser 128, such as, for e, a pill dispense commandto dispense a pill, a pill-type, a pill dispensing schedule, and/or a max pill-dispensing ia. The max pill-dispensing criteria may be a maximum amount ofof time; fora medication that may be delivered within a predetermined intervale, certain medications are taken as needed (i.e., pro re nata), however, themedication may not be safe if taken in excess and the max pill-dispensing criterialevels by the patient. e.g., amay prevent the medication from being taken at unsafepredetermined amount during a predetermined interval of time.

Optionally, the patient-care devices 7, 14. 15, 16, 17, 35, 126, 128, 130. 148clientmay also communicate data back to the monitoring 1, the other monitoringclient 4 and/or the remote communicator 11 for: determining if an alarm or alertshould be issued or sent; determining if the ent or condition is safe for thet; determining if the system 500 is operating properly or within predeterminedbounds; and/or for displaying the data on a display of the monitoring client 1, theother monitoring client 4 and/or the remote communicator 11. For example,Optionally. the infusion pump 7, the syringe pump 126, andlor the microinfusionpump 130 may communicate (where applicable): upstream pressure; changesupstream pressure; pressure downstream to the patient 2; changes in redownstream to the patient 2; the presence or absence of air within an infusion line;fluidan actual bolus amount delivered; an actual on flow rate; an actual totaldelivered; an actual start time for drug delivery; an actual stop time for drugdelivery; or an actual flow-delivery-rate profile to one or more of the monitoringclient 1, the other monitoring client 4 andlor the remote icator 11. Inanother embodiment, the pill dispenser 128 may optionally communicate data backto the monitoring client 1. the other monitoring client 4. and/or the remotecommunicator 11, such as for example, an actual pill dispensed, an actual pill-typedispensed, an actual pill dispensing schedule as dispensed, or whether or not amax pill-dispensing criteria was exceeded.

The data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126,128, 130, 148 may be analyzed for any predefined conditions to issue an alarmand/or an alert. For example, one or more of the monitoring clients 1, 4, 11 mayuse an increase in re downstream of the infusionpump 7, the syringe pump126 and/or the nfusion pump 130 to be an indication of one of: excessiveclotting, infiltration, occlusion or g of the tubing to the patient; or occlusionother material within the N bag 170. In response to the sudden increase indownstream pressure, one or more of the monitoring s 1, 4, 11 may visually oraudibly alarm or alert a user. Additionally or alternatively, a sudden decrease inpressure downstream to the patient 2 may be an indication that the tubing hasbecome detached from the needle and/or the needle isnow out of the patient; and,in response, one or more of the ring clients 1, 4, 11 may visually or audiblyalarm or alert a user. One or more of the monitoring clients 1, 4, 11 may,optionally, send a command to one or more of the infusion pump 7, the syringepump 126, and/or the microinfusion pump 130 to stop delivery of fluid in responseto the sudden increase and/or decrease ofpressure downstream to the patient 2.in some embodiments. each item, component, device, patient-care ,dock, and computing device, numbered or unnumbered, as shown in Fig. 5 orbed therewith is optional. For example, in some embodiments, thering client 1 is optional, the monitoring server 3 is optional, the facilityservices 8 is Optional, each of the services 19, 20, 21, 22, 23, 24is optional, thecloud server 25 is optional, each of the other monitoring s 4is optional, theonline drug databases 9 is optional, the drug adverse eventnetwork is Optional, thepatient's personal EHR 19' is optional. andior the treatment es database 10is optional. Additionally or alternatively, in some embodiments, each of the patient-care devices 7. 14, 15, 16, 17, 35, 126, 128, 130, 148 is Optional. Likewise, each ofthe system monitor 131, the wristband 118, the RFlD116, the barcode 114, thescanner 120, the display 134, andi'or AC power, is optional in some mentsof the present disclosure.

Additionally, in some ments, although some items, components,devices, patient-care devices, docks, and computing devices, numbered orunnumbered, as shown in Fig. 5 or described therewith are shown as being thesole item, component, device, patient-care device. dock or computing device,multiple items, components, devices, patient-care devices, docks and ings, are contemplated; for example, although a single infusion pump 77 may be used, multipleshown in Fig. 5, in some embodiments, two infusion pumpsof infusion pumps 7 may beinfusion pumps 7 may be used, or any arbitrary numberused. Additionally or alternatively, in some embodiments, multiple docks 502 maybe used.particular patient-care devices 7, 14,onally or alternatively, althoughmultiple, 16, 17, 126, 128, 130, 148 are shown, other combinations, subsets,to or combinations thereof may be used.ones of a particular patient-care device,7 is used of the patient-careexample, in some embodiments, only an infusion pump16, 17,devices, and, in this specific e, the other t-care devices 14, 15,available for system126, 128, 130, 148 may be ed, may not be present orbe part of system 500 of Fig. 5. Additionally oruse, may be turned off, or may nots used arealternatively, in some specific embodiments, only the patient-caredockable to the dock 502; for example, in one specific embodiment, the infusiondocked into the device dock 102 and the device dock 102pump 7 is the only deviceonly receives one device, e.g., the infusion pumpAdditionally, atively, ordevicesin some specific embodiments, the patient-care 7, 14, 15, 16,ally,and/or may not17, 35, 126, 128, 130, 148, are dockable, may operate undocked,device.be dockable and can e as a stand-alone patient-careIn Fig. 5, although the dock 502 is shows as being capable of receivingseveral patient-care devices, in other embodiments, the dock 502 can receive onenumber ofpatient-care device, a plurality of patient-care devices. or any arbitraryfor example, as shownpatient-care devices. Also, bays of a dock may be unused,in Fig. 5, empty bay 170 is shown in dock 502. Additionally, gh the dock 502clientis shown as be capable of receiving one ring 1, in other ments,the dock 502 can receive two monitoring clients 1, more than two monitoring clients1, or any arbitrary number of monitoring clientsFig. 6 is a flow chart diagram illustrating a method 304 for maintainingclient 1 of Fig. 5,communications between a monitoring client, e.g., the monitoringdevices 7, 14, 15, 16, 17, 35and one more patient-care devices, e.g., patient care126, 128, 130, 148 of Fig. 5 in accordance with an embodiment of the presentdisclosure.

The method determines if the dock is available as a communicationslinkbetween the monitoring client and the dock through a dockconnector during act306. If the communications link of act 306 is not available, method304 continuesto act 308, othenlvise, the method 304continues to act 310. Act 310 determines ifthe dock is available as a communications link betweenthe dock and the patient-care device. If the communications link of act 310is not available, the method 304continues to act 312. othenivise, the method 304continues to act 314.

Act 308 determines if the dock is available as a communications linkbetween the monitoring client and the dock through a wireless link. If thecommunications link of act 308 is available, the method304 continues to act 310,,vise, the method 304 continues to act 312.

Act 312 determines if the patient-care device is available as aications link between the ring client and the patient-care devicethrough a direct wireless link. If the communications link of act 312is unavailable,act 316 ines that communication betweenthe monitoring client and thepatient-care device is unavailable.

Act 314 attempts a handshake betweenthe monitoring client and the deviceusing the available communications link(s). In alternative embodiments, nohandshaking is utilized; for example. some protocols do notemploy handshaking.

Decision act 318 determines if the handshake was successful, and if it wassuccessful, method 304 continues to act 320 to communicate data using theble communications link(s). if the decision act 318 determines thehandshakewas essful in act 314, act 316 ines that communication with thedevice is unavailable. In other embodiments, if decision act 318 determines thehandshake was unsuccessful in act 314, method304 attempts to communicate withthe patient—care device via untriedcommunications links (not explicitly shown).

Method 304 is an ary embodiment of the present disclosuredescribing a method of maintaining communications betweena monitoring clientand one or more patient-care devices.

In some embodiments, ghmethod304 includes a le of communicationslinks, other schedules may be used,broadcasting, anycast, multicast or unicast may be used,routing algorithms may beused, a distance-vector routing protocolmay be used, a tate routing protocolmay be used, an optimized link state g protocolmay be used, a path-vectorprotocol may be used, static routing with predefined ative communicationspaths may be used, and/or adaptive networking may be used. For example, insome embodiments of the present disclosure, weights may be assigned to eachcommunications path and Dijkstra’s thm may be used to communicatebetween the monitoring client 1 and one or more patient-care devices; the weightsmay be ined in any know way, including as a function of bandwidth, signalquality, bit-error rate, may be linear to the available data throughput or latency,and/or the like.

Turning now to Fig. 7, a block diagram is shown of an electronic patient-caresystem 700 having a monitoring client 1 with an integrated dock 702 for dockingpatient-care devices 7, 126. 128, 130 thereto in accordance with yet anotherembodiment of the present disclosure. Additionally in some embodiments, aication module 124D. and a dongle 133 are all dockable to the dock 702.

The patient-care system 700 of Fig. 7 is similar to the patient-care system 100 ofFig. 1; however. the patient-care system 700 includes the integrated dock 702. Insome embodiments, the monitoring client 1 communicates with a patient-caredevices when it is docked via the dock; however. if the monitoring client 1 cannotcommunicate with a patient-care device. e.g., t-care devices 7, 14, 15, 16.17, 35, 126. 128. 130, 148. the monitoring client 1 can icate with itwirelessly. e.g., using the antenna 112 of the monitoring client 1.

Optionally, the monitoring client 1, other monitoring client 4, and/or theremote communicator 11 may be used to send commands or ts to patient-care devices 7, 14, 15, 16, 17. 35, 126, 128, 130, 148 such as for example, a bolusamount, an infusion flow rate, a total fluid for delivery, a start time for drug delivery,a stop time for drug delivery or a flow-delivery-rate profile to the infusion pump 7,the syringe pump 126 and/or the nfusion pump 130. In some ments,one or more of the ring clients 1, 4, 11 may be used to send commands orrequests to the pill dispenser 128, such as, for example, a pill dispense commandto dispense a pill. a pill-type, a pill dispensing schedule, and/or a max pill-dispensing criteria. The max pill-dispensing ia may be a maximum amount ofa medication that may be delivered within a predetermined interval of time; forexample, certain medications are taken as needed (i.e., pro re nata). however, thetion may not be safe if taken in excess and the max pill-dispensing criteriamay prevent the tion from being taken at unsafe levels by the patient, e.g., apredetermined amount during a predetermined interval of time.

Optionally, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148may also communicate data back to the monitoring client 1, the other monitoringclient 4 and/or the remote communicator 11 for: determining if an alarm or alertshould be issued or sent; determining if the treatment or conditionis safe for thepatient; determining if the system 700 is Operating properly or within predeterminedbounds; and/or for displaying the data on a display of the monitoring client 1, theother monitoring client 4 andlor the remote communicator 11. For example,optionally, the on pump 7, the syringe pump 126, and/or the microinfusionpump 130 may communicate (where applicable): upstream re; changes inupstream re; pressure ream to the patient 2; changes in pressuredownstream to the patient 2; the ce or absence of air withinan infusion line;an actual bolus amount delivered; an actual infusion flow rate;an actual total fluiddelivered; an actual start time for drug delivery; an actual stop time for drugdelivery; or an actual flow-delivery-rate profile to one or more of the monitoringclient 1, the other monitoring client 4 andlor the remote communicator 11. Inanother embodiment. the pill dispenser 128 may optionally communicate data backto the monitoring client 1, the other ring client 4, and/or the remotecommunicator 11, such as for example, an actual pill dispensed, an actual pill-typedispensed, an actual pill dispensing schedule as dispensed, or whether or not amax pill-dispensing criteria was exceeded.

The data received from the patient-care devices 7, 14, 15, 16, 17, 35, 126,128, 130, 148 may be analyzedfor any predefined conditions to issue an alarmandlor an alert. For example, one or more of the monitoring clients 1. 4. 11 mayuse an increase in re downstream of the onpump 7. the syringe pump126 and/or the microinfusionpump 130 to be an indication of one of: excessiveclotting, infiltration, occlusion or kinking of the tubing to the patient; or occlusion byother material within the IV bag 170. In response to the sudden increase inream pressure, one or more of the monitoring clients 1, 4, 11 may visually oraudibly alarm or alert a user. Additionally 0r alternatively, a sudden decrease inpressure downstream to the patient 2 may be an indication that the tubing hasbecome detached from the needle and/or the needle isnow out of the patient; and,in response, one or more of the ring clients 1, 4, 11 may visually or audiblyalarm or alert a user. One or more of the ring clients 1, 4, 11 may,optionally, send a command to one or more of the infusion pump 7, the syringe130 to st0p delivery of fluid in responsepump 126, and/or the microinfusion pumpthe patient 2.to the sudden increase and/or decrease of pressure downstream toIn some embodiments. each item, component. device. patient-care device,dock, and ing device. ed or ered. as shown Fig. 7 ordescribed therewith is Optional. For example. in some embodiments.monitoring client 1 is optional, the monitoring server 3 is optional, the tyservices 8 is optional, each of the services 19, 20, 21, 22. 23, 24 is al. thecloud server 25 is al. each of the other monitoring clients 4 is optional, theonline drug ses 9 is optional, the drug adverse event network is optional.patient's personal EHR 19' is optional. andior the treatment outcomes database 10is optional. Additionally or alternatively. in some embodiments, each of the patient-Likewise. each ofcare devices 7, 14, 15, 16, 17. 35, 126, 128. 130. 148 is optional.the system monitor 131. the wrist band 118, the RFID 116. the barcode 114, thein some embodimentsscanner 120, the display 134, andior AC power. is optionalof the present disclosure.

Additionally, in some embodiments. although some items, components.numbereddevices. patient-care devices. docks, and computing devices, orunnumbered, as shown in Fig. 7 or described therewith are shown as being thesole item, component, device, patient-care , dock or computing device,multiple items, components, devices. patient-care devices, docks and computingdevices, are contemplated; for example, although a single infusion pump 7be used. multipleshown in Fig. 7. in some embodiments, two infusion pumps 7 may7 may beinfusion pumps 7 may be used. or any arbitrary number of infusion pumpsused. Additionally or alternatively, in some embodiments, integrated docks 702may be used.

Additionally or alternatively. although ular t-care devices 7, 14., 16. 17, 126, 128, 130, 148 are shown. other combinations, subsets, lethereof may be used. Forones of a particular patient-care device, or combinationsexample, in some embodiments, only an infusion pump 7 is used of the patient-caredevices, and. in this specific example, the other patient-care devices 14, 15, 16. 17. 30126, 128. 130, 148 may be disabled, may not be t or available for systemof system 700 of Fig. 7. Additionally oruse, may be turned off. or may not be partalternatively. in some specific ments, only the patient-care devices used aredockable to the integrated dock 702; for example. in one specific embodiment, theinfusion pump 7 is the only device docked into the integrated dock 702 and theintegrated dock 702 only receives one device, e.g., the infusion pump 7.

Additionally, alternatively, or optionally, in some specific embodiments, the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148, are dockable, may operateundocked, and/or may not be le and can Operate as a stand-alonepatient-care device.

In Fig. 7. although the integrated dock 702 is shows as being capable ofreceiving several patient-care devices, in other embodiments, the integrated dock702 can e one patient-care device, a plurality of patient—caredevices, or anyarbitrary number of patient-care s. Also, bays of a dockmay be unused, forexample, as shown in Fig. 7, empty bay 170 is shown in integrated dock 702.

Additionally, although the integrated dock 702 is shown as having one integratedmonitoring client 1, in other embodiments, the integrated dock 702 has twointegrated monitoring clients 1, more than two integrated monitoring clients 1, orany arbitrary number of integrated ring clients 1.

Fig. 8 is a block diagram of an electronic patient-care system 800 having ahub 802 in ance with yet another embodiment of the present sure.

Optionally, in some embodiments, the hub 802 provides a communicationsinterface between the monitoring-client dock 102 and device docks804, 806. In yetadditional embodiments, the hub 802 controls the patient-care devices withoutmonitoring client 1, other monitoring client 4, and/or a remote communicator 11.

For example, the hub 802 may communicate with themonitoring server 3, thety services 8, the nursing station 5, the pharmacy 6, the cloud server 25, theonline drug databases or drug e event network 9, a patient's personal EHR19', and/or the treatment outcomes database 10. The hub 802may provide a clocksuch that all devices connected thereto use the hub's 802 clock (e.g.,patient-caredevices, ring s, remote communicators, etc), real-time devicesuse thehub's 802 clock, or time-critical devices use the hub's 802 clock.

In some embodiments, a GPS andior a ranging module (e.g., ultrasonicranging module) may be installed on the infusion pump 830, the monitoring clientthe hub 802, a caregiver, andlor a patient. Predetermined settings may require thata predetermined group of the infusion pump 830, the ring client1, the hub802, the caregiver, and/or the patient must, in this specific embodiment, be in apredetermined distance relative to each other prior to starting treatment and/orpriorto configuring one of the infusion pump 830, the hub 802, and/or the monitoringclient 1.

In some embodiments, the hub 802 includes an Application ProgrammingInterface (API) to display GUls. windows, data, etc. on the monitoring client 1and/or the remote communicator 11. The API may include a secure data class. Inyet additional embodiments, the docks 102, 804 and/or 806 include an API todisplay GUIs. windows, data, etc. on the monitoring client 1 or remotecommunicator 11. In yet an additional embodiment. the docks 102, 804, or 806, orthe hub 802 includes an API to display GUls, windows, data, etc. on a patient-caredevice 830, 810, and/or 814.

In some embodiments. the hub 802 and/or the docks 102. 804 and/or 806may identify the type of t-care device associated ith and loadconfiguration data based upon the type of the associated t-care device (adevice paired o, a device plugged in or docked to the hub 802 and/or thedocks 102, 804, and/or 806).

In some embodiments. the hub 802 and/or the docks 102, 804 and/or 806may identify the type of patient-care device ated therewith and configure ausing htmI, CSS, JavaScript. Etc. In some embodiments, the hub 802 andlor thedocks 102, 804 and/or 806 may have a distributed Ul system.

The user interface described herein may utilize a request-action framework.

Optionally. in some specific embodiments. the hub 802 includes all of thesafety-critical try and software for communicating with the monitoring client 1;for example. in this specific embodiment, the hub 802 receives treatmentparameters from the monitoring client 1, and the hub 802 ensures the treatmentparameter is safe for the patient 2 independent of the any safety check performedere, for example, on the monitoring client 1. In yet an additional specificembodiment. system 800 is, optionally, wholly tolerant of the monitoring client1, and may ignore commands, requests, or parameters from the monitoring client 1when. for example, independent safety checks med therein does not satisfypredetermined criteria, for example, predetermined safe ranges of drug delivery ofan infusion pump 7.

Optionally, in yet onal specific embodiments, a barcode attached to theIV bag 170 may be scanned by the scanner 120, which downloads a predeterminedprescription (e.g., from the patient’s personal EHR19') and/or an infusion pump 830includes a predetermined prescription that is uploaded into the hub 802 when it isdocked to the dock 804; thereafter, in this specific embodiment and optionally. thehub 802 initiates infusion of the N bag 170 into the patient 2 and monitors theprogress of the treatment to ensure the patient's 2 safety. onally,alternatively, or optionally, in this Specific embodiment. a caregiver may interactwith system 800 as shown in Fig. 8 exclusively via the hub 802. Optionally, insome ments. the hub 802 uploads ent, status, or patient informationto the monitoring client 1; for example. the hub 802 may upload treatmentinformation it es from the infusion pump 830 or treatment information itreceives from the patient's personal EHR 19' corresponding to a scanned barcodeon the N bag 170, to the monitoring client 1 for y to a user. for confirmation ofthe information by the user, for storage within the ring client 1, and the like.

In some embodiments, the device dock 804 receives infusionpumps 830,810, and 812. in some embodiments, the device dock 804 receives,one, moreIS than one, or a plurality of patient-care devices. Device dock 806 receives a pilldispenser 814. In some embodiments, the device dock 806 receives. one, morethan one, or a plurality of patient-care s, such as pill dispensers 806. Thedevice dock 804 includes an antenna 816 for wireless communications, and thedevice dock 806 includes an antenna 818 for wireless communications. se.the hub 802 includes an antenna 820 for ss ications. Additionally oralternatively, the device dock 804, the hub 802, andlor the monitoring client 1communicate with each other using wired connections. Each of the hub 802, andthe docks 804 and 806 may communicate with each other using, for example, aUSB cable, an Ethernet cable, andlor via a wireless link. Optionally, the hub 802may include additional ories, such as a display 822, a camera 824, amicrophone 826, a scanner 120, an ableldetachable display (not shown), andthe like. As previously mentioned, the hub 802 may provide all patient safety-critical functions and may operate independently of the monitoring client 1 and/orthe monitoring-client dock 102.

Optionally, the monitoring client 1, other monitoring client 4, and/or theremote communicator 11 may be used to send commands or requests to patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814, 830 148 such as for example,a bolus amount, an infusion flow rate, a total fluid for delivery, a start time for drugdelivery, a stop time for drug delivery or a flow-delivery—rate profile to one or moreof the infusion pumps 830, 810, 812. In some ments, one or more of themonitoring clients 1, 4, 11 may be used to send commands or requests to the pilldispenser 814, such as, for example, a pill dispense command to dispense a pill, apill-type, a pill dispensing schedule, and/or a max pill-dispensing ia. The maxpill-dispensing criteria may be a maximum amount of a tion that may bedelivered within a predetermined interval of time; for e, certain medicationsare taken as needed (i.e., pro re nata), however, the medication may not be safe iftaken in excess and the max pill-dispensing criteria may prevent the medicationfrom being taken at unsafe levels by the patient, e.g., a predetermined amountduring a predetermined interval of time.

Optionally, the patient-care devices 14, 15, 16, 17, 35, 830, 810, 812, 814,830, 148 may also communicate data back to the ring client 1, the othermonitoring client 4 andlor the remote communicator 11 for: determining if an alarmor alert should be issued or sent; determining if the treatment or condition is safe forthe patient; determining if the system 800 is operating properly or withinpredetermined bounds; andlor for displaying the data on a display of the monitoringclient 1, the other monitoring client 4 and/or the remote communicator 11. Forexample, optionally, one or more of the infusion pumps 830, 810, 812 maycommunicate (where applicable): upstream pressure; changes in upstreampressure; pressure ream to the t 2; changes in pressure downstreamto the patient 2; the presence or absence of air within an infusion line; an actualbolus amount delivered; an actual infusion flow rate; an actual total fluid delivered;an actual start time for drug delivery; an actual stop time for drug delivery; or anactual flow-delivery-rate profile to one or more of the monitoring client 1, the othermonitoring client 4 and/or the remote communicator 11. In another ment,the pill dispenser 814 may optionally communicate data back to the monitoringclient 1. the other monitoring client 4, andlor the remote icator 11, such asfor example, an actual pill dispensed, an actual pill-type dispensed, an actual pilldispensing schedule as dispensed, or whether or not a max pill-dispensing criteriawas exceeded.

The data ed from the patient-care devices 14, 15, 16, 17, 35, 830, 810,812, 814, 830, 148 may be analyzed for any predefined ions to issue analarm andlor an alert. For example, one or more of the monitoring clients 1, 4, 11may use an increase in pressure downstream of one or more of the infusion pumps830, 810, 812 to be an indication of one of: excessive clotting, infiltration, occlusionor kinking of the tubing to the patient; or ion by other material within the IVbag 170. In response to the sudden increase in reampressure. one or moreof the monitoring clients 1, 4, 11 may ly or audibly alarm or alert a user.

Additionally or atively, a sudden decrease in pressure downstream to thepatient 2 may be an indication that the tubing has become detached from theneedle and/or the needle is now out of the t; and, inresponse, one or more ofthe monitoring clients 1, 4, 11 may visually or audibly alarm or alert a user. One ormore of the monitoring clients 1, 4, 11 may, Optionally, send a command to one ormore of the infusion pumps 830, 810, 812 to stop delivery of fluid inresponse to thesudden increase andlor decrease of pressure downstream to the patient 2.in some embodiments, each item, component, device, patient-care device,dock, and computing device, numbered or unnumbered, as shown in Fig. 8 ordescribed therewith is optional. For example, in some embodiments, the[5 monitoring client 1 is optional, the monitoring server 3 is optional, the facilityservices 8 is optional, each of the services 19, 20, 21, 22, 23, 24 is Optional, thecloud server 25 is optional, each of the other monitoring clients 4 is optional, theonline drug databases 9 is Optional, the drug adverse event network is optional,patient's al EHR 19’ is optional, and/or the treatment outcomes database 10is optional. Additionally or alternatively, in some embodiments, each of the patient-care devices 830, 810, 812 is al. Likewise, each of the system monitor 131,the wrist band 118, the RFID 116, the barcode 114, the scanner 120, the display808, and/or AC power, is optional in some embodiments of the present disclosure.

Additionally, in some embodiments, gh some items, components,devices, patient-care devices, docks, and computing devices, numbered orunnumbered, as shown in Fig. 8 or described therewith are shown as being thesole item. component, device, patient-care device, dock or computing device,multiple items, components. s, patient-care devices, docks and computingdevices, are contemplated; for example, although a single pill dispenser 814 isshown in Fig. 8, in some embodiments, two pill dispensers 814 may be used,le pill sers 814 may be used, or any ary number of pill dispensers814 may be used. Additionally or atively, in some embodiments, multipledocks 804 or 806 and/or multiple monitoring-client docks 102may be used.

Additionally or alternatively, although particular patient-care devices 830,810, 812 are shown, other combinations, subsets. multiple ones of a particularpatient-care device, or combinations thereof may be used. For example, in someembodiments, only an infusion pump 830 is used of the patient-care devices, and,in this specific example, the other patient-care devices 810, 812, 814 may bedisabled, may not be present or available for system use, may be turned off, or maynot be part of system 800 of Fig. 8. Additionally or alternatively, in some specificembodiments, only the patient-care devices used are dockable to dock 804 or 806;for example, in one specific embodiment, the infusion pump 830 is the only devicedocked into the dock 804 and the dock 804 only receives one device, e.g., theinfusion pump 830.

In Fig. 8, although the dock 804 is shows as being e of receivingseveral patient-care devices, in other embodiments, the device dock 804 canreceive one patient-care device, a plurality of patient-care devices, or any arbitrarynumber of patient-care devices. Also, bays of a dock may be unused (not shown inFig. 8). onally, although the monitoring-client dock 102 is shown as becapable of receiving one monitoring client 1, in other embodiments, the ring-client dock 102 can receive two ring clients 1, more than two ringclients 1, or any arbitrary number of monitoring clients 1. Additionally, alternatively,or optionally, in some specific embodiments, the patient-care devices 14, 15, 16,17, 35, 830, 810, 812, 814 are dockable, may operate undocked, andlor may notbe dockable and can operate as a stand-alone patient-care device.

System 800 of Fig. 8 may use any known ications method toin communications ithin. For example, in some embodiments, anyschedule of communications may be used, broadcasting, anycast, multicast orunicast may be used, routing algorithms may be used, a distance-vector routingol may be used. a link-state routing protocol may be used, an optimized linkstate routing protocol may be used, a path-vector protocol may be used, staticrouting with predefined alternative communications paths may be used, and/oradaptive networking may be used. For e. in some ments of thepresent disclosure, weights may be assigned to each communications path andra’s Algorithm may be used to communicate between the ring client 1or the hub 802 and one or more patient-care devices (e.g., patient-care devices830, 810, 812, and 814); the weights may be determined in any know way,including as a function of bandwidth, signal quality, ror rate, may be linear tothe available data hput or latency, andior the like.

In an ment of the present sure. the facility services 8 and/or thedrug adverse event network 9 may also e a Drug Error Reduction System(”DERS"). The DERS system may include a first set of predetermined criteria totrigger soft alarms and/or a second set of predetermined criteria to trigger hardalarms. Soft alarms may be overridden (e.g., turned off) by a ver using auser interface of the infusion pump 830. the user interface 808 of the hub 802,and/or the user interface of the monitoring client 1 (and may be only an audibleandlor vibratory alarm) while hard alarms cause the treatment to ceaseuntil thesource of the hard alarm is removed.

In yet an additional embodiment of the present disclosure, the DERSsystemmay include a first set of predetermined ia defining soft limits andIor a secondset of predetermined criteria defining hard limits. The hard and soft limits definetreatment limits. such as drug dosage limits based upon size, weight, age. otherpatient parameters, or other criteria. Soft limits may be overridden by a caregiverusing a user interface of the infusion pump 830, the user interface of the monitoringclient 1. andfor the user ace 808 of the hub 802 to start treatment despite thatthe treatment is outside of the first set of predetermined criteria while the hardlimitsprevent the treatment from starting until the settings are changed to confirm to thesecond set of predetermined criteria defining the hard limits.

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

Referring again to the drawings, Fig. 9 shows a block diagram of anelectronic t-care system 900 having a stackable monitoring client 902, able infusion pump 904. a stackable syringe pump 906, and another stackablepatient-care device 908 in accordance with yet another embodiment of the presentdisclosure. The stackable devices 902-908may communicate using a backplaneand/or a bus (in some embodiments, the stackable devices 902-908 communicatevia communication modules}.ally, the monitoring client 902. other monitoring client 4, andlor theremote communicator 11 may be used to send commands or requests to patient-care devices 14, 15, 16, 17, 35, 128, 904, 906, 908, 148 such as for e, abolus amount, an infusion flow rate, a total fluid for ry, a start time for drugdelivery, a stop time for drug delivery or a flow-delivery-rate profile to the stackableinfusion pump 904, the ble syringe pump 906 andlor the other stackablepatient-care device 908. In some embodiments, one or more of the monitoringclients 902, 4, 11 may be used to send commands or requests to the pill dispenser128, such as, for example, a pill dispense command to dispense a pill, a pill-type, apill dispensing schedule, and/or a max pill-dispensing criteria. The max pill-sing criteria may be a maximum amount of a medication that may bedelivered within a predetermined interval of time; for example, certain medicationsare taken as needed (i.e., pro re nata), however, the medication may not be safetaken in excess and the max pill-dispensing criteria may prevent the medicationfrom being taken at unsafe levels by the patient, e.g., a predetermined amountduring a predetermined interval of time.ally, the patient-care devices 14, 15, 16, 17, 35, 128, 904, 906, 908,148 may also communicate data back to the monitoring client 902, the othermonitoring client 4 and/or the remote communicator 11 for: determining if an alarmor alert should be issued or sent; determining if the treatment or condition is safe forthe patient; ining if the system 900 is operating properly or withinpredetermined bounds; and/or for displaying the data on a display of the monitoringclient 902, the other monitoring client 4 andior the remote communicator 11. Forexample, optionally, the stackable infusion pump 904, the stackable syringe pump906, and/or the other stackable patient-care device 908 may communicate (whereapplicable): upstream re; changes in upstream pressure; pressuredownstream to the patient 2; changes in pressure downstream to the patient 2; theor absence of air within an infusion line; an actual bolus amountpresencedelivered; an actual infusion flow rate; an actual total fluid delivered; an actual starttime for drug delivery; an actual stop time for drug delivery; or an actual flow-delivery-rate profile to one or more of the stackable monitoring client 902, the othermonitoring client 4 and/or the remote communicator 11. In another embodiment,the pill dispenser 128 may optionally icate data back to the blemonitoring client 902. the other monitoring client 4, and/or the remoteicator 11, such as for example, an actual pill dispensed, an actual pill-typedispensed, an actual pill dispensing schedule as dispensed, or r or not amax pill-dispensing criteria was exceeded.

The data received from the patient-care devices 14, 15. 16, 17, 35, 128, 904,906, 908, 148 may be analyzed for any predefined conditions to issuean alarmand/or an alert. For example, one or more of the monitoring s 902, 4, 11use an increase in pressure downstream of the stackable infusionpump 904 andlorthe stackable syringe pump 906 to be an indication ofone of: excessive clotting,ation, occlusion or kinking of the tubing to the patient; or occlusion by othermaterial within the IV bag 170. In response to the sudden increase in downstreampressure, one or more of the monitoring clients 902, 4, 11 may visually or audiblyalarm or alert a user. Additionally or alternatively, a sudden se in redownstream to the patient 2 may be an indication that the tubing has becomedetached from the needle andfor the needle is now out of the patient; and, inresponse, one or more of the monitoring clients 902, 4, 11 may visually or audiblyalarm or alert a user. One or more of the monitoring clients 902, 4, 11 may,optionally, send a command to one or more of the stackable infusion pump 902andlor the stackable syringe pump 906 to stop delivery of fluid in response to thesudden increase and/or decrease of re ream to the patientThe stackable monitoring client 902, the stackable device 908, thestackableinfusion pump 904, and the stackable syringepump 906 may be chainedtogether via connectors coupled to the tap and bottom of each . Forexample, the stackable e pump 906 may instead be stacked on top of thering client 902 such that a bottom connector of the stackable syringepump906 electrically coupled to connectors on top of the monitoring client 902.

The daisy chain can be created, for example, through electn‘calconductorswithin each of stackable monitoring client 902, the stackable patient-care device908. the stackable infusion pump 904, and the stackable syringepump 906 suchthat a continuous electrical contact is maintained between each of thesedevices.

Additionally or atively, the stackable devices 902, 908, 904, 906 mayoptionally maintain wireless communications with each other. For example, theble monitoring client 902 may detect that daisy-chain conductors areelectrically unresponsive because of an al short within a stackable device ofthe stackable devices 902, 908, 904, 906, and the stackable monitoringclient 902can interrogate each of the stackable devices 908, 904, 906 to determine whichdevice is faulted; after a ination is made, the stackable monitoring client 902can wirelessly communicate with an isolated disconnect circuit within the faulteddevice of the stackable devices 902, 908, 904. 906 to electrically disengage thefaulted device from the daisy-chained tors. Additionally or atively, oneor more of the stackable devices 902, 908, 904, 906 can alarm, send an alert,and/or display a e that one of the ble devices 902, 908, 904, 906 isfaulted and/or that one of the stackable devices 902, 908, 904, 906 iscommunicating wirelessly rather than via the daisy-chained. wired communicationslink.

Additionally or alternatively, each of stackable monitoring client 902, thestackable device 908, the stackable infusion pump 904, and the stackable syringepump 906 may relay or smit information to a respective device below orabove itself within the daisy chain. For example, the stackable infusion pump 904may icate all data received from the stackable syringe pump 906 bybuffering the data within an internal memory and communicating the informationwhen a signal is received from the stackable patient-care device 908 indicating theble patient-care device 908 is ready to receive additional data. In someembodiments, each item, component, device, patient-care device, dock, andcomputing device, numbered or unnumbered, as shown in Fig. 8 or describedtherewith is optional. For example, in some embodiments, the monitoring client 1 isoptional, the monitoring server 3 is optional, the ty services 8 is optional, eachof the services 19, 20, 21, 22, 23, 24 is optional, the cloud sewer 25 is optional,each of the other monitoring clients 4 is optional, the online drug databases 9 isoptional, the drug adverse event network is optional, the patient's personal EHR 19'is optional, and/or the treatment outcomes database 10 is optional. Additionally oratively, in some embodiments, each of the patient-care s 830, 810, 812is optional. Likewise, each of the system monitor 131, the wrist band 118, the RFID116, the e 114, the scanner 120, the display 808, and/or AC power, isoptional in some embodiments of the present disclosure.

Additionally, in some embodiments, although some items, ents,devices, patient-care devices, and computing devices, numbered or unnumbered,as shown in Fig. 9 or described therewith are shown as being the sole item,component, device, patient-care device, or ing device, multiple items,components, devices, patient-care devices, and computing devices, arecontemplated; for example, although a single pill dispenser 128 is shown in Fig. 9.in some embodiments, two pill dispensers 128 may be used, multiple pilldispensers 128 may be used, or any arbitrary number of pill dispensers 128 may beused.

Additionally or alternatively, although particular patient-care s 904,906, 908 are shown, other combinations, subsets, multiple ones of a particularpatient-care device. or ations thereof may be used. For example, in someembodiments. only a stackable infusion pump 904 is used of the t-caredevices, and, in this specific example, the other patient-care devices 906, 908 maybe disabled, may not be present or available for system use,may be turned off, ormay not be part of system 900 of Fig. 9. onally or alternatively, in somespecific embodiments, only the patient-care devices used are stacked; for example,in one specific embodiment, the infusion pump 904 is the only device stacked.

Additionally or atively, unstacked patient-care devices, e.g., patient-caredevices 904, 906, andior 908, may continue to operate when it is operating as astand-alone device. Additionally, alternatively, or optionally, in some cembodiments, the patient-care devices 14, 15, 16, 17, 35, 904, 908, 908, 128, 148are dockable, may operate undocked, and/or may not be dockable and can operateas a stand-alone patient-care device.

In Fig. 9, although the stack is shows as being capable of ng severalpatient-care devices, in other embodiments, the stack can receive one patient-caredevice, a plurality of t-care devices, or any arbitrary number of patient-cares. Additionally, although the stack is shown as be capable of receiving onemonitoring client 902, in other ments, the two stackable monitoring clients902, more than two stackable monitoring clients 902, or any arbitrary number ofstackable monitoring clients 902 are stacked together in system 900.

System 900 of Fig. 9 may use any known communications method tomaintain communications therewithin. For e, in some embodiments, anyschedule of communications may be used, broadcasting, anycast, multicast or3D unicast may be used, routing algorithms may be used, a distance-vector routingol may be used, a link-state g protocol may be used, an optimized linkstate routing protocol may be used, a path-vector protocol may be used, staticrouting with predefined alternative communications paths may be used, andloradaptive networking may be used. For example, in some embodiments of thepresent disclosure. s may be assigned to each communications path andra's Algorithm may be used to communicate between the monitoring client902 and one or more patient-care devices (e.g., patient-care devices 904, 906,908); the weights may be ined in any know way, ing as a functionbandwidth, signal quality, bit-error rate, may be linear to the available datathroughput or latency, and/or the like.ing to Figs. 1, 3, 5, 7, 8, and 9, various updating technologies and/ortechniques may be employed to update a hub, a clock, a , an insulin pump,an infusion pump, andlor a patient-care device. For example, a t-care devicemay be coupled to a computing device (which,in some embodiments, may be apersonal computer or any device that may be used in a similar fashion as apersonal computer, for example, but not limited to, a tablet) by way of bustranslator, which ts, for example, and in some embodiments, R8232formatted data to e.g., i2C formatted data. A processor within a hub, a clock. adevice, an insulin pump, an infusion pump, and/or a patient-care , may, inorchestrate the some embodiments, execute an update program to control anddownloading a software into flash memory by a supervisor processor andlor acommand processor, for example. In some embodiments, the computing deviceinto the flash memory of the hub, amay orchestrate the downloading of softwareclock, a device, an insulin pump, an infusion pump, andlor a patient-care device.

Software updates obtained by computing device may be flashed into flash memory(not shown) accessible by the supervisor processor andlor the commandprocessor. The above-described software updates may be, in some embodiments,a script process.a command line pragram that may be automatically invoked byIn some embodiments, a hub, a dock, a device, an insulin pump, an infusionhave the ability of, a web connectedpump, and/or a patient-care device may be, orremote interface which may include, but is not limited to, capability to downloadapplications, download software updates, upload information and/or sendinformation to various machines, ing, but not limited to, h a web basedsecure portal and/or through electronic mail and/or by way of a wirelesscommunications protocol. Thus, in various embodiments, the remote interfaceapplication may run on any e device and is not limited to a so-calledproprietary device. r, in some embodiments, the remote interface may beBluetooth enabled, or otherwise enabled, to communicate, for example, using radiofrequency ("RF") communication, with one or more devices which may include, butare not limited to, one or more of the following: hub, a clock, a device, an insulinpump, an infusion pump, a patient-care device, a oth or other communicationdevice, a patient-care device, andfor any other device.

In some embodiments, a charging stationmay include a charging area for ahub, a clock, a device, an insulin pump, an infusion pump, and/or a patient-caredevice for the remote interface which may include a USB plug. In someembodiments, the charging station may include a USB port, and in someembodiments, may include a mini-USB port, allowing for the charging n toreceiVe power, in some embodiments, for charging the hub, the clock, thedevice,the insulin pump, the infusion pump, the patient-care device. and/or theremoteinterface through a USB. Additionally andlor alternatively. the USB port may beconfigured for data transfer tolfrom a remote ace and/or the hub, the dock. thedevice, the n pump, the infusion pump. andIor the patient-care device byconnection to a computer or other device andlor other er-typeapparatus. Inembodiments including a USB port, whilst the remote interface is being d,the system may call to a personal computer and/or webportal to check for updatedsoftware and if there is updated software available, may download softwareupdates, e.g., via the USB connection. These updates may then be transferred tothe hub, the dock, the device, the insulin pump, the infusion pump, and/or thepatient-care device upon pairing.

Thus, the user may connect the remote interface of a hub, a clock, a device,an insulin pump, an on pump, and/or a patient-care device to a personalcomputer and/or, in some embodiments, upload data from the remote interface to aweb portal or other. In some embodiments, this may be accomplished during”recharging" of the remote interface which, in some embodiments, may be doneusing a USB tion to the personal computer, which, in additional tong/recharging the remote interface may synchronize and/or upload/downloaddata from the personal computer, 1908 andior web . At this time, the systemmay determine software s for one or more of the devices and or for theremote interface are available. The user may select "download updates" and thesemay be downloaded to the remote interface of the a hub. a clock, a device, aninsulin pump, an infusion pump, andfor a patient-care device,again, at the time ofcharging and/or at any time the remote interface is either connected, directly orctly. to the personal computer andIor to a web portal designed specifically forthe system. As sed above, the remote interface is capable of communicationwith the s devices. Thus. software s may be communicated to anyone or more device by the remote interface. This has many advantages. including.but not limited to. only having to connect the remote interface to the personalcomputer/web portal to both upload datafinformation from all of the devices and I ordownload updates and/or applications from the personal er and/or from theintemet/web portal to any of the devices. This may be desirable for many reasons.including but not limited to. the ability to efficiently and easily update all sall the devices onIO from one connection and/or the ability to view all of the data fromthe one location andIor the ability to ad information and/or settings frompersonal computer I web portal to any of the devices through the remote interface.

Thus. in some embodiments. as the personal computer/web portal nsall the information from all the devices. ing. but not limited to. the remote[5 interface. at any time. a new “remote interface" may be introduced to the system.

This may be accomplished by connecting the new remote interface to the personalcomputer I web portal and downloading all the information regarding the systemthe remote interface. In some embodiments. this may first require that the oldremote interface be removed from "approved devices". however. in otherembodiments; the system may “allow" additional remote interfaces by permissionfrom the user. Thus. the system includes the ability to download all the informationand applications to any internet connected and I or remote interface capable ofcommunicating to the devices and I or capable of connecting the personalcomputer andIor web portal.

This also allows the remote interface to download any application from theinternet to any device in the system. Thus. in various embodiments of the system.turn any apparatus (including some parameters such as ability toa user canssly communicate and connect to the personal computer andIor web portal)into a device that could control the various device. for example. the infusion pumpandIor receive data from and I or control a CGM sensor/transmitter. andIor otherinsulinanalyte s. andIor other devices. such as a hub, a dock. a device. andevice. In some ments. thepump. an infusion pump. andIor a patient-careremote interface andIor the one or more applications on the remote interface maybe password or other protected and is paired with the one or more devices.example. paired with an infusion pump andlor CGM sensor and or one or moreother devices.

In some embodiments. the information on the remote interface may beuploaded and [or synchronized with another device andlor a computer and/ormachine. including, but not limited to, uploading the data to an internet site thatmay be password ted (web ). Thus. a user may access the ationfrom any device and or may download the information toany device including anydevice specific applications and therefore the user ation may be downloadedto any device including. but not limited to, history, preferred settings, etc..

IO information.

Fig. 10 is flow chart diagram of a method 600 for communicating a patient-care parameter of a patient-care device to a monitoringserver in ance withan embodiment of the present disclosure. Method 600 includes acts 602-608. Thepatient-care device of method 600 may optionally be any patient-care devicedisclosed herein. e.g.. patient-care devices 7, 14. 15. 16. 17. 35, 126, 128, 130,148. of Figs. 1. 3, 5. or 7. patient-care devices 14. 15. 16, 17, 830. 810. 812. 814 ofFig. 8. patient-care devices 14. 15, 16, 17 904, 906. 908 of Fig. 9. or otherpatient-care device disclosed herein.

Act 602 establishes a communications link between a patient-care deviceand a monitoring server. Act 604 communicates the patient-care parameter to themonitoring sewer, e.g.. over the local area network andlor the internet. throughWiFi, through a monitoring client. one or more hubs. or a dock. etc. Act 606 de-identifies the t-care parameter. Act 606 may be performed automatically andelectronically, e.g.. within the ring server 3 of Figs. 1. 3, 5, 7. 8 andlor 9. Forexample. the name of the patient may be removed and replaced by a random serialnumber or other indicator that cannot be used to determine the identity of thet in the monitoring server. Act 608 stores the de-identifled. patient-careparameter in the monitoring . e.g.. within a database, such as a SQLdatabase. a relational database. an ative database. a cloudserver, and thelike.

Fig. 11 is flow chart diagram of a method 701 for aggregating patient-careparameters from multiple patients as ined from patient-care devices in amonitoring server in accordance with an embodiment of the present disclosure.

Method 701 includes acts 703-713. In some embodiments. all of the acts 703-713are optional. The patient-care device may be any patient-care device disclosedherein. e.g.. patient-care devices 7. 14. 15, 16, 17. 35. 126, 128. 130, 148, of Figs.1, 3. 5. or 7, patient-care devices 14. 15, 16. 17, 830. 810, 812. 814 of Fig. 8.patient-care devices 14. 15, 16. 17 904, 906, 908 of Fig. 9. or other patient-caredevice sed herein.

Act 703 establishes communications links between a monitoring server, e.g..monitoring server 3 of Figs 1. 3. 5. 7. 8. or 9. and a plurality of patient-care devicesassociated with a plurality of patients. Optionally. multiple patient-care devices maybe associated with a single patient. andlor multiple t-care devices may beassociated with a different and respective patient.

Act 705 communicates a plurality of patient-care parameters from theplurality of patient-care devices to the monitoring server. Act 707 de-identifies thet-care parameters. and act 709 stores the patient-care ters in themonitoring server. relationale.g.. within a database. such as an SQL database, ase, an associative database, and the like. Act 707 may be performedautomatically andlor electronically. Act 711 treats a subset of patients of theplurality of patients with a treatment. For example. patients with high bloodlower blood pressure. Actpressure may be treated with a medication designed to713 es a subset of the plurality of patients-care parameters ated withthe plurality of patients to determine the efficacy of the treatment. For example, allpatients that received the blood pressure medication of act 711 can have theirblood pressure compared to a blood pressure reading after a predeterminedamount of time. e.g.. 6 months, to determine if the treatment was effective for oneor more patients.

Fig. 12 is a flow chart diagram of a method 801 of recovery for a patient-caredevice when the patient-care device's ion is interrupted in accordance withan embodiment of the t disclosure. For example. a patient-care device maybe unplugged from a clock. the power may be interrupted, a re or softwarefault may temporarily disable one or more processors or other circuitry within thet-care device. and the like. Additionally or alternatively. the one or moremethod 801processors on a patient-care device may implement the so that thepatient-care device is hot ble.

Method 801 includes acts 803-823. Each of the acts 803-823. in someembodiments. is Optional. Act 803 receives one or more patient-care parametersassociated with a patient-care device. The patient—care device ofmethod 801 maybe any patient-care device disclosed herein. for example. it may be one or more ofpatient-care devices 7. 14. 15, 16. 17. 35. 126. 128, 130. 148. of Figs. 1. 3. 5. or 7.patient-care devices 14. 15. 16. 17. 830. 810. 812. 814 of Fig. 8. or patient-caredevices 14. 15. 16. 17 904. 906. 908 of Fig. 9.

Act 805 stores the one or more patient-care parameters in anon-volatilememory of the patient-care device. The patient-care ters may be anyvalues ated with patient care including t-treatment ters orpatient-condition parameters. for example. an infusion rate for an infusionpump is apatient-treatment parameter.

Act 807 receives one or more ing parameters for the patient-caredevice. An operating parameter may be anything related to the ion of thedevice. For example. an Operating parametermay be a limit on the speed of amotor of an infusion pump. an on pump speed. a e limitation onIS wireless communications. a battery discharge rate or rate limit. an updatefrequency. and the like. Act 809 stores the one or more operating parameters inthe non-volatile memory of the patient-care device.

Act 811 calculates one or more additional ing ters for thepatient-care device. The calculated operating parameters are any parameterscalculated for operating the patient-care device. for example. a gain coefficientof aproportional-integral-derivative (“PlD”) control loop that has adaptive gaincoefficients used in automatic gain control. Act 813 stores the one or moreadditional operating parameters in the non-volatile memory of the patient-caredevice.

Act 815 determines that operation of the patient-care device has beeninterrupted. for example. power has been lost to the patient-care device. a fault hasoccurred in the patient-care device. a out CPU reset has occurred.and thelike. Act 817 determines that operation of the patient-care devicecan resume.

Act 819 loads the one or more received or calculated operatingparametersinto a working memory of the patient-care device: and. act 821 loads the one ormore patient-care ters into the working memory of the patient-care device.

Act 823 resumes operation of the patient-care device.

Turning now to Fig. 13. a flow chart diagram of a method 900 is shown forpairing a monitoring client having a user interface with a patient-care device inaccordance with an embodiment of the present disclosure. Method 900 esacts 902-912. The monitoring client of method 900 may be a monitoring client 1. orremote communicator 11 of Figs. 1. 3. 5. 7. or 8. monitoring client 902 of Fig.9. aremote communicator 11 of Figs. 1. 3. 5. 7. 8. or 9. a cell phone. a dcomputer. a tablet computer. a laptop computer. a personal computer. a personaldigital assistant. and the like. Although Method 900 described pairing between amonitoring client and a patient-care device. in some embodiments. the method 900with a patient-care device (e.g.,may be used to pair a hub (e.g., hub 802 of Fig. 8)patient-care device 830. 810. 812. and 814). to pair a first patient-care device (e.g.,IO patient-care device 830 of Fig. 8) with a second patient-care device (e.g., patient-devicecare device 814 of Fig. 8) such that the user interface of the first patient-carethe systemcan be used to control the second patient-care device. and/or to a pairmonitor (e.g., system ring 131 of Figs. 1. 3. 5. 7. 8 or 9) with a patient-caredevice (e.g., patient-care devices 7. 170. 126. 128. 148. 14. 15. 16. 17 or 170 as[5 shown in Figs. 1. 3. 5 and 7. or the patient-care s 830. 810. 812. 814. 14. 15.16. 17 or 148 of Fig. 8. andlor the patient-care devices 904. 906. 908. 14. 15. 16.17 or 148 of Fig. 9).

Act 902 positions a monitoring client having a User ace (e.g., a display.touchscreen. a display. buttons. accelerometer for user input. and the like) within anoperational distance of a patient-care device. Act 904 displays the ty of thepatient-care device on the user interface. The t-care device may be fiedby. for instance. a serial number. a device type. or a visual display on the user inputof the patient-care device using standard or custom discovery protocols. Act 906selects the patient-care device for pairing using the user interface. For e. aindicateuser in act 906 may touch a touchscreen of the monitoring client toion of the patient-care device.

Act 908 pairs the patient-care device to the monitoring client. For example.the paring of the patient-care device to the monitoring client may utilize Bluetooth.

Bluetooth Low Energy (I.E.E.E. 80215.1). WiFi. infrared communications. near fieldcommunication (NFC ISO 13157). IR communication. or optically. A custom pairingprotocol may be Used as well. as will be apparent in light of this disclosure. whichAct 910 communicatesmay or may not employ the use of handshaking sequence.patient-care parameters between the patient-care device and the monitoring client.e.g.. so that the patient-care device may be controlled or monitored by themonitoring client.

Act 912. optionally. operatively communicates onal patient-careparameters with another patient-care device through the patient-care . In act912. if the t-care device is operatively coupled to or is in operativecommunication with another patient-care device, the patient-care devicecan act asa relay or router so that the monitoring client can communicate with the anothert-care device. Additionally or alternatively, the patient-care device may useinformation from r patient-care device for its operation, for example, anIO infusion pump may use a flow rate as determined by a flow rate meter ortemperature from a temperature probe. andl’or the infusion pump may relayinformation from the flow rate meter to a monitoring client. Additionally. themonitoring client can optionally communicate with multiple patient-care devicescoupled to the paired patient-care device. either in parallel or in serial. Additionally[5 or alternatively. in some embodiments of the present disclosure, in method 900 themonitoring client communicates with the patient-care device using an intravenoustube. The communications may occur via an electrical conductorembedded into orattached to the intravenous tube, via electrical communicationusing the fluid withinthe intravenous tube as a conductive medium, Using sounds waves travelingthrough the intravenous tube. or lly by using the fluid within the tube asl waveguide. The communication via the intravenous tubemay be used toset-up g (e.g.. between a monitoring client. a hub, a dock. a patient caredevice and/or a system monitor with one or more of a monitoringclient, a hub, adock, a patient care device andlor a system monitor) using anothercommunications link. e.g., Bluetooth, oth Low Energy. WiFi,etc.

In yet additional embodiments of the present disclosure.the pairing from afirst device (e.g.. a monitoring client. hub. patient-care device, or system monitor)with a second device (e.g.. a monitoring client. hub. patient-caredevice. or systemmonitor) may be configured andior initialized using a first ications link suchthat the devices are paired using a second communicationslink; for e. near-field communications or IR communications may set up pairing between thedevices using Bluetooth, oth Low Energy. or WiFi. forexample. The gsetup (e.g., via near—field communications or IR communications)may prompt arequest on a monitoring client. hub. patient-care device. and/or system monitoringe.g.. pairing via Bluetooth. for requesting User confirmation of the device g.to a hub.example. In some embodiments. when a patient-care device is pairedmonitoring client. and/or dock. the ID and software version numberis sent to thethe monitoringhub. monitoring client. and/or dock. which checks with a server. e.g..to determine if the softwareserver 3. middleware. the cloud server, or other serverif the software is not up-to-date. the hub. on the patient-care device is Up-to-date;monitoring client. dock. or the patient-care devices itself (e.g.. directly) downloadsUpdated software to m the t-care device. The patient-care device maynotify the user if the re is Up to date andlor may give the User the Option onif the software is notIO the touch screen to optionally update the patient-care deviceand/or theup to date. The communications link that sets Up the pairing (e.g.. NFC)communications link that Uses the pairing (e.g.. Bluetooth or Bluetooth Low Energy)the updated software. themay communicate ID. the software n number.provide the notification. etc. One g that may be used. e.g.. with a pumppatient-care device or insulin pump. may be found in: 15 (1) the patent applicationto Mandro et al.. filedentitled "INFUSION PUMP METHODS AND SYSTEMS"March 25. 2010. Attorney Docket I06. and having the serial number 121731.843. (2)the patent application entitled "METHODS AND SYSTEMS FOR CONTROLLINGDocket 698. andAN INFUSION PUMP" to Bryant et al.. filed April 4. 2009. Attorneyhaving the serial number 12/416,662. andfor (3) the patent application entitledION PUMP ASSEMBLY" to Kamen et al.. filed December 31. 2009. Attorneycontents of allDocket GT5. and having the serial number 121347.985. the entirethree of which are hereby incorporated by reference in their entirety.

Fig. 14 is a flow chart diagram of a method 10000 for monitoring operationr paired to the patient-carea patient-care device using a wearable systemMethod 1000device in accordance with an embodiment of the present disclosure.es acts 1014-1040 and can utilize various devices 1002. 1004. 1006. 1008.method 10001100. 1112 to tate the pairing of the wearable system monitor ofwith a patient-care device. In some embodiments, each of the acts 1014-1040opfionaLThe wearable system monitor of method 10000 may be the wearable systemmonitor 131 of Figs. 1. 3. 5. 7. 8. and 9. The pairing of the system monitor ofbe done usingmethod 1000 for monitoring one or more patient-care devices mayany one or more of the devices 1002-1012. or using any sufficient devicesdisclosed herein. For example. a user interface of the monitoringdevice 1002. auser interface of a remote communicator 1004. a user interface of acommunications device 1006. a user interface of a patient-care device1008. a userinterface of another patient-care device 1010. or theuser interface of the wearablesystem monitor 1012 may be used to pair the wearable system rof method1000 with a patient-care device.

The patient-care device of method 1000 may be any patient-care devicedisclosed herein. such as patient-care devices 7. 14. 15. 16. 17. 35. 126. 128. 130.148. of Figs. 1. 3. 5. or 7. patient-care devices 14. 15. 16. 17. 830. 810.812. 814 ofFig. 8. t-care devices 14. 15. 16. 17 904. 906. 908 of Fig. 9. or other t-care device disclosed herein.

The system monitor of method 1000may be used with system 100 of Fig. 1.system 300 of Fig. 3. system 500 of Fig. 5. system 700 of Fig. 7.system 800 of Fig8. system 900 of Fig. 9. may be used with a stand-alone system. and/or withother ent system or group of devices disclosed herein.

Act 1014 identifies a caregiver (i.e.. provider) usingone or more of: a voice-recognition algorithm. a —recognition algorithm. a barcode. an RFIDtag. near-field communications. simple login.secure signatures. and the like. For example.the identification of the caregiver in act 1040may be done by a monitoring client. amonitoring-client docking station. a device docking station. by a communicationsmodule. other dock. or hub using an onboard camera andfora microphone. Also.as a safety check. a ring client. a hub. dock. or t-care device mayrequest that a user enter in font as displayed to guard against font corruptionerrors. Additionally or alternatively. in some embodiments. if after one or morefailed logins or verifications. the devicemay take a picture and store the picture; thepicture may be transmitted for storage in a ware server. Act 1016 logs thepresence of the caregiver in one or more of the devices 1002-1012. The log entrymay be stored on the any one of the devices 012. a patient-care devicedescribed herein. a monitoring client described herein.a le system monitordescribed herein. a remote communicator described herein.and/or a hub describedherein. The log of act 1016 can be for caregiver compliance. diagnosticpurposes.and the like. For example. if a ver is scheduled toappear and does not. theact of 1016 may log the non-appearance of the caregiverat the scheduled time.

The facial-recognition algorithm of act 1014 may relay on any facial featuresof the caregiver such as analyzing the relative size. shape, a position of the eyes.nose. jaw. ones. or other facial features. The facial-recognition algorithm ofact 1014 may use three-dimensional face recognition. skin e analysis. or otherfacial-recognition algorithm. Additionally or alternatively. in some embodiments. thevoice-recognition algorithm of act 1014 may use hidden Markov models: dynamic-tirne-warping based speech recognition. or other voice-recognition algorithm(s).

Act 1018 detaches the wearable system monitor from a wearable dock. Forexample. the system monitor 131 of Fig. 1 may be worn on the patient's wrist suchm that it is attached to the patient with a wristband similar to a watch wristband; aportion of the wearable system monitor may be detachable from a dock whiches the wristband and a snap-fit base member that the wearable systemmonitor snaps into (also referred to herein as a ”wearable dock”). When thewearable system r is detached from its dock. act 1020 starts a timer. Thetimer and related acts are each optional in method 1000 of Fig. 14.

The timer of act 1020 keeps track ofthe amount of time the wearable systemmonitor is out of its dock. Act 1022 stops a treatment if a predetermined amount oftime has d after the wearable system monitor has been undocked from thewearable dock. For example, the wearable system monitor of method 1000 maysignal an infusion pump to stop pumping. When the wearable system monitor isdocked again. act 1024 resumes the treatment if the treatment was interrupted.from its wearable dock after thee.g.. from undocking the wearable system monitorpredetermined amount of time has elapsed.

As previously mentioned. act 1018 detaches the le system monitorfrom the wearable dock. Act 1026 fies a t using, for example. one ormore of: a voice-recognition algorithm. a -recognition algorithm, a barcode. anRFID tag. near-filed communications. simple login, caregiver entry. and the like.

Act 1026 may be r to act 1014. may utilize the same software as utilized in act1014, andlor may utilize one of the devices 1002-1020. In some embodiments.however, note that the identification procedure for a patient can include more thanthe identification of the caregiver by using. for example, biometrics or otheridentifying t-specific information. Such patient identification standards may beused to ensure a particular ent is being given to the correct patient andlor toprovide compliance with given tions. Act 1014 andlor 1026 may beperformed using a y device on the patient and/or ver.

Act 1028 ines if the caregiver is authorized to pair the wearablesystem monitor, e.g., pair the wearable system monitor with a patient-care device.

If the caregiver is not authorized. then the method 1000prevents additional pairing(or editing of the pairing settings) of the wearable system monitor. If the caregiveris authorized to pair the wearable system monitor, act 1030 allows thecaregiver toselect one or more patient-care devices for pairing with the wearable systemmonitor. Caregiver authorization can be used, for instance, to ensure a particulartreatment is being given to the correct patient andlor to provide compliance withgiven regulations.

The caregiver may be provided a list of patient-care devices that areavailable for pairing on one or more user interfaces of the devices 1002-1012.

During act 1030. the caregiver selects a wearable system monitor (e.g.. the patient-I5 wearable system r of act 1018) and a patient-care device for pairingtogether. Act 1032 pairs the wearable system monitor with the patient-care device,and act 1034 logs the g of act 1032 in the wearable systemr includingthe identity of the ver and the patient. in an additional specific embodiment.the pairing of the wearable system r with the patient—care devicemay beused with parallel or serial pairing of the patient-care device with another device(e.g., a ring client. a hub. another patient-care device etc.) As will beappreciated in light of this disclosure. any suitable pairing protocol (e.g.. Bluetoothor lEEE 802.11) can be used. Additionally or alternatively. act 1034 can log thepairing into one or more of the devices 1002-1012.

Act 1036 reattaches the le system monitor to the wearable dock.1038 identifies and authenticates the wearable docking using the wearablesystemmonitor, e.g.. to determine if the wearable system monitor and the wearable dockare authorized for docking together. For example, act 1038 may ensure that thewearable system monitor is docked to a wearable dock of the correct patient.

If. forexample. the wearable system monitor was docked to a wearable clock of thewrong patient. the wearable system monitor can recognize the error, preclude theassociated treatment from proceeding by signaling the patient-care deviceassociated with the t-care device to stop operating (in some ments).and send an alert to a monitoring .e.g., the monitoring client 1, 4. or 11 ofFigs 1, 3, 5, 7, 8, monitoring client 9, 4, or 11 of Fig. 9, or other monitoring clientsed herein. Act 1024 can resume treatment if the treatment was interrupted.1040.or act 1040 can treat the patient in accordance with any updated gsIn some specific embodiments, when a caregiver is identifiedin act 1016and/or the t is identified in act 1026. the caregiver may update treatmentsettings, e.g., on a monitoring client, a hub, a remote communicationor on thepatient-care device.

Fig. 15 is a flow chart m of a method 1100 for ying a userof theinterface using a user-interface template in accordance with an embodimentpresent disclosure. Method 1100 includes act 1102-1132. In some embodiments,each of the acts 1102-1132 is al.

The monitoring client of method 1100 may be one or more of monitoringof Figs 1, 3, 5. Y. 8, monitoring s 9, 4, or 11 of Fig.clients 1, 4, or 11 9, orother monitoring client disclosed . The patient-care device of method 1100devices 7,may be one or more of patient-care 14, 15, 16, 17, 35, 126, 128, 130,814 of148, of Figs. 1, 3, 5, or 7, patient-care devices 14, 15, 16, 17. 830, 810, 812,Fig. 8, t-care devices 14, 15, 16, 17 904, 906, 908 of Fig. 9, or other patient-care device disclosed herein.gh method 1100 describes using a user-interface template with amonitoring client, the monitoring client may be tuted by a hub, acommunications module, another patient-care device, or other sufficient devicemethodhaving a user interface. The user-interface template of the user interface of1100 provides a predefined display with specific fields for displaying patient-careFor example, a user-interface template for an infusion pump may parameters.define certain fields for displaying on a GUI, such as the present fluid-flowrate.the monitoringThe user-interface template may also define an area on a display ofclient for displaying the present fluid-flow rate as received from the infusion pump.instructions The user-interface template may include layout information, such as:how to display information; a description of varioue widgets; various widgets;labels tographs; labels for the graph axes; labels for the display; buttons; and/orprovide the user with control or visual information of one or more patient-caredevices. The user-interface template may be a te describing a QT-basedtemplate, andlor may use HTML or CSS.

Act 1102 identifies or selects a patient-care device forcommunication with amonitoring client having a user interface. For example. in act 1102, the ringclient may automatically identify a predetermined infusion pump that has beenpreviously designated by a provider for treatment of a patient. Additionally oralternatively, in act 1102 a er may be given a list of patient-care devices toselect from for displaying on the user interface of themonitoring client informationconcerning ion of the selected patient-care device(s).

Act 1104 determines if the patient-care device has a stored user-interfacete. For example. an infusion pumpmay e flash memory with a user-interface template stored therein. If the t-care device has a storeduser-interface template. act 1106 communicates the storeduser-interface template fromthe patient-care device to the ring client having theuser interface. Act 1108displays the user-interface template on the user interface of themonitoring client.

Act 1110 communicates patient-care parameters betweenthe patient-care deviceand the monitoring client. Act 1112 displays the patient-care parameterson thedisplayed user-interface template in accordance with the user-interface template.

For example, a user-interface template for an infusionpump may include a spacefor the present infusion rate; act 1112 displays, in thisexample, the present infusionrate (a patient-care parameter) on the display using theuser-interface template.

If act 1104 determines that no patient-care device has a stored user-interface template. the method 1100 will determine if the monitoringclient has auser-interface template for use for displaying the patient-care parameters of thepatient-care device; additionally or alternatively. act 11004may issue an alarm viathe monitoring client and/or the patient-care device.

Act 1114 determines the typeof the patient-care . if the type is determined, act 1116 determines if a user-interface template is stored within the ring client inaccordance with the typeof the patient-care device. If there is a user-interface template, act 1118 displaysthe nterface template on the user ace of themonitoring client. Act 1120communicates patient-care parameters between the patient-care device and themonitoring client. Act 1122 ys the patient-care parameterson the yeduser-interface template in accordance with the user-interface template. Forexample. patient-care parameters. such as an infusion rate, may be displayed inned areas of the user interface as designated by the user-interfacetemplate.

If the type is not determined in act 1114, or a user-interface template is notlocated within the monitoring client based upon the determined type, then act 1124displays a selectable list of a plurality of user-interface templates on the userinterface of the monitoring client; additionally or alternatively, act 1114 may issuean alarm or alert via the ring client andfor the patient-care device. Act 1126allows a user to select a user-interface template from the ity of user-interfacetemplates using the user interface of the monitoring client. Act 1128 displays theuser-interface template on the user interface of the monitoring client. Act 1130communicates patient-care parameters between the patient-care device and themonitoring client. Act 1132 displays the patient-care parameters on the displayeduser-interface template in accordance with the user-interface template.

In some embodiments of the present disclosure, the patient-care device ofmethod 1100 may also store one or more fonts for display on the monitoring .e.g., using the user-interface template described above. The fonts may be storedin any format. such as JPEGs, BMPs, image s, pre-stored fonts. and the likeand may be transmitted for use within the field to provide an indication of theing parameter. (e.g., rather than transmitting a value, an image is transmittedshowing a number or value which is then displayed on the monitoring client). Insome ments, fonts stored within the monitoring client may be used such thata value of the operating ter is sent to the monitoring client for display withinthe template using the fonts stored in the monitoring client.

Fig. 16 is a flow chart diagram of a method 1134 for downloading anapplication for controlling a patient-care device in accordance with an embodimentof the t disclosure. ln method 1134 of Fig. 16. although a monitoring deviceis described ith as an exemplary device for controlling a patient-care device,the monitoring device may be tuted andlor supplemented by a dock, hub.communications module, remote icator, communications device, and thelike.

Method 1134 includes acts 1136-1146. In some embodiments, each of theacts 1136-1146 is optional. The monitoring client of method 1134 may optionallybe one of the monitoring clients 1. 4, or 11 of Figs 1, 3, 5, 7, 8, the monitoringclients 9, 4, or 11 of Fig. 9, or other monitoring client disclosed herein. The patient-care device of method 1134 may ally be one of patient-care devices 7, 14,. 16, 17, 35, 126, 128, 130, 148. of Figs. 1, 3, 5, or 7, patient-care devices 14,, 16, 17, 830, 810, 812, 814 of Fig. 8, t-care devices 14, 15, 16, 17 904,906, 908 of Fig. 9, or other patient-care device disclosed herein. The server ofmethod 1134 may optionally be one of the monitoring servers 3 of Figs 1, 3, 5, 7, 8,or 9.

Act 1136 clocks a patient-care device into a dock. For example, an infusiondevice 7 of Figs. 1, 3, 5, or 7, infusion s 830, 810, or 812 of Fig. 8, or aninfusion device 904 of Fig. 9 may be docked into a tive dock. In act 1138, amonitoring client identifies the patient-care . For example, the patient-caredevice may communicate, for instance. an ID number, a serial number, adescription, a prescription, a treatment regime, a patient-treatment parameter, orthe like, to the monitoring client, e.g., by way of a discovery protocol. The dockedpatient-care device may have stored therein treatment information (for example, amedication amount, on rate, total fluid amount, or other patient-treatmentparameter), each of which may be associated with or correspond to a patient.in act 1140, the monitoring client queries a server for an application tocontrol the patient-care device (e.g, to set an infusion rate). The monitoring clientdownloads the application in act 1142. The communications between themonitoring client and the server may be encrypted. For example. the server mayencrypt the application prior to sending to the monitoring client, and the monitoringclient can decrypt the application using a ent encryption key. onally oralternatively, all ications may be encrypted. The monitoring client executesthe application during act 1144. In act 1146, the ring client iscommunicatively and operatively coupled with the patient-care device through theapplication by executing the application on one or more processors. Themonitoring client may place the application in a x (as described below). Inone such embodiment, the application includes an operative set of processorexecutable instruction configured for execution by one or moreprocessors on themonitoring client. The application may include instructions to display a userinterface on a display of the ring client, e.g., using the user interfacetemplate of method 1100 of Fig. 15. Additionally or alternatively, in someembodiments, the application may be used to control the patient-care device byoptionally sending parameters or values to the patient-care device, e.g., a bolusamount, an on flow rate, a total fluid for delivery, a start time for drug delivery,a stop time for drug ry, a fiow-delivery-rate profile, a pill dispense command todispense a pill, a pill-type, a pill dispensing schedule, andlor a max pill-dispensingcriteria.

Fig. 17 is a flow chart m of a method 1200 of ensuring data integritywhen communicating data (e.g., requests) for a patient-care device in accordancewith an embodiment of the present disclosure. Method 1200 includes acts 1202-1222. In some embodiments, each of the acts 1202-1222 is optional. The patient-disclosed , forcare device of method 1200 may be any t-care deviceexample patient-care devices 7, 14, 15, 16. 17, 35, 126, 128, 130, 148, of Figs. 1,3, 5, or 7, patient-care devices 14, 15, 16, 17, 830, 810, 812, 814 of Fig. 8, patient-care devices 14, 15, 16, 17 904, 906, 908 of Fig. 9, or other patient-care devicedisclosed herein.

The request may optionally originate from any ized, authenticated,andlor identified monitoring client, such as, for example, a monitoring client 1 or 4of Figs. 1, 3, 5, 7 or 8, a remote communicator 11 of Figs. 1, 3, 5, 7, 8 or 9, a cellphone, a handled computer, a tablet computer, a laptop computer, a alcomputer, a personal digital assistant, and the like.

Act 1202 submits a request for a patient-care device using a user interfaceof a monitoring client. For e, using the touchscreen of the monitoring client1 of Fig. 1, a user submits an infusion rate for the infusion pump 7. In someembodiments, the request may optionally be a parameter related to the patient-caredevice, total fluid for delivery, a starte.g., a bolus amount, an infusion flow rate, atime for drug delivery, a stop time for drug delivery, a flow-delivery-rate profile, a pilldispense command to dispense a pill, a pill-type. a pill dispensing schedule, andlora max pill-dispensing criteria.

Act 1204 is al, and act 1204 displays ng request" on the userinterface of the monitoring client. Act 1206 formats the request for a patient-caredevice. For example, act 1206 may prepare the request such that it ms tothe communications requirements of the patient-care device.

Act 1208 ines a check value of the t. For example, a -redundancy-check algorithm is used to determine a check value that correspondsto the request. The check value calculated by the cyclic-redundancy-checkalgorithm is dependent upon the request. A change in one bit of the request willalso change the check value as calculated by the cyclic-redundancy-checkalgorithm. Likewise, changing several bits will also change the check value.

Additionally or alternatively. in other ments. a parity bit (even or odd) orother data ity checks may be used.

Act 1210 appends the check value to the request. Action 1212 is optional,and act 1212 requests confirmation from theuser for communicating the requestusing the user interface. The request for confirmationmay be a pop-up dialog boxon a touchscreen that displays "confirm infusion rate of 90 milliliters/hour?”with abox for selecting med." The text and format shown in act 1212 may be of adifferent font, ent font size, and/or different display position than otherdisplayed information, e.g.. as displayed during the entering of the request orotherwise, to provide an onal safeguard against bad display pixels, acorrupted font table, user misunderstanding. and the like. Act 1214 confirms therequest for communication of the request using the user interface. The user cantouch the “confirmed” box to confirm the request for communicationof the request.according to some embodiments of the present disclosure.

Act 1216 communicates the request to the patient-care device. Thecommunication may be made via wired, wireless, guided. or fiber opticcommunications. or the like. The patient-care device receives the request duringact 1216. During transit of the request, it is possible that one or more bits in therequest have been corrupted. e.g.. a bit has changed its value, a bit has been lost,a bit has been added. and the like; this or other data corruption is undesirable.

Act 1218 of method 1200 facilitates the detection of ted data.

Duringact 1218, the t-care device s the check value in accordance with therequest. in act 1218, the patient-care devicemay use the same cyclic-redundancy-check algorithm as in act 1208 on the request to calculate an additional checkvalue. The check value in act 1216 as calculated by the patient-care devicewill beidentical to the check value calculated in act 1208 only if the datain the request iscal. That is, the check value in act 1216 and the check value inact 1208 willbe different only if the data of the request has become corrupted, has fewermore bits, or otherwise is not identical to the digital data used to determine thecheck value of act 1208.

If the check value of the t was not verified, in act 1222 the patient-care device requests retransmission of the request from the ring client.

Although Fig. 17 shows act 1222 as proceeding to act 1204 of method1200, inother embodiments, method 1200 may proceed to any of acts 1202-2116. Ifretransmission of the request is not successful, method 1200 can communicate anto the monitoring client. Othenivise, if theerror. an alarm. or an alert (not shown)the patient-carecheck value is verified as indicating no data tion. in act 1220device performs the request.sent backIn alternative embodiments, the request in act 1218 is additionallyto the monitoring client after verification from the patient-care device and mayinclude additional CRC checking during the transmission. The t-care devicem. alternative embodiment, checks toduring verification may in thisdetermine if the request is within predetermined ranges (e.g.. the infusion rate forin this alternativethe particular drug is safe, etc.). The monitoring client,either e the t as received from the patient-careembodiment, candevice with the original request as stored in memory (the requests may bethe request toassociated with each other). andfor the monitoring client can displaybe a pop-up dialog boxthe user for confirmation. The request for confirmation mayrate of 90 iterslhour?” with aon a touchscreen that displays "confirm infusion“confirmed." The text and format shown in this alternativebox for selectingembodiment for the confirmation may be of a different font. ent font size,andlor different display position than other displayed information. e.g.. as displayedadditional safeguardduring the entering of the request or otherwise. to provide anand theagainst bad display , a corrupted font table. user misunderstanding,like. In this alternative ment, the user can confirm the requestcommunication of the request using the user interface. The user can touch the"confirmed" box to confirm the request for communication of the request, accordingto some embodiments of the present disclosure.

Thereafter, in this alternative embodiment, the request is resent to thepatient-care device for performing; additionally or alternatively, in this alternativeembodiment. an action message is sent to the patient-care device, and the actionmessage contains information linking it to the original request (e.g., ”This is then" for the 90 milliliterslhour request that was just sent").

Fig. 18 is a block diagram of an electronic patient-care system 1300 inance with yet another embodiment of the present disclosure. System 1300includes a monitoring client 1302. a dock 1304. and a ss dock 1306.describedally. in some embodiments, the dock 1304 may act as a hub asherein.

The patient care devicemay be any patient-care device described herein,such as one of the patient-care devices 7, 14, 15, 16, 17, 35, 126, 128, 130, 148,of Figs. 1, 3, 5, or 7, the patient-care devices 14, 15, 16, 17, 830, 810, 812, 814 ofFig. 8, or the patient-care devices 14, 15, 16, 17 904, 906, 908 of Fig. 9. Themonitoring client 1302 may be tuted for any monitoring client describedherein, such as monitoring clients 1, 4, or 11 of Figs 1, 3, 5, 7, 8, monitoring clients9, 4, or 11 of Fig. 9, a , a smart phone, a PDA,or the like.

The clock 1304 may include a shaped receiving portion for receiving thering client 1302 for connecting electrical contactsof the monitoring client1302 to the docket 1304 through a cable 1308.

The cable 1308 may be integrateder with the dock 1304 andlor the monitoring client 1302. The cable 1308may provide, for instance. USB or other standardications between thedock 1304 and the monitoring client 1302.

The dock 1304 optionally includes a processor 1301, sensors 1309, awatchdog 1310, a r 1312, a battery 1314, and an alternating-current(”AC")power cord 1316. The processor 1301 controls the ion of the dock 1304. Apatient-care device 1318 is dockabie to the dock 1304. System 1300 also includesa wireless dock 1306 having a patient-care device 1320 docked thereto. Thewireless dock 1306 may be identicalor similar to the dock 1304, however, thewireless dock 1306 wirelessly communicates withthe monitoring client 1302, insome embodiments.

The battery 1314 can power the dock 1304 andthe patient-care device 1318when the AC power cord 1316 is unplugged from an AC outlet (not .some embodiments,the dock 1304 may be the sole source of power for themonitoring client 1302 or the patient-care device 1318. Additionally or alternatively,the monitoring client 1302 andior the patient-caredevice 1318 may include an on-board battery or a separate ACpower cord (not shown).

In some example embodiments, the dock 1304 may provide lEC-60601compliant power to the patient-care device 1318. Additionally or alternatively, thedock 1304 can provide a variable DC voltage as requested by thepatient-caredevice 1318. For example. the dock 1304may e a programmable buck-boostpower supply (not shown) that can provide a DC voltage from 1 Volt to 24 Volts asted by the patient-care device 1318 for a specific connector pin of aconnector 1322.1312 when the power cordThe battery 1314 may be d by the chargeroutlet (not shown). The y 13141316 is plugged into an AC providesthe AC power cord 1316uninterrupted power to the patient-care device 1318 whenFor example, the patient-care deviceis ged from an AC outlet (not shown).after the AC power cord1318 may be an infusion pump which continues to operate1316 is unplugged because the battery 1314 automatically supplies replacement1318 when the AC power cord 1316 is unplugged.power to the patient-care deviceThe sensors 1308 may optionally e one or more of an ambientambient humidity sensor. andtemperature . an ambient pressure sensor. ansuch as twothe like. The s 1308 may optionally include redundant sensors,and the dock 1304 may use the redundant sensors totemperature sensors.the readings of thedetermine if one or both has malfunctioned, e.g.. by comparingtwo sensors to each other. The dock 1304 may communicate with the sensorsto ensure to m data1308 andlor other peripherals their proper operation.1318 with their measurements,integrity checks. to e the patient-care devicee.g.. the ambient temperature.the patient-care device 1318The watchdog 1310 can optionally ensures thatmentioned above. monitoring theis ly operating by performing interrogationsdetermineoutputs of the t-care device 1318 to if they are withinpredetermined ranges (e.g.. physically possible or likely ranges). have feedbackand is othenivise properly.that is in accordance with applied input, operatingmonitor theAdditionally or alternatively. the system monitor 13010 may optionallyoperation of the monitoring client 1302 through the cable1308. Although one1310 may be used.watchdog 1310 is described . one or more watchdogse.g.. a plurality of watchdogs 1310.

In some example embodiments. the patient-the og 1310 at fixed intervals. Thecare device 1318 communicates withinterface of the monitoringfixed intervals are optionally configurable using a usercable 1308. If the patient-careclient 1302 or using a computer attached to the1310 during the fixed interval.device 1318 fails to communicate with the watchdoghas occurred within the patient-carethe watchdog 1310 determines that an erroraudible sound using a speakerdevice 1318 and issues an alert or alarm, e.g.. an1324 or s an LED 1326 red. The action for response to not receiving ausingcommunication within the interval may be configurable and/or program. e.g..client 1302 or using a computer attached to thea user interface of the monitoringcable 1308; for example, for non-critical t-caredevices, a failure to respond tothe watchdog 1310 may cause the LED1326 is flash RED. and an action to acritical patient-care devicemay additionally cause the dock 1304 andlor monitoringclient 1302 to audibly and visually alarm andsent a notification to a nursing stationand/or a remote communicator,e.g., remote communicator 11 of Figs. 1, 3, 5, 7, 8,or 9, a smartphone, a laptop computer, anotherpatient-care device. and the like.

Additionally or alternatively, the LED 1326 may optionally flashgreen if the t-care device 1326 is ing ly or is presently treating a patient.

Additionally or altematively, a speaker within the monitoring client 1302may issuean audible alert or alarm. If appropriate, the t-care devicecan be disabled orswapped out until the error condition is resolved.

Additionally or alternatively. the watchdog 1310 may ensures that thewatchdog 1310 at a fixed, predetermined, or preprogrammed interval. if themonitoring client 1302 fails to communicate with the watchdog 1310 during thefixed al, the watchdog 1310may determine that an error has ed withinthe monitoring client 1302 and issuesan alert or alarm similar to theone describedabove with regards to the patient-care device1318, e.g., an audible sound using aspeaker 1324 or flashes an LED 1326 red. In some embodiments, a speaker withinthe monitoring client 1302 may issue an audible alert.

In some embodiments, aspeaker within the monitoring client 1302may serve as a backup speaker to thedock 1304, and the speaker 1324 of the dock1304 may serve as a backup speakerto the monitoring client 1302.

The charger 1312 can charge the battery1314 using AC power suppliedh the AC power cord 1316. Additionally or alternatively, the charger 1312can charge a battery 1328 within the patimt-care device1318.

In some embodiments, the ss dock 1306 may include the samehardware as the dock 1304 andmay or may not include the AC power cord 1316.

For example. the wireless dock 1306 may include a plurality of contacts forpositioning the wireless dock in a recharging cradle that includes a plurality ofts that engage the contacts of the ssdock 1306 for charging a batterytherein.

Fig. 19 is a block diagram of an electronic patient-care system 1400 inaccordance with another embodiment of thepresent disclosure. System 1400includes a monitoring client 1402. a dock 1404, a large volume pump 1406. asyringe pump 1408. and s 1410. System 1400 also include a USB sensor1412 d to the dock 1404 through a USB cable. a wireless sensor 1414 inwireless communication with the dock 1404, a server 1416. and a hospitalinformation server 1418. The monitoring client 1402 may be any n'ng client.such as one of the monitoring clients 1, 4, or 11 of Figs 1, 3, 5, 7. 8. the monitoringclients 9. 4. or 11 of Fig. 9. a tablet, a smartphone. a PDA. a laptop. and the like.

The dock 1404 can communicate via the electrical conductor shown in Fig. 19and/or via wireless to one or more of the large volume pump 1406. 1408, and/or the[0 sensors 1410 to receive parameters andlor to control the devices.

The dock 1404 receives AC power 1420 from an AC outlet 1422. The dock1404 is in operative communication with the monitoring client 1402 using amonitoring-client adapter 1424. The monitoring-client adapter 1424 is d tothe dock 1404 through Ul connectors 1426, 1428. The UI connectors 1426. 1428IS provide power to the monitoring-client adapter 1424 and data h a USB link.

The monitoring-client adapter 1424 is coupled to the monitoring client 1402 throughseveral connectors 1430. 1432. 1434, 1436. Two of the connectors 1430, 1434e power from the monitoring-client adapter 1424 to the monitoring client1402, while two other tors 1434. 1436 provide a USB connectiontherebetween to facilitate digital communications between the dock 1404 and themonitoring client 1402. Note that other embodiments may employ connectionsother than the USB—type.

Connectors 1438-1450 allow the dock 1404 to operatively provide power tothe large volume pump 1406, the syringe pump 1408. and sensors 1410.

Additionally or alternatively. connectors 1438 and 1440 provide serialcommunications between the dock 1404 and the large volume pump 1406;connectors 1442 and 1444 provide serial communications between the largevolume pump 1406 and the syringe pump 1408; and. connectors 1446 and 1448provide serial communications between the syringe pump 1408 and the sensors1410. Connector 1450 provides optional expansion for additional s (notshown).

System 1400 shows a daisy-chained system for coupling together ldevices together. Each device either digitally routes data destined for anotherdevice to a subsequent device. or each device includes electrical conductors suchthat both of its connectors include ical connections to respective pins.

The dock 1404 can communicate with the wireless sensor 1414 using. forexample, Bluetooth. Bluetooth low energy. Zigbee. Xbee. ANT. ANT Plus. and thelike. The sensors 1412. 1414. andfor 1410 may be a patient-monitoring device. orone or more environment sensors. such as a temperature sensor. humidity sensor.a camera, a microphone. an t light sensor, a vibration sensor. and the like.

The server 1416 can communicate with the hospital information system1418. The server 1416 provides a WiFi router such that the dock 1404 is inive communication with the hospital information system 1418. ationmay be transferred to and from the hospital information system 1418 through theserver 1416. which can translate protocols of the dock 1404 to and from thehospital information system 1418 or Health Level 7 ("HLT"). The server 1416(andlor the hospital information system 1418) may include a drug error reductionIS system (“DERS”) system that checks to determine that any treatments beingapplied to a patient using the system 1400 is safe for the t. The server 1416may be the monitoring server 3. and the hospital information system 1418 may bethe facility services 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-care1400 system of Fig. 19 in accordance with an embodiment of the presentdisclosure. In some embodiments. each of the components shown in Fig. 20 isopuonaLDock 1404 es an ACIDC converter 1452 for receiving the AC power1420 (see Fig. 19). The ACIDC converter 1452 may include rectifier try.smoothing circuitry. a switched-mode power supply. a linear regulator. and the liketo convert the AC power to DC power 1454. in some ments of the presentdisclosure. the ACIDC converter 1452 may be external to the dock. in otherments. the AC/DC ter 1452 is located within the dock 1404.

The DC power 1454 is received at the DC power entry 1456. which may be aconnector to connect the positive and negative leads of the DC power 1454 topower and ground planes of a PCB board, respectively. The DC power entry 1454provides power to the circuitry of the dock 1404. The DC power entry 1456 mayalso receive wireless power 1458.'112The power received via the DC power entry 1456 is sent to charging circuitry1460. The charging circuitry 1460 charges a primary battery 1462 and a backupbattery or super-capacitor 1464. The charging circuitry 1460 may employ scharging techniques, for example. a nt-currentlconstant-voltage chargingalgorithm.

The dock 1404 includes a y processor 1466 and a safety processor1468. The primary processor 1466 is powered by the primary battery 1462. Thesafety processor 1468 is also powered by the primary battery 1462, but also canreceive power from the backup battery or super-capacitor 1464.with aID In this example ment, the primary processor 1466 interfacesWiFibarcode reader 1470. a camera 1472, dock sensors 1474. a speaker 1476. atransceiver 1478. a Bluetooth transceiver 1480, a USB controller 1482, LED statuslights 1484, and three internal expansion slots 1486. 1488. and 1490 (each ofwhich is optional).

The al expansion slots 1486. 1488. and 1490 can receive additionalhas acircuitry. For example. as shown in Fig. 20. the internal expansion slot 1486communicationslranging module 1492. and the internal ion slot 1488 has aRFID reader 1494 and a near-field icator 1488 ed therein (eachwhich is optional).

The safety processor 1468 provides a watchdog function to the primaryprocessor 1466. For example. the safety processor 1468 can icate withfromthe primary processor at predetermined intervals. or expects a communicationthe primary processor 1466 at predetermined intervals. If the safety processor1468 does not receive the expected response or communication. it may determinethat an error has occurred. The safety processor 1468 in response to the error maysoundindicated a fault using LED Fault status lights 1401. generating an audiblevibration motorusing a backup speaker 1403. or e the dock 1404 using a1405. As will be appreciated in light of this disclosure, numerous fault notifications(e.g.. telephone call. email. text message, etc) can be issued to numerouspersonnel (e.g., nurses andlor physicians, facility maintenance. etc).

The safety processor 1468 can monitor the power supplied through thedevice connector using current sensing circuitry 1407. If the safety processor 1468determines that the current supplied to the device tor 1438 exceeds apredetermined threshold or is otherwise out of specification, the safety processor1468 s power enable circuitry 1409 to disengage thepower supplied from theprimary battery 1462 to the device tor 1438. The power enable circuitry1409 may include relays. switches. solid-state es.contactors. and the like toconnect and disconnect the primary battery 1462 from the deviceconnector 1438.

The primary processor 1466 is also electrically coupled to a optionalcharge—state display 1411 and a optional display 1413. The -state display1411 can display the charge state of the primary y 1462. The display 1413may be a touchscreen andlor may display the operational status of the dock 1404.

The dock 1404 receives user input via optional buttons 1415.

The communications/ranging module 1492 can communicate with othercommunicationslranging modules 1492. e.g., on a t-care device. other dock.or monitoring client. to determine the ce therebetween. For example. twocommunicationslranging module (e.g.. communications/ranging module 1492 andanother communications/ranging module). may wirelessly communicate. forIS example. via ultrasound. RF. UHF. electromagnetic energy. optically. and the like.to determine the distance between them. In accordance with one embodiment. oneor more of a patient-care . a monitoring .a patient's watchdog. a remotecommunicator. etc. may not e unless each of them having acommunicationslranging modules 1492 determines they are within a predeterminedce relative to each other.

Fig. 21 shows an exemplary arrangement of a system 2100 in which amonitoring client 2102 is linked to a number of patient-care devices via a dock2120. including an infusion pump 2106 connected to and delivering froma smallerbag of fluid 2118. an infusion pump 2108 connected to and delivering froma largerbag of fluid 2116. a drip detection device 2112 connected to tubing from the smallerbag 2118. a pill dispenser 2114. and a microinfusion pump 2110. The monitoringclient 2102 may communicate with these patient-care devices ina wired n, asshown for the infusion pumps 2106. 2108. the microinfusionpump 2110 (via docks2120. 2104). and the pill dispenser 2114. Alternatively. the monitoring client maycommunicate wirelessly with patient-care devices. as ted by the absencea wired connection between the drip detection device 2112 and the monitoringclient 2102. In an embodiment. a wired connection between the monitoringclient2102 and a patient—care device also affords an opportunity for electricalpower to besupplied to the patient-care device from the monitoring client 2102. In this case.the monitoring client 2102 may include the electronic circuitry necessary to convertthe e to power the patient-care device from either a y attached to themonitoring client 2102 or from line e fed into the monitoring client 2102 from apower outlet (not shown) in a patient's room. Additionally or alternatively. the dock2104 supplies power to the infusion pumps 2106. 2108 and the nfusion pump2110.

In an embodiment. the monitoring client 2102 is capable of receivinginformation about each patient-care device with which it is linked either directly fromthe device itself. or via a docking station. such as. for example. the dock 2104 ontoIO which the patient-care device may be mounted. The dock 2104 may be configuredto receive one or more patient-care devices via a standardized connection mount.or in some cases via a connection mount individualized for the particular device.

For example. in Fig. 21. infusion pumps 2106 and 2108 may be d to thedock 2104 via a similar connection mount. whereas the microinfusion pump 2110.for example. may be mounted to the dock 2104 via a tion mount configuredfor the particular dimensions of the microinfusion pump's 2110 housing.

The dock 2104 may be configured to electronically identify the particularpatient-care device being mounted on the docking station. and to transmit thisidentifying information to ring client 2102. either wirelessly or via a wiredconnection. Additionally. the particular patient-care device may be preprogrammedwith ent information (e.g.. patient-treatment ters such as an infusionrate for a predetermined infusion fluid) that is transmitted to the ring client2102. In some embodiments of the present disclosure. the monitoring client 2102communicates with EMR records to verify that the grammed treatmentinformation is safe for an identified patient andlor the preprogrammed treatmentinformation matches the prescribed treatment stored in the EMR records.

In some ments. the drip detection device 2112 may communicatewith the monitoring client 2102 either wirelessly or in a wired connection. If anaberrant fluid flow condition is detected (e.g.. because the tubing to the t hasbecome occluded). a signal may be transmitted to monitoring client 2102. which (1)interface eithermay display the flow rate of fluid from fluid container 2118 in a userlocally on monitoring client 2102. or more remotely to a user interface at a nurse'sstation or a handheld communications device. (2) may trigger an auditory or visualalarm. (3) may alter the rate of infusion of a pump 2108 connected to bag 2118. byeither terminating the infusion or othenrvise changing the g rate.or (4) maycause an audible alarm (and/or vibration alarm) on the infusionpump 2106. Thealarms may occur simultaneously on several s or may follow apredetermined schedule. For example, when an occlusion occurs in a lineconnected to the infusion pump 2106, (1) the drip ion device 2112 alarmsusing its internal speaker and an internal vibration motor, (2) thereafter. the infusionpump 2106 alarms using its al speaker and an internal vibration motor. (3)next, the monitoring client 2102 alarms using its internal speaker and an internalvibration motor. and (4) finally. a remote communicator 11 (e.g.. see Figs. 1, 3. 5. 7.8, 9) alarms using its internal speaker and an internal vibration motor.

In some embodiments, an individualpump may be programmable to allowfor continued operation at a predetermined pumping rate should communicationsfail between the monitoring client 2102 and the pump. either e of amalfunction in the monitoring client 2102, in the communications channel betweenIS the monitoring client 2102 and the pump. or in the pump itself. In someembodiments, this independent function option is enabled when the medicationbeing infused is pre—designated for not being suspended or held in the event of amalfunction in other parts of the system. In some embodiments, a pumpmmed to operate ndently in a fail safe mode may also be configuredto e information from a drip detection device 2112 directly. rather thanthrough a ring client 2102. With this option. the pump may be programmed.in some embodiments. to stop an infusion if the drip detection device 2112 detectsan aberrant flow condition (such as, e.g., a free-flow condition or an air bubblepresent in the infusion line). In some embodiments, one or more of thepumps2106. 2108, and 2110 may have al fluid flow meters and can operateindependently as a stand-alone device.

Fig. 22 shows an electronic patient-care system 2200 having a tablet 2102docked into a clock for wirelessly communicating with patient-care devices2106.2108, 2110, 2112, 2114 in accordance with an embodiment of the presentdisclosure. The monitoring client 2102 may communicate with the patient-caredevices 2106. 2608, 2110. 2112 wirelessly or h a wireless transceiveron thedock 2120. For example, the monitoring client 2102 may communicate to atransceiver within the dock 2104. Additionally or alternatively, the dock 2120include a transceiver for use by the monitoring client 2102 for communicatingwithdevicesthe dock 2104 andlor directly via a wireless connection to the patient-care2106. 2108. 2110. 2112. 2114.

Fig. 23 shows an electronic patient-care system 2300 having modularinfusion pumps 2302. 2304, 2306. 2308 that dock into a dock 2310 having awithmonitoring client 2312 with in accordance ana retractable user interfaceembodiment of the present disclosure. The modular on pumps 2302. 2304,be snapped into the2306, 2308 have standardized connectors so that they mayincludesdock 2310. Each of the modular infusion pumps 2302, 2304. 2306. 2308the modular on pump 2302 includes aa user interface. For example.

IO touchscreen 2314, a start button 2316, a stop button 2316, an increase-infusion-rate button 2320. and a decrease-infusion-rate button 2322. Fig. 24 is a side-viewof the electronic patient care system 2300 of Fig. 23 and shows an outline of acavity 2400 in which the monitoring client 2312 can retract into because2312 can be rotatedmounting pole 2402 is movable such that the monitoring clientalong pivot 2404 and pushed down into the cavity 2400.modularFig. 25 shows an electronic patient-care system 2500 havinginfusion pumps 2502, 2504, 2506, 2508 that dock into a dock 2510 having a2502.monitoring client 2512 with a retractable user interface. the infusion pumps2504, 2506, 2508 are arranged in a staggered fashion in accordance with rment of the present disclosure. System 2500 of Fig. 25 may be similar tothe system 2300 of Fig. 23. except that system 2500 of Fig. 25 has the moduleinfusion pumps 2502. 2504, 2506, 2508 arranged in a red fashion. The2508 may providestaggering of the modular infusion pumps 2502. 2504. 2506.more room for tube routing.2600 modularFig. 26 shows an electronic patient-care system havinginfusion pumps 2602. 2604. 2606 that dock into a dock 2608 along a commonThe dock 2608 includes a monitoring client 2610 that ishorizontal plane.retractable into the dock 2608. .The monitoring client 2610 may be wholly2610's circuitryretractable into the dock 2608 andfor some of the monitoring clientmay be housed in the dock 2608. As is easily seen fromFig. 27 which shows aclientiew of the onic patient-care system 2600 of Fig. 26. the monitoring2610 into a cavity2610 pivots along a pivot 2700 for ting the monitoring client2702 inside of the dock 2608.

Fig. 28 shows another embodiment of an electronic patient-care system2900 including a hub 2902 coupled toa device dock 2904. Fig. 29 shows a side-view of the electronic patient-care system 2900 ofFig. 28. The monitoring client2901 is integrated with the hub 2902. in alternativeembodiments. the hub 2902 is acradle for the monitoring client 2901 and only provideselectrical tions to thedock 2904 and the scanner 2912. Modular infusion pumps 2906. 2908, 2910shown as docked into the device dock 2904. The system 2900 also includes ascanner 2912 coupled to the hub 2902. The dock 2904 includes quick releasehandles 2914 and 2916 on the left and right side of the dock 2904,respectively.

Also shown in the upper left corner of each of the modular infusionpumps 2906,2908, and 2910 pumps is a respective button 2918. 2920. and2922 that lights upwhen that patient-care device is the focus of interaction on the monitoringclient2901 (shown as a tablet, a type of monitoring client)or is selected for control by auser. Either the tablet can select the specific modularinfusion pumps or the usercan push the respective button of the buttons 2918. 2920,and 2922 of the modularinfusion pumps 2906, 2908. and 2910 to select it formanipulation on the monitoringclient 2901.

Figs. 30-32 show l views illustrating a clutch system formounting anelectronic patient-care system on a pole in accordancewith an ment of thepresent disclosure. Fig. 30 shows atop view of a dock 3100 havinga hole 3102 forreceiving a pole 3104. The clutches 3110 and 3112 are shown inFig. 31. in someembodiments, the clutches 3110, 3112 include cleats 3114, 3116. The handles3106 and 3107 may be used, duallyor together. to release the clutches 3110and 3112 from the pole 3104 (e.g., by pulling on thehandles). Additionally oralternatively, the handles 3106 and 3107 may be used for locking the clutches3110and 3112 to the pole 3104 (e.g., by pushingon the handles 3106, 3107). As iseasily seen from Fig. 31. a downward force, e.g., from gravity. furthercompress theclutches 3110. 3112 against the pole 3104. Although two es 3110. 3112 areshown in Fig. 31. one clutchmay be used to press the pole 3104 against a onsurface. Fig. 32 shows an ative pole mounting structure 3300 in which twofasteners 3302 and 3304 are used to clamp downon the pole 3104.

Fig. 33 shows an infusion pump 3400 and retractable connectors3402. 3406in accordance with an embodiment of thet sure. In Figs. 33-35. a hub3401 is shown as having the retractable connectors3402 and 3406. The hub 3401has docking connectors making it also a dock. The retractable connectors 3402and 3406 are shown as closed in Fig. 33. However. in ative embodiments,to the infusionthe retractable connectors 3402 and 3406 may be connected directlyandlor additional infusion pumps. The hubpump 3400. the infusion pump 3412,3401 may have a pole mounting mechanism that is enveloped by the hub 3401(see Fig. 36). The hub 3401. in some embodiments, may be a dock or a cradle.handle may beand may optionally include a handle coupled to the top thereof; thehandle alsointegrated into the pole attachment mechanism such that picking up thereleases the hub 3401 from the pole. Alternatively. in some ments. the hubIO 3401 could support a cradle to attach it to a monitoring client, e.g.. a tablet. or themonitoring client could be attached to the pole separately. The retractable3402 and 3406. in some ments. could haveconnectors a supportism (e.g.. a lip) on the bottom of the retractable connectors 3402 and 3406to support an infusion pump when attached. In this example embodiment. the lipfor electrical tion.may also be the mechanismand connectorsIn Fig. 34, the retractable connector 3402 is shown as open.3408 and 3410 are shown. Although the connectors 3408 and 3410 are shown onthe retractable tor 3402. in other ments, the connectors 3408 andis a cover to cover the3410 are on the hub 3401 or on pump 3400 and 3402connectors 3408 and 3410. The retractable connector 3406 has an infusion pumpto the3412 docked thereto. Fig. 35 shows an infusion pump 3416 dockedconnector 3402, and the infusion pump 3412 is docked to theretractableretractable connector 3606. The infusion pumps 3400. 3412. and 3416 areelectrically connected together in Fig. 35 via the hub 3401. Fig. 36 shows a topthe pole 3420 ofview of the infusion pump 3400 and the hub 3401 as attached toin the openFigs. 33-35. The retractable connectors 3402 and 3406 are shownuration.

Fig. 37 shows a square-shaped hub 3701 having several connectors 3703.3705, 3707, 3709 in accordance with an embodiment of the present disclosure.to connectEach of the connectors 3703, 3705, 3707, and 3709 may be usedadditional batteries, communication modules, scanners. a monitoring client. aring client's Ul. t-care devices, and the like. Each of the connectors3703, 3705. 3707, and 3709 may use a standard pin-out in which the modulesattached thereto use a subset. in some embodiments. each of the connectors3703. 3705. 3707, and 3709 may use a subset of the availablepins that are uniqueto the device that is connected basedupon the type of device. e.g.. as determinedfrom a signal. A pole mounting mechanism could be locatedon the back of thesquare-shaped hub 3701. The square-shaped hub 3701may also include front3711 and back 3713 connectors.

The mechanical attachments ated witheach of the connectors 3703. 3705, 3707, 3709.3711. 3712 may be permanentattachments (e.g. screws) or quick-release mountingpoints (e.g. latches).

Fig. 38 shows an electronic patient-care system having a hub 3701coupledto a pole 3715 in accordance with another embodimentof the present disclosure.

Fig. 38 shows an articulating monitoring client 3712 on the left. an extendedbatterylcommunication module 3717 on top, a barcodescanner module 3719 onthe bottom. and a pump dock 3723 on the rightof the hub 3701. Thepump dock3723 is removable for transportation with all the infusion pumps 3725, 3727, 3729ed such that they allmay be transported as one unit. A quick-release handle3731 may be located on top of thepump dock 3727 to allow easy ment fromthe hub 3701. Alternatively. in other embodiments. the infusionpumps 3725. 3727.3729 may be daisy chained er. The articulatingring client 3721 (e.g., atablet) may be attached permanently to the hub 3701, which could make up a"Zero-Channel Pump" when the dock 3723 is d. For example, themonitoring client 3721 may continue to operate and r spatient-caredevices when no pump is attached to and/or is inoperative communication with themonitoring client 3721.

Fig. 39 shows an electronic patient-care system havinga hub 3701 coupledto a pole 3715, and a portable dock 3733 that includesa quick-release handle 3731to detach the le dock 3733 from the hub3701 in accordance with anotherembodiment of the present disclosure. The hub 3701 allows for devices to beconnected thereto using an adaptor plate 3735as shown in Fig. 40.

Fig. 40 shows an electronic patient-care system havinga hub 3701 coupledto a pole 3715 and a dock 3735 dto the hub 3701 in accordance withanother embodiment of the present disclosure. The dock 3735 of fig. 40 is shownas a connector plate. That is. the dock 3735 is shown as an adaptor or connectorplate adapted to facilitate the connection of the infusionpumps 3725. 3727. 3729 tothe hub 3701 using the generic connector provided by the hub 3701. The dock3701 provides ient signals and sufficient mechanical alignment and orientationfor connecting to the dock 3735 andfor vice versa.

Fig. 41 shows an electronic patient-care system 4101 having a hub 4103coupled to a pole 4105 in accordance with another embodiment of the presentdisclosure. The hub 4103 includes connectors 4107, 4109, and 4111 for receivingrespective on pumps, e.g., infusion pumps 4113 andlor 4115. Thethreepatient-care system 4101 includes a monitoring client 4117, e.g., a tablet, on oneside of the pole 4105 and the infusion pumps attachable to the other side of thepole 4105 via the connectors 4107, 4109, and 4111. Although three connectors4107, 4109, 4111 are shown, any arbitrary number of connectors may be used.

Electronic patient-caresystem 4101 facilitates viewing of the ring client 4117and the infusion pumps, infusion pumps 4113 and 4115, attached to thee.g.,connectors 4107 4109, 4111. Additionally, electronic patient-care system 4104facilitates routing of the tubes. The tubes may be inserted from top to bottom of theinfusion pumps or may be routed from the monitoring client 4117's side (e.g., usingThe monitoringa tube organizer on the pole 4105) on a side of the pole 4105.client 4117 may be articulated. The pole mount of the hub 4103 may clamp topole 4105 or slip over the step in the pole 4105 that is available in some adjustablepoles. The pole mount of the hub 4103, show here as being tubular shaped, may,in other embodiments, be a gular shape and/or may include the powersupply, handle, and/or hub re. In some embodiments, the hub 4103 may bea cradle to route electrical connections.

Fig. 42 shows an electronic patient-care system 4201 having a ringclient 4203 coupled to a hub 4205 having notches 4207, 4709, 4711 for receivinganothert-care devices, withe.g., an infusion pump 4713, in accordanceembodiment of the present disclosure. This on pump 4713 includes a slidingconnector 4715 that slides into one of the notches 4207, 4709, 4711. Theconnector 4715 may be structurally sufficient and/or onal structural support4203 may fold down,may be added. The monitoring client e.g., flat with the dock4205. The dock 4205 may include reliefs for routing tubes, e.g., from left to right orup to down. In alternative embodiments, the infusion pump 4713 may attach to thedock 4205 such that it is raised in front of the dock’s 4205 front plane facilitatingvertical routing of the tubes. Fig. 43 shows a close-up view of a T-shapedconnector. e.g., connector 4715 of Fig. 42, for connecting with the notches 4207,4709, 4711 of the hub 4205 as shown in Fig.

Fig. 44 shows an electronic patient-care system 4401 having stackablepatient-care s 4403, 4405 and a stackable container 4407 for housing aninfusion bag, e.g., on bags 4411 and 4408, in ance with anotherembodiment of the present disclosure. The stackable container 4407 includes a lid4413 for securing the bags 4411, 4409 therein. The electronic patient-caresystem4401 includes a monitoring client 4415 with a screen thatmay be folded down anda handle 4417 that may be pulled up for portability.

The on bags 4411 and 4407may be microbags and may include anintegrated flow rate monitor andfor an RFID tag embedded n having a serialnumber or data (e.g., patient data) associated with the contents of the bags4411adfor 4407. In this specific embodiment, the microbags 4411 and 4407 maye an integrated flow rate meter, a drip counter, an integrated drip chamber,communication link to icate via the N tube, and may include a powersupply with or without a battery or ACIDC converter to power the electronicsthereon. The N communications may occur via an electrical conductor embeddedinto or attached to the intravenous tube, via electrical icationusing the fluidwithin the intravenous tube as a conductive medium, using soundswaves travelingthrough the intravenous tube, or optically by using the fluid within the tube as anoptical waveguide. The N communications may be encrypted, e.g., usingsymmetric or tric key tion. The microbags 4411 andlor 4407 mayinclude an optical communicator that communicates data (viaan infusion tube) toan infusion pump describing a flow rate andlor the contents of the liquid containedtherein. The microbags 4411 andlor 4407may include an RFlD and/or NFC tag ata pigtail that can interface with a drip counter which a readermay use to determinethe contents and/or volume of the liquid inside of the microbags 4411 and/or4407(e.g., the information is encoded therein) . The microbag 4411 and/or 4407 mayinclude a bubble sensor (capacitive or ultrasonic) which communicates theestimation of bubble sizes to a monitoring client and/or hub. The microbags4411andlor 4407 may need to be within a predetermined distance from the t asdetermined by NFC, and/or a ranging module before it will operate (e.g., open avalve and/or active an integrated flow rate meter, drip counteror drop chamber, acommunication link. power supply etc.)1 22Fig. 45 shows an electronic patient-care system 4501 having stackablepatient-care devices 4503, 4505, 4507, 4509, 4511, 4513, 4515, 4517 that areble next to r one of the patient care devices in accordance with yetanother embodiment of the present sure. The electronic patient-care system4501 includes a monitoring client 4519 that es a screen that may be foldeddown and a handle 4520 that may be pulled up for portability.

Fig. 46 shows an electronic patient-care system 4601 having stackablepatient care devices 4603, 4605, 4607 with a syringe pump patient-care device4607 having a single syringe 4609 in accordance with r embodiment of thepresent disclosure.

Fig. 47 shows an electronic patient-care system 4701 having stackablet-care devices 4703, 4705, 4707, 4709 with a syringe pump patient-caredevice 4707 having two syringes 4711, 4713 in accordance with anotherembodiment of the present disclosure.

Fig. 48 shows an electronic t-care system 4801 having blepatient-care devices 4803, 4805, 4807, 4809 each having a tive display (i.e.,displays 4811, 4813, 4815, 4817) in accordance with another embodiment of thepresent disclosure. Fig. 49 is a close-up view of the handle 4901 of the electronicpatient-care device of Fig. 48. Fig, 50 is a close-up view of an infusion line port5001 showing an infusion line 5003 positioned therethrough of the electronicpatient-care system 4801 of Fig. 48.

Figs. 51-52 show another embodiment of an electronic patient-care system5101 showing a removable stackable patient-care device 5102 in accordance withanother embodiment of the present disclosure. Fig. 52 shows the handle 5103being moved in a transport configuration to transport the electronic patient-caresystem 5101 with a pole 5105.

Fig. 53 shows an electronic-patient care system 5301 coupled to a pole 5317and having stackable t-care s 5307, 5309, 5311, 5313, 5315 that arecoupled to a hub 5303 via a dock connectors 5305 in accordance with anotherembodiment of the present disclosure. The hub 5303 is coupled to a monitoringclient 5305. The dock connectors 5305 connect to patient-care devices 5307 and5309, which are connected to patient-care devices 5311, 5313, and 5315 via daisy-chained connections.

Fig. 54 shows an electronic-patient care system 5401 having stackablet-care devices 5403, 5405, 5307, stackable from the bottom up, inaccordance with another embodiment of the present disclosure. Fig. 55 shows anelectronic-patient care system 5501 having stackable patient-care devices 5503,5505, 5507 that are ble from the top down, in accordance with anotherembodiment of the present sure.

Fig. 56 shows a perspective-view of a clutch system 5601 having a releasehandle 5603 for frictionally gripping to a pole 5605 in accordance with anotherembodiment of the present disclosure. Fig. 57 shows a back-view of the clutchsystem 5601 of Fig. 56 showing a arent back for illustrating theuse of thehandle 5603 to engage clutches 5607 and 5609.

Fig. 58 shows a top, cross-sectional view of the clutch system of Fig. 56.

Fig. 59 is a block diagram of a system 3400 to control an infusion pump inaccordance with an embodiment of the t disclosure. System 3400 includesuser interface ent 3402, a ngine component 3404, a data-management y layer component 3406, and a fluid measurementlsafetymonitor component 3408.

The components 3402, 3404, 3406, and 3408 may be implemented. forexample, in hardware, software, software in execution, in digital logic, firmware,bytecode, in virtualization, using PLDs, FPGAs or PLAs, using one or moreprocessors, or some combination thereof. For example, the components 3402,3404, 3406, and 3408 may be an operative set of processor executable instructionconfigured for execution by one or more sors on a device 3401,e.g., thedevice 3401 may be a ring client disclosed herein. The components 3402,3404, 3406, and 3408 may be stored on non-transitory, computer readable mediumreadable by one or more processor for execution by theone or more processors,e.g., the one or more sors may be in operative communication with the non-transitory, computer readable medium.

The user interface 3402 may be a touchscreen (or processor executablecode to control a touchscreen) configured to receiveuser input, e.g., an infusionrate. The user interface 3402 may be used by an operator toset up treatmentparameters and to see treatment status. The user interface 3402 can be used toadjust patient-treatment parameters during therapy, for guidance on the setup ofthe system 3400, and/or for post-treatment disassembly ofthe system 3400. Theuser interface 3402 may include a touchscreen and buttons. The user interface3402 may be a resident software application on the device 3401 or may beexecuted by a remote or separate component, such as on a ld device or acomputer at a nurses” station. For example, the user interface 3402 may beimplemented by the remote icator 11 or the other monitoring clients 1, 4 ofFigs. 1, 3, 5, 7, 8 or 9, a smartphone, a tablet, a pc, 3 tablet computer. or the like.

The data management therapy component 3406 can communicate with oneor more external data systems 3410. For example, the data management therapyent 3406 may compare the a patient’s 3412 ID with electronic medicalrecords 3410 to determine if the therapy entered (e.g., an infusion rate) via the userinterface component 3402 is: (1) safe for the patient; (2) conforms with the patient's3412 ailment, condition, disease, andfor therapy plan; (3) is not contraindicated byanother medication or treatment; (4) and does not require the presence of alists not-determined to be within the proximity to the patient 3412 (asdetermined by an RFID tag, voice authentication, -recognition,usernamelpassword identification or verification, secure signatures, or the like).

The data management therapy component 3406 may include all treatmentsettings, may verify settings with the external data systems 3410, and can logtreatment history such as flow rates, drug gs, vital signs, etc. to the electronicmedical records of the external data systems 3410. The data management therapycomponent 3406 may also set parameters for any safety monitors. If the datamanagement therapy component 3406 confirms the treatment, the setting is sent tothe pump engine component 3404.

The pump engine component sends 3404 sends the t-treatmentparameters, e.g., an infusion rate, to the infusion pump 3414. The on pump3414 may be any infUSion pump sed herein. In some embodiments of thepresent disclosure, the pump engine component 3404 only sends an infusion rateto the pump 3414. The pump may have fluid ement capability that isredundant to a flow meter or is the primary fluid measurement of the system 3406.

The fluid measurementlsafety monitor ent 3408 may serve as awatchdog for the other pump engine ent 3404, can receive flow data from aflow meter (not shown), and may serve as a watchdog for the pump 3414. The fluidmeasurement/safety monitor component 3408 can determine if a fault or errorcondition exists, e.g., the infusion rate as measured is outside of a predeterminedrange or is beyond a threshold, and can communicate a stop command to thepump 3414 to stop the pump 3414. Additionally or alternatively, the fluidmeasurement/safety monitor component 3408 can communicate to a mechanicalocclusion device (not shown) to stop the flow of the infusion fluid to the patient3412.

Additionally or alternatively, the fluid measurementlsafety monitorcomponent 3408 may e ck on flow rate as well as patient-conditionters, e.g., heart rate, temperature, vital signs, etc. if any of the parametersmonitored by the fluid ement/safety monitor component 3408 are e ofa predetermined range, an alert, such as a text message or email, is issued, e.g., toa monitoring device, a remote communicator, other monitoring clients, asmartphone, a tablet, a pc, 3 tablet computer, or the like. Additionally oralternatively, a mechanical fluid the fluid measurement/safety monitor ent3408 can communicate to a mechanical occlusion device (not shown) to stop theflow of the infusion fluid to the patient 3412.

Fig. 60 is a block diagram of system 3500 for communicating with severalelectronic patient-care devices 3502, 3504, 3506, 3508, 3510 in accordance withan embodiment of the present disclosure.

System 3500 includes a wireless or USB based dock or hub 3518. The dock3518 is coupled to a drip counter 3502, an infusion pump 3504, a wearable systemmonitor 3506, a pill dispenser 3508, and other device 3510. The other device maybe, for example, various t-condition devices, such as a pulse oximeter device,a heart monitor device, a blood re , and a temperature device. Thedevices 3502, 3504, 3506, 3508, 3510 communicate with the monitoring ,e.g., a tablet 3514, which in turn communicates with one or more servers 3516.

The one or more servers 3516 may be, for example, a server of the facility services8, the online drug databases 9 or drug adverse event network 9, the patient’spersonal HER 19', or a treatment outcomes database 10 of Figs. 1, 3, 5, 7, or 8.

The wireless communications between the wireless or USB dock 3518 anddevices 3502, 3504, 3506, 3508, 3510 may be, for example, WiFi, Bluetooth, lowenergy Bluetooth, Zigbee, a communications link capable of ranging, near fieldications, RFID communications, and the like.

The tablet 3514, in some embodiments of the t disclosure, may be theprimary programming and monitoring interface. The tablet 3514 may be configuredfor a single patient or may be configured when docked into a dock 3518 or whenthe tablet 3514 identifies a patient (e.g., the tablet 3514 may download patient-treatment parameters after a patient’s ID is entered into the tablet 3514 manually,h an RFID reader, a barcode reader, etc).

The tablet 3514 may icate patient-condition parameters or patient-ent parameters to the one or more servers 3516. The one or more servers3516 may store the patient-condition parameter or patient-treatment parameters.

The tablet 3514 may communicate the patient-care ters, e.g., the patient-condition ters or the patient-treatment ters, in real time (i.e., with atleast one time constraint such as a deadline).

The tablet 3514 may connect to the dock 3518 wirelessly, through a USBcable, or may dock thereto. The tablet 3514, in some embodiments, receivesfrom the dock 3518.power and data through one or more wired connectionsThe infusion pump 3504 may be a low rate infusion pump (e.g., can deliver0.1-10 milliliters per hour), a medium flow rate infusion pump (e.g., can deliver 10-300 milliliters per hour), a high flow rate infusion pump (e.g., can deliver 300-1000milliliters per hour), an infusion pump that switches n the various flow ratesettings, or some combination thereof. The infusion pump 3504 may be edbe ainto the hub 3518 through a receiving portion; that is, the hub 3518 may alsodock (not shown in Fig. 60). The infusion pump 3504, in some embodiments of thepresent disclosure, receives power and data through one or more wiredconnections from the hub 3518. The infusion pump 3504 may be configured to beundocked from the hub 3518 and can continue to operate while being carried bythe patient. The infusion pump 3504 may be sent to a pharmacy for configurationIn someand/or to be attached to an infusion bag (also referred to as an IV bag).embodiments, the infusion pump 3504 may be configured to operate only with aspecific bag and/or a specific patient.

The wearable system monitor 3506 may be the wearable system monitor131 of Figs. 1, 3, 5, 7, 8, or 9. In some embodiments, the wearable system monitor3506 may read patient fication off of a smart arm-band, e.g., via RFID, canprovide watchdog functionality for any of the other devices 3502, 3504, 3508, 3510,can track flow rate, detect air, monitor vitals, or include a call button atedthereon. The wearable system monitor 3506 can occlude flow in response to anerror condition. The wearable system monitor 3506may communicate wirelesslywith the hub 3518 or the infusionpump 3504.

Fig. 61 is a block diagram of an electronic patient-care system 3700 having adock 3702 connectable to patient-care devices 3704, 3706Cthrough USBconnections in accordance with an embodiment of the present disclosure.

System3700 includes a dock 3702 which receives a tablet 3708. The dock 3702 isd to a hub 3710 which includes USB connections and can connect to docks3712 and 3714 through USB connections. Dock 3712 receives the pill dispenser3704. The dock 3714 receives infusionpumps 37OBC. Docks 3712 and3714 provide power to the devices 3704, 3706A-37060 dockedthereto.

The dock 3702 supplies power to and charges the internal battery of thetablet 3708. The dock 3702 is also coupled to an USB hub 3710, which the tablet3708 is a host. The flow meter 3716, e.g., a drip counter, and the wearablesystemmonitor 3718 communicate wirelessly to the tablet 3708 via an antenna andtransceiver on the tablet 3708 and/or via a transceiver andantenna on the dock3702. As will be appreciated in light of this disclosure, flow meter 3716 andwearable system monitor 3718 may be operatively coupled with,or othenrvise haveintegrated therein, transceivers and antennas such as communication s 124and antennas 122 of Fig. 1, so as to tate the wireless communication with thetablet 3708.

Fig. 62 is a process diagram 3800 showing several stages of electronicpatient-care in accordance with an ment of the t disclosure. Theprocess diagram 3800 may be a method for electronic patient-care for use, forinstance. with the example systems of Figs. 1, 3, 5, 7, 8, and 9. Process diagram3800 includes stages 3802-3810. Stage 3802 includes the steps of a physicianing patient data and previous treatment history in electronic medical s,and entering a prescription into a computerized physician orderentry server 3812.

Stage 3804 includes the steps of a pharmacist preparing a drug container,identifying a ner with a printed label andlor an RFID, and selecting a deliverydevice. Stage 3806 includes the steps of delivering a container to a patient or asurgical ward, and tracking the container, e.g., a controlled substance. Stage 3808includes the steps of a nurse gup and adjusting treatment, and checking the5R's (right patient, right drug, etc). Stage 3810 includes the steps of delivering theissues anddrug, logging the treatment history into an electronic medical records,alerts or alarms, and patient surveillance, e.g., monitoring the patient.docked to aFig. 63 shows a system 3900 having an on pump 3902dock 3904, a pill dispenser 3906 docked into a dock 3908. and a hub 3910 forinterfacing with the docks 3904 and 3908 via USB cables. The hub 3910 alsointerfaces with a tablet dock 3912 that receives the tablet 3914. Additionally ortablet 3914 icates with the hub 3910 wirelessly. Thealternatively, theused fortablet 3914 may issue an alert and/or alarm when the mode or technologywired to wireless or fromcommunicating changes, e.g., when changing fromwireless to wired.betweenThe hub 3910 includes a display 3916 and provides an interfaceGUI displayedthe tablet 3914 through the dock 3912. The hub 3910 can support afor setupon the display 3916 (which may be a touchscreen) programming,ce. status, displaying alerts, displaying alarm, etc.all ofIn some embodiments of the present disclosure, the hub 3910 includesfault nt of anythe t-safety circuitry enabling the system 3900 to be fullyand the userfaults or errors that may occur within or regarding the tablet 3914,of ainterface necessary for patient safety is either on the hub 3910 or on a display3902 e a displaypatient-care devices 3906 and 3902 (e.g., the infusion pump3918, but not explicitly shown device 3906). For example, the hub 3910 mayrequire user ation (e.g., via a touchscreen of the hub 3910) of an infusionfor therate and drug to be delivered prior to sending the request or commandalternatively, in someinfusion rate to the infusion pump 3902. Additionally orthe infusionembodiments, the infusion pump 3902 ts user confirmation ofvia a touchscreen of therate and drug to be delivered prior to operation (e.g.,infusion pump 3902).

The hub 3910 may sound audible tors for help guidance, alertto monitor safetyprompts, alarm prompts. may include independent safety sinto a safetycritical tasks, may be a fail-safe system for putting patient-care devicessensors forstate when an alert or alarm condition occurs, may include independentclock for timecritical s, may include an independent time base or real-timecritical patient-care s. e.g.. real-time patient-care devices, may include abattery backup to power the patient-care devices through a USB cable, and mayinclude a battery charging to circuit for charging the internal battery therein.

The hub 3910 may include a power entry module for ACor DC power supplyand can receive power from a standard ACpower outlet. The hub 3910 may satisfythe requirements for isolation and electromagnetic compatibilityaccording to lEC-60601. The hub 3910 converts the ACpower to a regulated DC power to be usedto charge an internal backup battery, providepower to various circuitry therein, or topower the t-care devices 3906, 3902 via their respective USB cables.

The hub 3910 may include lEC—60601 compliant power supply that isselectable or programmable to allow the attached patient-care deviceto t apower parameter, e.g., a voltage, duty cycle, DC or AC power etc., from the hub3910. The hub 3910 may include one or more ndentpower supplies that areindependent from the primary as defined by lEC-60601.

The hub 3910 includes a backup battery thatmay be used to supply powervia the USB cables or other cables (not explicitly depicted). The hub 3910 mayinclude its own battery charging circuit, e.g., a constant-voltagelconstant—currentcharging circuit.

The display 3916 of the hub 3910may display alarms or alerts based uponsignals received from the patient-care devices 3902, 3906, 3920. For example, thehub 3910 may periodically query the t-care devices 3902,3906, 3920, and ifthe hub 3910 does not receive aresponse from one or more of the patient-caredevices 3902, 3906, 3920 or the tablet 3914, or othenivise one or more of thet-care devices 3902, 3906, 3920 or the tablet 3914 becomesunresponsive,the display 3914 displays an alert or alarm. The alarmmay te to the user thatthe patient-care device is unresponsive. The patient-care devicemay be identifiedby the ring client via serial number, infusion pump channel, drug beingdelivered by the infusion pump, a letter or number being displayedon the patient-care device, via visual mapping of the patient-care devices on the monitoringdevice, and the like. For example, the ring client 3914may diSplay a layoutdiagram of the patient-care devices 3902, 3906, 3920 on its screen to providevisual g of the devices. Thereafter, the problem device, dock, or hub maythereafter be represented as a flashing red device ting to theuser the devicethat is the subject of the alert andIor alarm. The hub 3910may also include statuslights, LEDs, a speaker, a vibrator, or other visual/audio indicator.

The hub 3910 may include, for example, buttonsor other input devices, suchas switches, a stylus input, and the like. In some embodiments of the presentdisclosure, only the hub 3910 issues alerts and/or alarms for the patient-caredevices; however, in other embodiments, the patient-care devices 3902, 3906,3920, or the tablet 3914 issues alerts and/or alarms.

The hub 3910 may include two separate processors, each being a watchdogto each other. The hub 3910 may also include various sensors, such as anambient temperature Thesensor, a pressure sensor, a humidity sensor, etc.sensors of the hub 3910 may be ant to the sensors onthe patient-caredevices 3902, 3906, 3920 or the tablet 3914, or the hub 3910 may give the patient-care s 3902, 3906, 3920, or the tablet 3914 access to the measurement[0 taken by the sensors of the hub 3910.

The hub 3910 may include, for example, WiFi capabilities, Zigbee, Bluetooth,Low Energy Bluetooth, Xbee, Near Field Communication, ranging devices, orlike. The hub 3910 may also e s wired interfaces, such as for example,RS-232, SPI, CAN, USB, Ethernet connectivity, etc.

IS The hub 3910 may also include a failsafe line that is coupled to one or moreof the on the patient-care devices 3902, 3906, 3920 or the tablet dock 3912 which,when pulled low, can cause a safety circuit to cause all of the patient-care devices3902, 3906, 3920 or the tablet dock 3912, or the particular device that causefault, to enter into a fail safe mode. For example, an electrical conductor (Le, awire or line) may exists between the hub 3910 and one or more of that is dto a voltage source via a resistor (i.e., the line is ”high"), and another circuit cancouple the conductor to a ground (the conductor may be so-called “pulled low").some embodiments, but not all embodiments, of the present disclosure, when apatient-care device disclosed herein, such one or more of the t-care devicesfail-3902, 3906, 3920, or a monitoring client, such as a tablet 3914, enters into asafe mode, only critical (a ermined set) of software routines are enabledand/or only critical circuitry (a predetermined set) is powered. In someembodiments, but not embodiments, for example, all try except for the motordriver circuitry of an infusion pump may be disabled, such as radios, displays,display drivers, or other circuitry. onally or alternatively, someembodiments, but not all ments, some software routines or functionality maybe disabled that are not necessary when a specific fail safe mode is entered, suchinformation may beas in an infusion pump, the software that displays configurationdisabled.

The hub 3910 may also include a camera 3922may be used to allow accessto the system 3900, or identify a patient, nurse or drug using facial-recognitionsoftware, or by reading a barcode (2D or 3D). The camera 3922 of the hub 3910may also read drug information and check it against the one or more servers 3926for accuracy, and to ensure the drug is being delivered to the correct patienl.

Additionally or alternatively, the hub 3910 may also include a microphone 3924 toidentify a patient, nurse, or ver using voice-recognition software.

The hub 3910 may also include a r 3928 that isa barcode reader, anRFID reader. or a magnetic strip reader. Thescanner 3928 may be used to allow[0 access to the system 3900, or identify a patient,nurse or drug. The scanner 3928of the hub 3910 may also read drug information and checkit t the one ormore servers 3926 for accuracy, and to ensure the drug is being deliveredto thecorrect patient.

The hub 3910 may also include one or morecomponents for execution byIS one or more processors therein. The hub 3910 may include a watchdogcomponent for verifying at given als that a patient-care device is responding toication queries (for example, a call and response challenge to eacht-care device every 5 seconds or other suitable interval, and if the hub 3910receives no response, the hub 3910 ”pulls" the safety line, i.e., tes that anerror condition exists), a watchdog circuit to monitor health and check voltage levelsof various power supply voltages, a data ity checkto verify that the data beingtransmitted through the hub 3910 is not corrupted and checks internal and routedpackets to be sent to the tablet 3914 or a patient-care device disclosed herein, anda range checker to allow for checking of programmed thresholds. The hub 3910may use data integrity ng.

The hub 3910 can monitor the tablet 3914 andcan separately alarm whenan error occurs on a patient-care device. In some embodiments of the presentdisclosure, the hub 3910 may include all of the safety-critical circuitry and softwaresuch that the system 3900 is wholly fault-tolerant of the tablet’s3914 failures and/oris wholly fault-tolerant of any failure modes of the tablet 3514.

The hub 3910 may e an application programming interface("API") todisplay data on the display 3916 or the tablet 3914. The API may include a securedata class. A patient-care device can use the API to yon the display 3916 ofthe hub 3910. A patient-care device can send a message to the tablet 3914device.instructing the tablet 3914 how to display an interface for the patient-careAdditionally or alternatively, the hub 3910 sends a message to the tablet 3914cting the tablet 3914 to download an application from the one or more serverssend this3926 for displaying a user ace on the tablet 3914; the hub 3910 mayfirst ted to the hub 3910, either via amessage when a patient-care device isUSB cable, or wirelessly (e.g., using pairing as described herein). Additionally oralternatively, the hub 3910 sends an instruction to the tablet 3914 for displaying auser interface for interfacing with the identified patient-carefor allowing an electronic medical recordsFig. 64 shows a system 4000server of one or more servers 4002 to enter a prescription and send theprescription to an infusion pump of infusion pumps 4004A-4004C for confirmationusing the r 4006 and/or using an interface of one or more of the infusionprescription may be sent from EMR records on the pumps 4004C. Theserver 4002 to the infusion pumps 4004A-4004C via an application.application may on a bedside computer 4008 that can be used to determineclinician ance with the prescription. In some embodiments, the application ison the monitoring client. The bedside er 4008 may e an applicationfor interfacing with an EMR server of the one or more servers 4002 through astandard API to download prescription andlor treatment regimes for use on theinfusion pumps 4004A-4004C. The API may include a secure data class. In someadditional embodiments, the hub communicates to the server 4001 throughmiddleware as described above. Additionally or alternatively, referring to Fig. 65,the tablet 4102 asthe application for interfacing with the EMR server may be onshown in Fig. 65. Although the scanner 4104 is shown as being coupled to the hubtablet hub4106, it may be attached to a patient-care device 4108A-4108C, or a4110. Rather than using the scanner 4104 to identify the medication, a camerabarcode on the4112 may be used to identify the medication by reading a 2D or 3Dtion, e.g., on an infusion bag or pill container.the patient-careIn Fig. 66, a system 4200 is shown. A patient-care device ofdevices 4202A-42020 can broadcast patient-care parameters, e.g., a patient-treatment parameter such as an infusion rate to a subscribed device or a paireddevice (see Fig. 67). For example, the on pump 4202A, a hub 4204, a remotecommunicator 4206, a nurses’ station 4208, or a bedside computer 4210 maye the broadcasted signal, such as from a temperature probe (e.g., theinfusion pump 4202A is subscribed to the temperature probe).

The data may havedifferent levels of encryption such that all data is not accessibleto all clients (e.g.,devices subscribing to another devicemay need to have a minimal level of securitypriority). The broadcasted signal may be the same signal received by the tablet4212 or a subset thereof. The broadcasted messagesmay use a cross-platformprotocol, e.g., http, https, etc.

Fig. 67 shows a timing diagram 4300 of communications for the system 4200of Fig. 66 in accordance with an embodiment of thepresent disclosure. The timingdiagram 4300 illustrates the communications using an electronic medical recordsll) application programming interface executed on the tablet 4212. In someembodiments of the present disclosure, a drug error reduction system and/orails (or a cached version thereof) may be exists on the hub 4204 or aninfusion pump of the infusion pumps 4202A-42020 to provideredundant patientsafety when the system 4200 is not in operative communication with electronicIS l records on the one or more servers 4214.

Timing m 4300 includes acts 4302 to 4354. During act 4302, a userupdates a prescription in an application ("app") in a computer or a monitoring client,e.g., a tablet. Act 4304, the updated prescription is communicated to one or moreservers in an EMR. Act 4306 checks the prescription in DERS to ineif it issafe for any patient or the particular patient,e.g., using predetermined criteria. Act4308 communicates the safety information from the DERS system to theapplication on the monitoring client or computer application. Act 4310 receives thesafety information. Act 4312 communicates the prescription from the tablet orcomputer ation to an API of a hub, via an EMR application programminginterface ("API”) of the hub in act 4314. The APImay include a secure data class.

Act 4316 communicates the prescription to the pump in act 4318, whichin turn,icates the prescription to the pump in act 4320. Act 4322 requests userconfirmation of the prescription on thepump user ace, e.g., via a touchscreen.

After confirmation, the confirmation is communicated to the pump in act 4324.which is received in act 4326. During act 4326. therapy is started, and statusation is communicated via act 4328 to thepump status Ul, which is yedto the user in act 4330.

Also, status information is icated in acts 4332 and 4334. In act4326, status information is received by the hub which broadcasts the status viaWiFi in act 4338. The tablet application receives the status information during act4340 from a communication of the status during act 4342. During act 4346, statusinformation is interfaced via an EMR API, which is communicated to an tablet orinformation iscomputer app via act 4348, which is received in act 4350. The statuscommunicated in act 4352 to the EMR database, which updates the EMR databaseIn some embodiments communication between the EMR and the in act 4354.

Allscripts Tablet/Computer App or the Hub is through middleware (e.g., middlewareon the monitoring server 3 of Fig. 1).

Figs. SBA-688 show a flow chart diagram of a method 4335 illustrating theof thetiming diagram of Fig. 67 in accordance with an embodiment presentsure. Method 4335 includes acts 4301-4333.

Act 4301 s a prescription for a patient in an application. Act 4303queries, from the application, electronic medical records on a server to determinethe safety of the updated iption for the t. Act 4305 communicates theIS determined safety of the d prescription for the t from the server toapplication. Act 4307 communicates the updated prescription from the applicationto an API of a hub. The API may include a secure data class. In someembodiments, the communication of Act 4307 occurs through middleware (e.g.,middleware on the monitoring server 3 of Fig. 1). Act 4309 determines the safety,within the hub, of the updated prescription (e.g., in some embodiments DERSchecks andlor prescription checks). In some embodiments, Acts 4309 is optional.

In some embodiments, Act 4311 icates the updated prescription fromhub to the pump. Act 4311 is optional in some embodiments.

Act 4313 ys a confirmation request of the updated iption on auser interface of the pump. Act 4315 confirms the updated prescription on the userinterface of the pump. Act 4317 pumps fluid in accordance with the updatedprescription. Act 4319 displays a parameter on the user ace of the pump.4321 communicates the parameter from the pump to the hub. Act 4323 wirelesslybroadcasts the parameter from the hub. Act 4325 communicates the parameterfrom the hub to a monitoring client, e.g.. a tablet. Act 4327 displays the parameteron a user interface of the monitoring client. Act 4329 communicates the parameterandlor the updated iption from the hub to the application using an API ofhub. Act 4331 communicates the parameter and/or the updated prescription fromthe application to the server. Act 4333 updates the ter andlor the updatedprescription within the electronic l s in the server. In someembodiments, Act 4333 communicates through middleware (e.g., middleware onthe monitoring server 3 of Fig. 1).

Fig. 69 shows an electronic patient-care system 4400 and Fig. 70 showselectronic patient-care system 4500. In some embodiments, an electronic medicalrecords application may reside on a tablet 4402 as shown in Fig. 69 and/or in abedside computer 4502 of Fig. 70. Additionally or alternatively, in someembodiments, the electronic medical records applicationmay reside in a hub, aninfusion pump, a tablet, a patient-care device, some other device or apparatus,l0 some combination thereof, or may not be utilized. The scanner 4404 may be usedto ine if the medication, e.g., an infusion bag, matches the prescriptionprescribed for an identified patient, e.g., the patient may be identified using thescanner 4404.

Fig. 71 shows a timing m 4600 illustrating, in accordance with some[5 embodiments of the present disclosures, a method in which an infusion pump4408A andior a hub 4406 requests from the tablet 4402 whichprescription wasprescribed for a patient by querying an onic medical records applicationed on the tablet 4402. A user may enter the patient’s identification or thepatient’s identification is scanned using the scanner 4404. The electronic medicalrecords application ed on the tablet 4402 may request the prescribedmedication from the one or more servers 4410. A tablet application may requestthe user to choose from a list of available prescriptions if there are multipleiptions, e.g., multiple infusion-pump-based prescriptions.

The timing diagram 4600 illustrates acts 4602-4652.

Act 4602 requests,using a monitoring client during act 4604, a list of prescription for a patient afteridentifying the patient. Act 4602 “pulls” the prescription information from themonitoring client. The patient may be identified using a barcodescanner, an RFIDinterrogator, voice- or facial-recognition, or via manual entry. The tabletcommunicates the patient's ID during act 4606 using an EMR APIto a tablet orcomputer application of 4608. The API may include a secure data class. Thepatient's identity is communicated in act 4610 to an EMR database, which in act4612, communicates the list of iption to an EMR API during act4614, whichis receiVed by the EMRprogram running on the ring client or erin act 4616, which in turn communicates them in act 4618 to the monitoring clientapplication. The communication between the EMR Tablet/Computer Applicationand the EMR database may be via middleware (e.g., middleware on the monitoringsewer 3 of Fig. 1).

The monitoring client, e.g., a , in act 4620, can y the variousprescriptions for the patient for user selection. The selected prescription iscommunicated in act 4622 to the hub, which can check the iption in act 4624and communicate the prescription to the pump in act 4626. The pump tes,either tically by ensuring the prescription is within predetermined criteria,e.g., using DERS, in act 4628, or by requesting user validation. Additionally or[0 alternatively, a user can validate the prescription using the pump UI.

The validated prescription of act 4628 is communicated in act 4630 to thehub, which in act 4632 communicates in act 4634 it to the monitoring clientapplication. In act 4636, a user can accept the prescription, which is thencommunicated in act 4638 to the hub. The accepted prescription's communicationsIS occurs in act 4640 communicates it via act 4642 to the pump.

In act 4644, theUl in act 4646, in which the userpump communicates the iption to the pumpcan confirm the prescription in act 4642. The confirmation is sent to the pump inact 4650. Act 4652 runs the therapy.

Figs. 72A-72B show a flow chart diagram of a method 4653 illustrating thetiming diagram of Fig. 71 in accordance with an embodiment of the presentdisclosure. Method 4653 includes acts 4655-4691.

Act 4655 determines an identity of a patient using a monitoring-clientapplication in a monitoring client, e.g., a tablet. Act 4657 communicates the identityof the patient from the monitoring-client application to an API. Act 4659 queries,from the API, electronic l records on a server to determine at least oneprescription for the patient. In some embodiments, the Act 4659 queries throughmiddleware (e.g., middleware on the monitoring server 3 of Fig. 1) to the electronicmedical s. Act 4661 communicates the determined at least one prescriptionfor the patient from the server to the API. Act 4663 communicates the determinedat least one prescription for the patient from the API to the monitoring-clientapplication in the monitoring client. Act 4665, optionally, displays on a user displayof the monitoring client a user selectable list of the at least one iption. Act4667, optionally, selects a prescription of the at least one prescription using thedisplay on the ring client. Act 4669 communicates the selected prescriptionand/or the at least one prescription from the ring client to thehub.

Act 4671 communicates the selected prescription and/or the at least oneprescription from the hub to the pump. Act 4673 validates the selected prescriptionand/or the at least one prescription. Act 4675 communicates the selectedprescription and/or the at least one prescription from the pump to the hub. Act4677 communicates the selected prescription and/or theat least one prescriptionfrom the hub to the monitoring-client application of themonitoring client. Act 4679ys a confirmation request of the validated prescription on the user interface ofll) the monitoring . Act 4681 confirms the ted prescription on the userinterface of the monitoring client. Act 4683 communicates the validatedprescription from the monitoring-client application of the monitoring client to thehub. Act 4685 communicates the validated prescription fromthe hub to the pump.

Act 4687 displays a ation request of the validatediption on a userinterface of the pump. Act 4689 confirms the validated prescription on the userinterface of the pump. Act 4691 pumps fluid in accordance with the validatedprescription.

Fig. 73 shows a timing diagram 4700 in which a iption is pushed to theinfusion pump 4408A. Additionally or alternatively, the electronic medical recordsapplication also can be located on the device hub 4406 which maintain theelectronic medical records application programming interface across ledevices. Method 4700 includes acts 4702-4726. Middleware (e.g., middleware onthe monitoring server 3 of Fig. 1) may be utilized, in some embodiments, betweenthe EMR databases and the EMR tablet/computer application.

In act 4702, a user updates a prescription in an EMR application on amonitoring client, e.g., a tablet or a computer. The update may be a newprescription of a modified prescription. The updated prescription is communicatedto the application in act 4704. The application ses the update in act 4706,and commutes it in act 4719 to the EMR database. In act 4708, DERS checks theupdated prescription. The updated prescription is communicated, in act 4710, tothe EMR ring client or er application, whichis processed in act 4712.

After processing, in act 4714. the updated prescription is communicated via anEMR API to a monitoring client application, which is processedin act 4721. Themonitoring client communicates it, in act 4716, to the pump. The pump processesthe updated prescription in act 4718 and communicates it to the pump in act 4720.

A user confirms the updated prescription in act 4722. which is communicated to thepump in act 4724. The therapy is applied in act 4726.

Fig. 74 shows a flow chart diagram of a method 4701 rating the timingdiagram of Fig. 73 in accordance with an embodiment of the present disclosure.

Method 4701 includes acts 4703-4717.

Act 4703 updates a prescription for a patient in an application. Act 4705queries, from the application, electronic medical records on a server to determinethe safety of the updated prescription for the t. Act 4707 communicates theIO ined safety of the updated prescription for the t from the server to theapplication. Act 4709 communicates the updated prescription from the ationto an API of a monitoring . Act 4711 communicates the Updated prescriptionfrom the monitoring client to the pump. Act 4713 displays a confirmation request ofthe updated prescription on a user interface of the pump. Act 4715 confirms the[5 d prescription on the user interface of the pump. Act 4717 pumps fluid inaccordance with the updated prescription.

Fig. 75 shows a timing diagram 4800 in which the hub 4406 communicatesto the infusion pump 4408A for user confirmation of the prescription. That is, themethod 4800 of Fig. 75 is similar to method 4700 of Fig. 73; however, the hubincludes the EMR API and processes it in act 4802.

Fig. 76 shows a flow chart diagram of a method 4801 illustrating the timingdiagram of Fig. 75 is ance with an embodiment of the present disclosure.

Method 4801 includes acts 4803-4817.

Act 4803 s a prescription for a patient in an application. Act 4805queries. from the application, electronic medical records on a server to determinethe safety of the updated prescription for the patient. Act 4807 communicates thedetermined safety of the updated prescription for the patient from the server to theapplication. Act 4809 communicates the updated prescription from the applicationto an API of a hub. Act 4811 icates the updated prescription from the hubto the pump. Act 4813 displays a confirmation request of the updated prescriptionon a user interface of the pump. Act 4815 confirms the d prescription on theuser interface of the pump. Act 4817 pumps fluid in accordance with the updatedprescription.

Figs. 77 and 78 show embodiments in which the hub 4406 communicateswith the one or more servers 4410,e.g., to determine if the prescription is safe forthe t, etc.

Fig. 79 shows a timing m 5100 for user confirmation of the prescriptionon the pump's 4408A user interface. The timing diagram 5100 implements amethod that includes acts 5102-5130. Act 5102 requests prescriptions from anEMR using a monitoring client’s app, which is communicated in act 5104 andprocessed by act 5106. The request 5102 may be made via patient identification.

The tablet communicates the request in act 5108 via an EMR API to the EMRIO se. Act 5110 processes the request and communicates back via theAPI in act 5112. The monitoring client processes the prescriptions received fromthe EMR database in act 5114.

The monitoring client communicates the prescriptions in act 5116 to thepump, which validates the prescription in act 5118 and communicates it in act 5120[5 to the monitoring client's application. The user can accept the prescription in act5122, which is communicated to the pump and the pump's Ul in act 5124. In act5126, a user can confirm the prescription on the pump. The confirmation iscommunicated to the pump in act 5128, which then is executed in acct 5130.

Figs. BOA-80B show a flow chart m of a method 5101 illustrating thetiming diagram of Fig. 79 in accordance with an embodiment of the presentdisclosure. Method 5105 includes acts 15128.

Act 5103 determines an identity of a patient using a monitoring-clientapplication in a monitoring client, e.g., a tablet. Act 5105 queries, from an API,electronic medical records on a server to determine at leastone prescription for thepatient. Act 5107 communicates the determined at least one prescription for thepatient from the server to the monitoring-client application. Act 5109, optionally.displays on a user display of the monitoring client a user selectable list of the atleast one prescription. Act 5111, optionally. selects a prescription of the at leastone prescription using the diSplay on the monitoring client. Act 5113 communicatesthe selected iption and/or the at least one prescription from the ringclient to the pump. Act 5115 validates the ed prescription and/or the at leastone prescription. Act 511? communicates the ted prescription from thepumpto the ring client. Act 5119 ys a confirmation request of the validatedprescription on the user interface of the monitoring client.

Act 5121 confirms the validated prescription on the user interface of themonitoring . Act 5123 communicates the ted prescription from themonitoring client to the pump. Act 5125 ys a confirmation request of thevalidated prescription on the User interface of the pump. Act 5127 confirms thevalidated prescription on the user interface of the pump. Act 5129 pumps fluid inaccordance with the validated prescription.

Fig. 81 shows a timing diagram 5200 in which the hub 4406 communicateswith the one or more servers 4410 to communicate with electronic medical records.

The method implemented by the timing diagram 5200 es acts 5202-5238.

Middleware (e.g., middleware on the monitoring server 3 of Fig. 1) may be utilized,in some embodiments. n the EMR databases and the EMR lcomputerapplication.

In act 5202, a user requests prescription from an EMR via a monitoring clientin act 5204 and processed by act 5206. Theapplication, which is communicatedmonitoring client application interfaces with the EMR API of the hub in act 5208,which is processed by act 5210. The EMR API requests in act 5212 theprescriptions, which is processed in act 5214.

The iptions are communicated in act 5216 to the hub, which processesthem in act 5218 and communicates them in act 5220 to the monitoring client'sapplication for processing in act 5222. The iptions are communicated in actin act5224 to the pump for validation in act 5226. The validation is communicated5228 for user acceptance in act 5230, which is communicated to the pumpin act5232. The user can confirm the prescription in act 5234, which is communicated inact 5236 for starting the therapy in the pump in act 5238.

Figs. 82A-828 show a flow chart diagram of a method 5201 illustrating thetiming diagram of Fig. 81 in accordance with an embodiment of the presentdisclosure. Method 5201 includes acts 5203-5233.

Act 5203 ines an identity of a patient using a monitoring-clientapplication in a monitoring client, e.g.. a tablet. Act 5205 communicates the identityAct 5207of a patient from the monitoring-client application to an API on the hub.leastqueries. from the API, electronic medical records on a server to determine atone prescription for the patient. Acts 5205 and/or 5207 may e middleware(e.g., middleware on the monitoring server 3 of Fig. 1). Act 5209 icates thedetermined at least one prescription for the patient from the server to the API of thehub. Act 5211 communicates the determined at leastone prescription from the APIof the hub to the monitoring-client ation. Act 5213, optionally, displays on auser display of the monitoring client a user able list of the at least oneprescription. Act 5215, ally, selects a prescription of the at least oneiption using the display on the monitoring client. Act 521? communicates theselected prescription and/or the at least one prescription fromthe ring clientto the pump. Act 5219 validates the selected prescription and/or theat least oneprescription. Act 5221 communicates the ted prescription fromthe pump tothe monitoring client. Act 5223 displays a confirmation request of the validatedprescription on the user interface of the monitoring client.

Act 5225 confirms the validated prescription on the user interface of themonitoring client. Act 522? communicates the validated iption from themonitoring client to the pump. Act 5229 displays a confirmation request of thevalidated prescription on the user interface of the pump. Act 5231confirms thevalidated prescription on the user interface of thepump. Act 5233 pump fluids inaccordance with the validated prescription.

Fig. 83-89 show several additional embodiments of an onic patient-care system in accordance with l embodiments of thepresent disclosure.

Fig. 83 shows a system 5300 where an electronic medical records applicationaces with electronic medical records on one ormore servers 3516 to displaysome of the patient’s electronic medical recordson a user ace of a tablet 3514and/or the hub 3804. A subset of the data from the electronicmedical recordsreceived from the one or more servers 3516may be displayed on a display on aninfusion pump 3504 (e.g., the medication being delivered by the infusion pump3504). onally or alternatively, in some embodiments, a subset of data fromthe electronic medical recordsmay be cached on the hub. In some embodiments,the hub may communicate with the medical ITsystems through middleware (e.g.,middleware on the monitoring server 3 of Fig. 1).

Fig. 84 show a system 5400 where an electronic medical sapplication interfaces with electronic medical records on one or moreservers 4410to display some of the patient's electronic medical recordson a user interface of abedside computer 4204 and/or the hub 4406. A subset of thedata from theelectronic medical records received from the one or more servers 4410may bedisplayed on a display on an infusion pump 4408A (e.g., the medication beingdelivered by the on pump 4408A). Additionally or alternatively, in someembodiments, a subset of data from the electronic medical records may be cachedon the hub and/or the bedside computer. In some embodiments. the hub mayicate with the medical IT systems through middleware (e.g., middleware onthe monitoring server 3 of Fig. 1).

Fig. 85 shows a system 5500, which may be an independent system or issystem 5400 of Fig. 84 when the communication with the one or more servers 4410is interrupted. Fig. 86 shows a system 5600, which may be an independentsystem or is system 5400 of Fig. 84 when the communication with the one or morei0 servers 4410 is interrupted. In Figs. 85-86, the prescription may can to beprogrammed into the systems 5500, 5600 without access to an onic medicalrecords server of the one or more servers 4410. The prescription may be adjustedon the tablet 4402, the e computer 4502, or the infusion pump 4408A. Thehub 5804 may communicate with the scanner, the bedside er 4502, and/ori5 the infusion pumps 4408A—44080 wirelessly and/or via a wired connection. Insome specific ments, the monitoring client 4402, the hub, and/or thebedside computer can be programmed without EMR data, but may be compared tolocal version of Guardrails.

Referring to the drawings, Fig. 87 shows a system 5700 for electronicallytreating a patient. The hub 5702 communicates with the one or more servers 5704using a networking API or a local API to a resident electronic medical recordsapplication that handles the ication to the one or more servers. The pumps5706A-57060 are used to program and run the treatment. The hub 5702 maycommunicate with the r andfor the medical IT systems 5704 wirelesslyand/or via a wired connection.

Fig. 88 shows a system 5800 not having a tablet, or a bedside computer.

System 5800 may be system 5700 of Fig. 87 when communication to the one ormore s 5704 is unavailable 5704. The infusion pump 5802A is programmedusing the user interface on the pump 5802A, and a cached set of predeterminedsafety criteria (e.g., Guardrails) exists in either the hub 5804 or in the pumps5802A-58020. The predetermined safety criteria may be based upon the drugdelivered, the patient, allergies. or stored drug contraindications and may preventunsafe treatment settings from being delivered to the patient. The hub 5804 maycommunicate with the scanner and/or the infusionpumps 5802A, 58023, andior5802C wirelessly and/or via a wired connection.

Fig. 89 shows a system 5900 with several infusion pumps. System 5900may be system 5800 of Fig. 88 when communication with the hub is unavailable.

The infusion pumps 5902A-59020 may be directly controlled using eachrespective user interface on the pump, and a set of predetermined criteria (e.g.,DERS) may be cached therein to ensure the medication is not delivered outsidepredetermined criteria; in some ments, no DERS is cached within theinfusion pumps 5902A—5902C, andr‘or permanent DERS data is stared internallywithin non-volatile memory.

Fig. 90 shows a block m of circuitry 6000 of a hub disclosed herein.onally or alternatively. the circuitry 6000 may be used within a dock, acommunication module, or a pump disclosed elsewhere herein. The circuitry 6000may interface into a bus or hub to communicate with several devices via the device'15 module interface and/or to providepower thereto. Circuitry 6000 includes a firstfailsafe line 6002 that may be activated by a deviceprocessor subsystem 6004,and a second failsafe line 6006 that may be activated by an aceprocessorsubsystem 6008. The first and second failsafe lines 6002, 6006, are fed into an ORgate 6010, which has an output for an output failsafe line 6012. If ether the devices subsystem 6004 or the interface processor subsystem 6008 detects a faultor error, the first or second fe lines 6002, 6006can activate the output feline 6012. The failsafe line 6012 may be coupled to appropriate circuitry andlors in se to the output failsafe line 6012,e.g., an automatic occludingdevice that can automatically prevent fluid flow through an intravenous line when itreceives a signal from the output failsafe line 6012. In some embodiments, apatient-care device coupled to the device module interface may request one ormore voltages from the regulated power supplies, which eachmay be a buck. aboost. or a buck-boost power supply.

Fig. 91 is a block diagram of circuitry 6100 for interfacing withan infusionpump. Additionally or alternatively, the circuitry 6100 may be in a dock or hubdisclosed herein that connects to a pump andlor the circuitry 6100 may be anable module attachable to an infusionpump, e.g., a ications module.

The circuitry 6100 may interface into a bus or hub to communicate with severaldevices via the device module interface andior to epower thereto. In someembodiments, the ace processor subsystem may communicate with devicecoupled to a device hub interface using a wireless link and/or near-fieldcommunications.

Fig. 92 shows a block diagram of an electronic patient-care system 6200 thatincludes a tablet dock 6202, infusion pumps 6204A-6204D, a dock 6206 forreceiving the infusion pumps 6204D, and a tablet 6208. In alternativeembodiments. the tablet 6208 is integrated into the tablet dock 6202. In additionalembodiments. the docks 6202 and 6206 are integrated together. In yet additionalalternative embodiments, the dock 6202, the dock 6206, and the tablet 6208 areintegrated together. The tablet 6208 provides the primary user interface using adisplay 62010. The dock 6202 includes a memory for caching or storing a userinterface template or a user interface program for displaying a user ace on thedisplay 6210 for a patient-care device, e.g., infusion pumps 6204A-6204D. Thetablet 6208 may be used to order a iption or verify a prescription using one ori5 more servers 6212 having a drug error ion system, e.g., using the scanner6214. In some embodiments, there may be middleware (e.g.. middleware on themonitoring server 3 of Fig. 1) between the medical IT system 6212 and the dock6206. The user interface template or a user ace program is configured todisplay on the display 6210 aggregate data from the infusion pumps 6204D,and acts as a backup alarm if one or more of the infusion pumps 6204A—6204Dfails. Additionally or alternative, the dock 6206 alarms if one or more of the infusionpumps 6204A—6204D fails using an internal speaker and/or an internal vibrationmotor.

The dock 6206 may aggregate data from the infusion pumps 6204A-6204Dand pass the aggregated data to the tablet 6208. Each of the infusion pumps6204A—6204D includes a respective display 6216A—6216D. The displays 6216A-6216D can be used for adjusting flow rates during infusion (predetermined safetycriteria may be loaded while programming a prescription through the tablet 6208).

An on can be d without the drug error reduction 's predeterminedsafety criteria by adjusting the flow rate from zero on a user interface yed onthe displays 6216A—6216D. The displays 6216A-6216D may also displays alertsand alarms both visually and with auditory indication.

The dock 6206 includes a power entry module. medical grade powersupplies, and a backup battery. The dock 6206 also contains all of thecommunications hardware to ace to the tablet 6208 and to the medical ITsystems, i.e.. the one or more servers 6212. The dock 6206 may include hardwarefor traveling, such as a pole. and pole mounting re.

During mming of a prescription, the personalized drug error reductionsystem setting, e.g., predetermined safety ia, is received directly from the oneor more servers 6212. The tablet 6208 may be used to facilitate entering in apatient's ID and medication. Communication between the tablet 6208 and the oneor more sewer 6212 may occur through the dock 6206. The predetermined safetycriteria from the l drug error reduction system is cached on the dock 6206 orin one or more of the infusion pumps 6204A—6204D. In case the drug errorreduction system is unavailable from the one or more s 6212, the locallycached predetermined safety criteria from the drug error ion system isupdated through the network (e.g., WiFi) when it is available again.

The dock 6206 has enough battery to support 8 hours of operation ofhub dock 6206 and of the infusion pumps 6114A—6114D. The tablet6110may ormay not have its own battery. In some embodiments, the infusion pumps 6204A-6204D may have enough battery (or other backup power) tosupport saving datawhen being pulled out of the dock 6206 and for alarming. This alarming capabilityand separate y may also be moved to the dock 6206.

The pump's Ul display on a display of the displays 6216A-6216Dmay besmall. For example, in some embodiments. the displays 6216A-6216Dmay be justlarge enough so that only flow rate may be adjusted. This will allow an infusion tobe started without entering in any other information. Since the t's ID and/ordrug name may be entered before accessing the EMR, there is d data from adrug error reduction system or guardrails from the one or more servers 6212 ifinfusion is started without the tablet 6208. If the infusion is programmed with thetablet and then later the tablet is removed from the system thepump can continueto implement the guardrails feature related to the current prescription.

Fig. 93 shows a block diagram of circuitry 6300 for the hub 6206 of Fig. 92.or for a communications module 124A—124K of Figs. 1, 3. 5. 7, 8, or 9. onallyor alternatively, the circuitry 6300 may be used in a pump or a dock describedherein. The circuitry 6300 may interface into a bus or hub to communicate withseveral devices via the device module interface and/or to providepower thereto. Atablet (not shown) coupled to a tablet UI interface 6302may have its own powersupply (not explicitly shown). In some embodiments of the present disclosure, thecircuitry 6300 can supply power to a tablet.

Fig. 94 shows a block diagram of circuitry 6400 for the hub 6206 of Fig. 92.or for a communications module 124A-124K of Figs. 1, 3, 5, 7, 8, or 9.

Additionally or alternatively, the try 6400 may be used in a dock or a pumpdescribed herein. The circuitry 6400 may ace into a bus or hub tocommunicate with several devices via the disposable interface and/or to providepower thereto. In some embodiments of the present disclosure. the try 6300can supply power to a tablet.i0 Fig. 95 shows a system 6500 having an extended battery 6502. an onpump 6504, and a wall wart 6506. System 6500 may operate without a drug errorion system from a server. A display 6508 on the infusion pump 6504 may beused to enter in drug information and control the infusion rate. In someembodiments, drug error ion system data is cached in memory of the infusionpump 6504 and updated through docking.

Fig. 96 shows a system 6600 having an infusion pump 6504 coupled to adevice hub 6602. The infusion pump has 6504 has an ability to initiate delivery.

Emergency modes with limited generic Drug Errdr Reduction System based on asubset of drugs easily picked from a list may be cached on the device hub 6602and/or the infusion pump 6504. The infusion pump 6504 may be started withoutdata from a drug error reduction system.

Fig. 97 shows a system 6700 having a tablet 6702 allowing access to theon pump 6504 through the tablet's 6702 interface. The tablet's 6702 userinterface may reside in the device hub 6602. DERS may reside on the tablet6702, on the device hub, and/or on the infusion pump 6504. A wall wart 6506 cansupply power to the tablet 6702, the device hub 6602, and/or the infusion pump6504.

The device hub 6602 may have a physical or wireless connection to thetablet 6702. The device hub 6602 may include a cradle (not shown) for the tablet6702. The tablet 6702 could optionally be rigidly attached to the device hub 6602.

Referring to the drawings, Fig. 98 shows a system 6800 having a dock 6804(which may be a cradle in some embodiments), pump s 6802A-6802C, adevice hub 6602, and tablet 6702 plug into a ane of the dock 6804 (or insome embodiments, cradle). In addition. a power module 6804 includes powerentry and extra battery that may be plugged into or is integrated into the dock 6806.

The device hub 6602 is the master for communication between all other sas well as IT systems via one or more servers (not shown). Although the infusionpumps 6802A—68020 are removable in the embodiment shown in Fig. 98, othercomponents may be modular or integrated together in other embodiments.

The infusion pumps 3802A-38026 generally contain pumping mechanismsand electronics that can run a pumping mechanism. In one specific embodiment,the device hub 6602 includes backup power for one or more infusion pumps3802A-3802C. a processor for aggregating data and hosting the tablet’s 6702 Uli0 model (e.g.. a nterface template) and modular communications hardwareThe tablet 6702 may include a creen 6808. The wall wart 6506es AC-to-DC conversion, and is coupled to the power module 6804 whichcontains all the power entry module and an ACIDC power supply. The wall wart6506 is optional and/or an AC-to-DC converted may be incorporated into the poweri5 module 6804. The power module 6804 may also include an extended battery torun multiple pump modules. The dock 6806 includes a back plane connectinger the various components.

Fig. 99 shows electronic circuitry 6900 of a device hub. e.g., device hub6602 of Fig. 96. in ance with one embodiment of the present disclosure.onaily or alternatively, the circuitry 6900 may be used in a pump, a dock or acommunication module described herein. The circuitry 6900 may interface into abus or hub to communicate with several devices via the device patient—careinterface 6916 and/or to provide power thereto. Circuitry 6900 includes variouspower sources, a user interface, communications, sensors. and ors. t6900 includes AC mains 6902, DC power 6904, wireless power 6906, e.g..inductive, and an external battery connection 6908.

The AC mains 6902 may be a direct connection to mains, such as throughan AC outlet. The AC mains 6902 are coupled to a power entry and chargingcircuit 6910 which can rectify and convert the AC signal from the AC mains 6902 toa DC signal. The DC signal from the power entry AC/DC universal supply 6910 isfed into the DC power entry and charging circuit 6912.

The DC power 6904 receives DC power from a DC power . such asthe wall wart 6506 of Fig. 95 or from a backplane or another al battery (notitly shown).

The wireless power 6906 may receive energy ssly. For example, thewireless power 6906 may include a coil that receives a time-varying magnetic fieldsuch that a voltage across the coil is induced; the induced AC signal is ied andsmoothed via a smoothing circuit and coupled to the DC power entrylchargingcircuit 6910.

The circuitry 6900 also includes a primary y 6914, an external battery6908, and a secondary battery 6920. The primary battery 6914 is used to supplypower to one or more patient-care devices d to the patient-care deviceinterface 6916 and a tablet (not shown) coupled to a tablet interface 6918. Theinterface 6916 may connect to none, one, or a plurality of patient-care devicesthrough one or more ications technologies. The tablet interface 6918 maycouple directly to a tablet or is coupled to a user interface of a tablet. The externalbattery connection 6908 may be ical connectors (not explicitly shown) that areadapted for electrical coupling with one or more battery cells located in a separatei5 housing of the electronic circuitry 6900. The external battery 6908 may supplementthe primary y 6914 or e the primary battery 6914 in the event theprimary battery 6914 fails. The secondary battery 6920 may be a super-capacitor6920. In some embodiments, the secondary battery 6920 may be used only infailure modes where power is otherwise unavailable, e.g., the AC mains 6902 failsand the al battery 6908 is removed or fails. The secondary battery 6920supplies sufficient power for a device processor subsystem 6922 to alarm via asecondary buzzer 6824.

The circuitry es various power supplies, such as hub regulated powersupplies 6926, a gated ndent supply from regulated device power supplies6928, and a tablet regulated power supply 6930.

The hub regulated power supplies 6926 is used to for powering the electricand sensors of the circuitry 6900. For e, the hub regulated power supplies6926 are used to provide a voltage for an interface processor subsystem 6932.

The regulated device power supplies 6928 may be gated and may provideone or more independent and regulated voltage supplies that are sent to one ormore patient-care devices coupled to the t-care device interface 6916. Theone or more regulated device power supplies 6928 that are sent to one or morepatient-care devices via the patient-care device ace 6916 are monitored by acurrent sense 6934 and are enabled by the device processor subsystem 6922.

Additionally or alternatively, the regulated device power supplies 6928 may beprogrammable such that a patient-care device requests a voltage from devicesor subsystem 6922, which is turn, programs the regulated device powersupplies 6928 to supply the requested voltage to the patient-care device.

The tablet regulated power supply 6930 supplies DC power to a tabletcoupled to the tablet interface 6918. Additionally or alternatively. the circuitry 6900passes an AC signal from the through AC mains 6902 for use by an internal powersupply of the tablet (not shown in Fig. 99).

The circuitry 6900 also includes a user interface 6936 ing a batteryindicator 6938, status indicators lights 6940, and a LCD touchscreen 6942. Thebattery indicator 6938 shows the charge state and battery state of the primarybattery 6914. The status indicator lights 6940 show the status of the hub, tablet.and any patient-care devices d to the t-care device interface 6916.

The status indicator lights 6940 may e one or more lights, e.g., LEDs, forI5 each patient-care device coupled to the patient-care device interface 6916. Forexample, the status indicator lights 6940 may include a LED to show an alarm stateand another LED to show a run state.

In some embodiments of the present disclosure. the LCD touchscreen 6942may be the main display and input method for patient-care devices coupled to thepatient-care device interface 6916 which don't have displays. Additionally oralternatively, the LCD touchscreen 6942 displays verbose ation about thehub. the hub's try 6900, andfor patient-care devices coupled to the patient-care device interface 6916. In on, the LCD touchscreen 6942 may beconfigured to passively output status information to a large display. such as anexternal TV screen.

The primary speaker 6944 may be used to e voice guidance forpatient-care s coupled to the patient-care device interface 6916 that do nothave displays or alarms when a tablet is not connected to the tablet interface 6918and/or is otherwise not available. The secondary buzzer 6924 is a backup buzzerand provides safety in conditions in which the primary speaker 6944 is unavailableor broken and/or the interface sor subsystem 6932 is unavailableor broken.

In some embodiments of the present disclosures, hardware buttons 6946may be used for additional safety input to stop or provide input into a patient—caredevice that does not have its own display and there is no tablet available.

The tablet ace 6918 is coupled to the interface 6932 such that theinterface processor subsystem 6932 can communicate with a tablet d to thetablet interface 6918. The tablet interface 6918 is coupled to a USB interface 6947and a Bluetooth interface 6948 (the Bluetooth interface 6948 may be a BluetoothLow energy ace.

The patient-care device interface 6916 provides interfaces to a patient-caredevice including a serial interface 6949, which may be a SPI, l2C, R3232, RS485,or any other serial protocol. The patient-care device interface 6916 also provides aCAN interface 6950, a USB interface 6951, 3 Ethernet interface 6952, a WiFi Radiointerface 6953, and a Bluetooth interface 6954.

The patient-care device interface 6916 may e a Wired Device ID 6955that facilitates patient-care device discovery of type, serial number, class, orperformance teristics of the patient-care device and its location in amultichannel cradle, dock, andlor hub. The wired device ID 6955 may be used todetermine an optimal or preferred communications protocol based uponpredetermined criteria. Additionally or alternatively, a ng method may bechosen as a function of the wired device ID 6955 based upon predeterminedcriteria. The wire device ID 6955 may be determined by communicating with apatient-care device attached to the patient-care device interface 6916 using a “onewire" device. Additionally or alternatively, the patient-care device interface 6916also includes a wireless device ID 6958 that facilitate patient-care device discoverywhich may utilize a RIFD interrogator, near field communications, or other sscommunications link to facilitate patient-care device discovery of the type, serialnumber, class, or performance characteristics of the patient-care device and itslocation in a multichannel cradle, dock, andlor hub.

The patient-care device interface 6916 also includes a l IIO interface6956. The digital l/O interface 6956 may include le lines per patient-caredevice coupled to the patient-care device interface 6916 that may be used fortriggering actuators, enabling pins as part of a safety system, or for be used forstatus lights on a hub or cradle.

The patient-care device es also es failsafe lines 6957. Either ofthe interface processor subsystem 6932 or the device process subsystem 6922 cantrigger one of the failsafe lines 6957 which are fed into a logical OR 6977. Theoutput of the logical OR 6977 can be coupled to a electromechanical occludingdevice (not shown) coupled to the patient-care device interface 6916. In alternativeembodiments, a logical AND is used in place of the logical OR 6977 such that bothof the interface processor subsystem 6932 or the deviceprocess subsystem 6922must agree, in this specific embodiment, (i.e., both provide a logical true) prior to”true" signal being sent to the patient-care device ace 6916as a failsafe line.

The circuitry 6900 includes several communications links to IT systems orone or s 6967. The circuitry 6900 includes a WiFi interface 6960, a 3G/4Ginterface 6961, and an et hub or switch interface 6956. The 3G/4G interface6961 facilitates operation of the hub having the circuit 6900 within a homeenvironment. The 3GI4G interface 6961 may beany cellular logy or long-range communications transceiver, 9.9., Code division multiple access (“CDMA”),Time-division multiplexing (“TDM”), WiMax, Evolution-Data Optimized (”EVDO"),Orthogonal frequency-division multiplexing (“OFDM”), Space-Division MultipleAccess ”), Time-Division Duplex (”TDD"), Time division multiple access(”TDMA"), Frequency-division duplexing (”FDD”), or the like.

The circuitry 6900 includes a barcode reader or camera 6962, whichmay beused for patient Identification, clinician identification, and/or solution/drugidentification (e.g., by reading a 2-D barcode using the camera).

The circuit 6900 may also include a transceiver 6963 for RFID, NFC,or othercommunication protocol for patient identification, clinician fication, andlorsolution/drug identification or to determine the on of a patient-care device.

The circuitry 6900 can also e a communications expansion slot 6964so that future wired or wireless technologies may be modularily ed into theslot 6964. The slot 6964 may include one or more expansion connectors and isinternal to the case of the hub is externally connectable thereto. Additionally oralternatively, the expansion slot 6964 may be a connection for an additionalmodules having a plurality of functions, 9.9., wireless communications functions,wired connections, and the like.

The circuitry 6900 may also include hub sensors 6965, such as atemperature sensor, a pressure sensor, a humidity sensor, and an accelerometer.

The circuitry 6900 may also include a ion motor 6966 for e ck,8.9., when alarming or prompting a user for selection via a GUI on the tabletcoupled to the tablet interface 6918.

Fig. 100 shows a block diagram of circuitry 7000 which shows oneembodiment of features that may be used for a patient-care device such as apump. That is, the device module interface may interface with an infusion pump 7of Fig. 1, for example. Additionally or alternatively, in some embodiments, thecircuitry 7000 may be on a hub, a communication module, a dock, or an infusionpump described herein. The circuitry 7000 may interface into a bus or hub tocommunicate with several devices via the device module interface and/or to epower o. try 7000 also includes various safety s. This circuitry7000 supplies a method of battery backed-up power and ications to thetablet and IT systems. The circuitry 7000 receives power from an external wall wart(not shown) power supply for the hub and for the tablet. In some embodiments,the device hub processor subsystem includes an Ethernet connection to the ITsystems. In some embodiments, the device hub processor subsystemcommunicates with the monitoring client interface using Ethernet, WiFi, Bluetooth,Bluetooth Low Energy, near-field communications, etc.

Fig. 101 shows a block diagram of circuitry 7100. The circuitry 7100 may beon a hub. And, the device module interface may interface with an infusion pump 7of Fig. 1, for example. Additionally or alternatively, in some ments, thecircuitry 7100 may be on a hub, a communication module, a dock, or an infusionpump described herein. The circuitry 7100 may interface into a bus or hub tocommunicate with several s via the device module interface and/or to providepower thereto. Circuitry 7100 includes a WiFi t 7102 and an Ethernettion 7104 for communication with an IT system (e.g., as described )for flexibility in ance with one embodiment of the present disclosure. Thespeaker 7106 may also be useful for enunciating problems with the hub or droppedconnections to the IT system. The tablet regulated power supply is may facilitatethe use of only one al power supply. In some embodiments, the device hubprocessor subsystem communicates via the monitoring client interface usingBluetooth, wifi, Bluetooth low energy, near-filed communications, etc. In someembodiments, the device hub processor subsystem communications with thepatient-care device interface using Bluetooth, Bluetooth low energy, USB, near-fieldcommunications, etc. Fig. 102 shows a battery only version, i.e., an extendedbattery as previously described. That is, the circuitry 7200 of Fig. 102 may be theextended battery 6502 of Fig. 95 and may make the system 6500 wearable, forexample. The extended batteries 6502 of Fig. 95 may be stackable together (e.g.,the circuitry 7200 includes a transceiver, such as SPl or CAN) such that multipleextended batteries 6502 of Fig. 95 may be stacked together topower the infusionpump 6504. The circuitry 7200 may interface into a bus or hub to providepower toseveral devices (e.g., patient-care devices) via the device module ace.

Fig. 103 shows a block diagram of circuitry 7300 for controlling multipleinfusion pumps with flexibility for expansion. For example, the device moduleinterface may ace into multiple infusion pumps, one infusion pumps, or noinfusion pumps. Additionally or atively, in some embodiments, the circuitry7300 may be used in a dock, an infusion pump, a communication module, and/or ahub as described herein. The try 7300 may interface into a bus or hub toicate with several devices via the device module interface and/or to providepower thereto. In some embodiments, the monitoring-client interface may utilizeBluetooth, Bluetooth low energy, or other communication technology. In someembodiments, the device module interface (i.e., patient-care device interface) maybe coupled to a patient-care device via Bluetooth, Bluetooth low energy, WiFi,and/or near-field communications. As can be seen with this example, CANcommunication may be used as the wired protocol to communicate with the infusionpumps. Some digital are IOS ed to add some onality to the pump cradle. ifnecessary. The power entry and the ACIDC supply 7302 is inside the hub (i.e.,inside of the circuitry 7300), and it supplies power to the tablet, hub, and one ormore infusion pumps. The infusion pumps coupled to circuitry 7300 may be “stand-alone” safe. An RFID reader 7304 and the barcode reader/camera 7306 areincluded to authenticate a patient, or provider. The com expansion slot 7308 ised to expand the ication functionality when other methods aredeveloped (e.g., peanut for authentication and location).

Fig. 104 shows circuitry 7400 for a hub described herein with a failsafe line7402 and two processors 7404, 7406. Additionally or alternatively, in someembodiments, the circuitry 7400 may be used in a dock, an on pump, and/or acommunication module as described herein. The circuitry 7400 may interface intoa bus or hub to communicate with several devices (e.g., patient-care s) viathe device module interface and/or to provide power thereto. The processor 7406may be a safety processor. The fe line 7402 may be activated by either of thetwo processors 7404, 7406. In some embodiments, the WiFi Radio may be anEthernet interface. In some embodiments, the CAN interface may be a Bluetooth.

Bluetooth low energy, WiFi, or other communications logy.

Additional safety is provided by the failsafe line 7402. For example. a pulseoximeter r can clamp a line if the pulse rate goes up or is too high. That is.the failsafe line output may be coupled to an omechanical occluder. The hubcircuitry 7400 could act as a watchdog and even monitor the output for rangechecking and send failsafe signals down to trigger the clamp if the process in thepulse oximeter is in error or is in a fault condition. The communication with a tabletmay be wireless via the tablet Ul interface 7408. The circuitry 7400 may bewirelessly charged via wireless power 7410. A vibration motor may be added togive hepatic feedback when there is an alarm. The circuitry 7400 optionally includestwo processors 7404, 7406 that implement a method for warning the user when analarm or alert is issued. A secondary battery or super cap 7412 may ebackup power when there is power failure. The circuit 7400 may be a pumpmodule, e.g., a communications module, and/or a hub to attach to a .

Fig. 105 shows a system 7500 for electronic patient care according to yet anadditional embodiment of the present disclosure. System 7500 includes amonitoring client, more particularly, a stackable monitoring client 7502. andstackable t-care devices, e.g., stackable infusion pumps 7504A-7504D. Thestackable monitoring client 7502 includes a display 7505 that is pivots along a pivot7508. The display 7506 may be a touchscreen. The stackable monitoring client7502 may e a tilt , e.g., an accelerometer. to orient the display 7506such that it is always viewable to a user. Likewise, each of the stackable infusionpumps 7504A-7504D may include a respective display 7510A—7510D thatorientates itself based upon the its tilt, e.g., the display may show letters in anupright position regardless whether the stackable infusion pumps 7504A-7504D arepositioned in a horizontal ation or a vertical orientation. Additionally oralternatively. each of the ble infusion pumps 7504A—7504D may include a tiltsensor, e.g., an accelerometer.

The displays 7510D may be touchscreen. Each display or thedisplays 7510A—751OD may e one or more buttons that orientates itself basedupon the tilt as indicated by an internal tilt. For example, as shown in Fig. 105, abutton 7512 is shown as being in an t position relative to the elongated lengthof the stackable infusion pump 7504A. Referring to Fig. 105. the system 7500 isshown tilted such that the button 7512 is shows as being in an upright positionrelative to the length of the stackable infusion pump 7504A. Also note that thedisplay 7507 is further pivoted along the pivot 7508. Fig. 107 shows the display7506 pivoted against the monitoring client 7502. Fig. 108 shows the intravenousholes 7807A—7807D. Fig. 109 illustrates additional range of pivoting along the pivot7408. Fig. 110 shows the infusion pump 7504B slidable into the stack.

Figs. 111-112 show an additional embodiment of a stackable electronicpatient care system 8100 in which the stackable infusion pumps 8102A—8102D areconnected together through respective top (e.g.. connector 81004) and bottomconnectors (not explicitly shown) such that the stackable infusionpumps 8102A-8102D are daisy d er. Fig. 111 shows one configuration of the system8100. Fig. 112 illustrates that the infusion pump 810020 is detachable from thesystem 8100. The infusion pump 81020 may include its own internal battery tocontinue ion. e.g., the infusion pump 8102B may have sufficient ypower to continue to pump infusion fluid into a patient for a ermined amountof time.

Fig. 113 rates that a monitoring client 8106 may include connectors toreceive the infusion pump 8102B. The monitoring client 8106 may have anable/detachable display 8110. Fig. 114 illustrates that another moniton'ngclient 8108 may be stacked onto the stackable infusion pump 8102B. Themonitoring clients 8106, 8108 may coordinate their operation. For example, themonitoring s 8106, 8108 may coordinate the supply of power to the infusionpumps such that both of the batteries of the infusion pumps 8106. 8106 supplypower to the system 8000.

Fig. 115 shows the connections 8402-8420 enabling stackable infusionpumps 8422, 8424 and a monitoring client 8426 to be coupled together in a daisychain configuration. Fig. 116 shows slideable connections 8502, 8504. 8506, 8508such that the stackable on pumps 8422, 8424 and a monitoring client 8426are daisy chained together. The slideable connections 8502, 8504, 8506, 8508may include electrical tor enabling the ble infusion pumps 8422. 8424and a monitoring client 8426 to communicate with each other.

Fig. 117 shows a system 8600 of a stackable monitoring client 8602 with astackable infusion pump 8604 that connect together via a backplane panels 8606,8608. The backplane panel 8606 includes a connector 8610 that matenglyengages a connector 8612 of a backplane panel 8608. Additional backplanepanels (not shown) may be added to example the ane in accordance with thenumber of monitoring clients, 8602 or infusion pumps 8604 added thereto. Fig. 118shows a cross-sectional view of the backplane panel 8608 of Fig. 117.

Fig. 119 shows a system 8800 that includes a monitoring client, moreparticularly, a stackable ring client 8806, and stackable patient-care devices,e.g.. a stackable infusion pump 8802. The stackable infusion pump 8802 slidesinto a dock 8804 in a direction "A.“Fig. 120 shows a system 8900 where a stackable infusion pump 8902Bion "B."engages a dock 8904 via a connector 8509 when moved inFig. 121 shows a communication module 9000 in accordance with anembodiment of the present disclosure. Communications modules 9000 includeconnectors 9002, a LED status ring 9004, a RF antenna 9004, a snap-on connector9006, a wireless charging coil 9008, a battery ng and safety processor 9010,wireless communications and sensor processor 9012, and a battery 9014. Thecommunications module 9000 of Fig. 121 may be a communications module 124A-124K of Figs. 1, 3, 5, 7, or 8. Fig. 122 shows the communications module 9000coupled to a patient-care device 9100. Fig. 123 shows a diagram of electronictry 9200 of the communications module 9000 of Fig. 121 in accordance withan embodiment of the present disclosure.

Fig. 124 shows onic circuitry 9300 for allowing a near field ogator(e.g., one operating at about 13.56 MHz) to read a 900MHz UHF RFID tag. Theelectronic circuitry 9300 includes a dyne transfer oscillator. The circuit 93000translates near field ogation signals to RFID interrogation signals. Theelectronic try 9300 may be used by the communications module 9000 of Fig.90 and/or a communications module 124A-124K of Figs. 1. 3, 5, 7, or 8 for enablinga near field communications circuit to interrogate an RFID tag. Each of theantennas may be replaced by an RF circuit to allow the circuit to be used on aninterrogator or a receiver. Additionally or alternatively, in other embodiments, theelectronic circuitry may be arranged such that the UHF RFID interrogator is used tocommunicate with a near field communications device.

Figs. 125-127 show several antennas in accordance with additionalembodiments of the present disclosure. Figs. 125 and 126 show two split-ringresonators 12500, 12600 that may be used with a scanner, e.g., placed in from ofan RFID or near field ogator and/or antenna (for sending or receiving). Theresonators 12500, 12600 are made using .028 thick FR-4 single-sided board with .5oz copper. Trimming may be used to tune the resonators ( as shown).

Fig. 127 shows a near field antenna 12700 for a UHF reader (e.g., a915MHz RFID reader), which focuses the near field pattern with a reader chip.

Without a power amplifier, approximately 1.5 inches of readrange is achieved. Theantenna 12700 is made from a .028 thick FR-4, with acopper backing. Antenna12700 may be used with a 10pF shunt matching element.

Fig. 128 shows a patient wristband 12800 with an RFID tag 12802 attachedo in accordance with an embodiment of the present disclosure. Becausecapacitance is observed when an RFID tag 12802 is attached to a wristband of apatient, a split-ring resonator (”SRR”) 12804 may be used such that it is .01 inchesaway from the patient. The dielectric loading from the capacitance of the patientknocks off the frequency of the RFID tag 12802; therefore, the SRR 12804 helpstune the RFID tag 12802 by coupling the RFID tag 12802 more closely to theantenna. The SRR 12804'5 resonant frequency should be slightly above theoperating frequency of the RFID tag 12802. Fig. 129 shows a close-up view of thesplit-ring resonator 12804 for use on the wristband of Fig. 128.

The RFID tag 12802 of the patient’s wristband 12800may be writable. Ahub, dock, patient-care device, andfor ring client may write data related to apatient into the RFID tag 12802, including: (1) treatment history such as flow rates,drug settings, vital signs, etc., (2) usage statistics (patient-care parameters, patient-treatment ters, patient-care device ing parameters. diagnosticinformation from docks, hubs and monitoring clients, and the like); (3)a intravenouspump flow ter, an ECG parameter, a blood pressure parameter, a pulseer parameter, a C02 capometer parameter. an intravenous bagparameter,and a drip-flow meter value; (4) patient ter includes at leastone of treatmentprogress of an infusion pump, an electrocardiographic signal. a blood pressuresignal, a pulse oximeter signal, a C02 capnometer signal, and a temperature; (5) patient-treatment parameters, such as infusion settings including anon rate or on pressure. and receive from it various operating parameters,such for e, the presence of air in the infusion line, the amount of solutionremaining in an IV bag to which it is connected, or the re of fluid in theinfusion line. In some embodiments, the RFID tag 12802 includes only apredetermined amount of passed time (Le, a rolling history) in its memory, e.g., 6hours or 14 hours of history on a 32 Kilobyte or 56 te memory of the RFID tag12802, in some specific embodiments. In yet onal embodiments. the RFIDtag 12802 may include a patient ID andfor a Near-Field communications receiver toreceive the data.

Fig. 130 shows a split-ring tor 13000 in accordance with anembodiment of the present disclosure. The high Q, split-ring resonator 13000includes a tor 13002, which acts in the place of an air gap. The SRR 13000may be placed approximately 8 inches away from a 13.56 MHZ NFC loop antennato e the loop a by as much as 10 dB. The SRR 13000 may bedesigned to operate at 13.8 MHZ to reduce group-delay tion to the 13.56 MHZdigitally modulated signal. Fig. 131 shows an equivalent circuit 13100 for the SRR13000 of Fig. 130 in accordance with an embodiment of the present disclosure.

Fig. 132 shows a 5 R’s checklist that may be displayed on any displaydisclosed herein. Fig. 133 shows an occlusion checklist that may be disclosed onany display disclosed herein. Fig. 134 shows a display in operative communicationwith l infusion pumps, e.g., a monitoring client 1 or 11 of Figs. 1. 3, 5, 7, 8, orFig. 135 is an illustration of a display on a health care provider's lering client, g a list of patients whose information the provider canaccess in accordance with an embodiment of the present disclosure;Fig. 136 is an illustration of a display on a health care provider's portablemonitoring client. showing devices associated with a particular patient, with currentdata from the devices and one-touch access to some of the patient's medicalinformation in accordance with an ment of the present disclosure. Fig. 137is an illustration of a display on a health care provider's portable ring client,g data entry fields for a prescription for a medication for use with anintravenous infusion pump in accordance with an embodiment of the presentdisclosure. Fig. 138 is an illustration of a display on a health care provider'sportable monitoring client. showing a risk profile associated with an orderedmedication, and a suggested course of action, as generated by the Monitoring inaccordance with an embodiment of the present disclosure. Fig. 139 is anillustration of a display on a health care provider's portable monitoring client,showing a medication prescription ready for submission by the ordering provider in1 59accordance with an ment of the present disclosure. Fig. 140 is anillustration of a display on a health care provider’s portable monitoring client,showing how the Monitoring system can display confirmation to the orderingprovider that the prescription has been transmitted to the pharmacist in accordancewith an embodiment of the present disclosure.

Example of Monitoring-assisted order entryThe functionality of the Patient Monitoring system can be illustrated byexample in which an ordering provider enters a new medication prescription for apatient. In this scenario, the physician may view his list of ed patients on hisIO hand-held device after entering the appropriate security pass code. In thisexample, the physician’s patients can be listed as shown in Fig. 97, with limited anduser-selectable information 26 on each patient, such as, for example, age.diagnosis, and medical record number. Alert symbols 27 may be itted by themonitoring client 1 to the physician’s device 11 if, for example, orders for the patient2 are incomplete, the nurse has flagged the patient for attention.or if the monitoringclient 1 has received input from a database or a patient monitoring device 14-17that has exceeded a predetermined threshold for physician notification.

After the physician selects a patient for further review, a display suchas thatshown in Fig. 135 may be transmitted to the physician's device 11. The physiciancan view user-selectable data originating from monitors 14-17 to which the patientis connected, and the physician may have uch access to a number ofses 19-21, 23 containing patient-specific information. In an embodiment, themonitoring client 1 may be connected or docked to an on pump 7 available foruse with the patient 2. In a scenario illustrated in Fig. 136, the physician canpresson the icon enting the infusion pump 3’ to order an enous medication forthe patient 2.

Fig. 137 shows one of a number of possible prescription ng screenswith which a physician can remotely order a medication. In the example rated,the physician enters the drug IV Nitroglycerin 28, whichmay be entered by typingor via a own y populated by the hospital pharmacy’s formulary 22,accessed by the monitoring client 1 via the Monitoring Server 3. The 'PDR' button29 may represent the physician’s one-touch access to an in-hospital 22 orproprietary drug se 9 for detailed drug information. The physician can orderthe dose of medication, either ly or by accepting a default standard startingdose 30 provided by the monitoring client 1 via the monitoring server 3. Thephysician may also specify the maximum fluid infusion rate 31 for the infusion pump7, in order to assist the pharmacist in preparing the proper tration of thedrug in a bag for infusion.

Fig. 138 shows an example of how the Patient Monitoring system can detecta risk of an adverse reaction after the ian has entered the prescription. Themonitoring client 1 can compare the new tion 28 to the patient's existingmedications and drug allergy list aded from the EHR 19. The monitoringserver 3 preferably will have populated the appropriate patient-specific data into thering client 1, and the client 1 will be programmed to look up this informationafter the new medication order has been d. The monitoring client 1 may beprogrammed to request a listing of significant adverse reactions and druginteractions associated with each of the patient’s medications and the newmedication 28 from the monitoring server 3. The server 3, in turn can access acy se 22 or external database 9 for this information. If a potentialdrug interaction or adverse reaction common to an existing medication and the newtion 28 are detected, the monitoring client 1 may issue a warning 32 andtransmit it to the ordering physician, as shown in Fig. 138. If the potential adversereaction is due to an effect common to both the new medication and an existingmedication, the monitoring client 1 may categorize this as a potentially veadverse effect and issue a recommendation 33 to reduce the initial drug dose, forexample, by 50%.

As shown in Fig. 139, the ordering physician has the option either to acceptthe recommendation 33 or edit the recommended dose to another value. In anyevent, the monitoring client 1 may generate and log a report 34 of the warning 32and any corrective action 33, if any, taken by the physician, with the option for thephysician to further edit the report before logging and entry into the patient's EHROnce the medication dosing is finally determined, the monitoring client 1 canfonNard the order to the communication devices of both the hospital pharmacist 6and the patient's nurse 5. A report of the accomplishment of this task may then betransmitted back to the ordering ian 11, as shown in Fig. 140. Thepharmacist can use the information provided by the ordering physician to mix anappropriate concentration of the tion in a solution bag. Both the medicationvial and the on bag may have identification tags, such as, e.g., bar codeidentifiers, that can be read into the pharmacist’s monitoring client 6, and which canbe verified as correct by the monitoring client 1 (using the pharmacy database 22as ed by the monitoring server 3). The pharmacist may then generate aunique identification label, such as a bar code label, to be ently affixed tothe medication bag, the code now being linked uniquely to the patient 2 for whomthe medication 28 has been prepared. The identifying code on the label may betransmitted to the monitoring client 1 for later reconciliation when the nurse is aboutto administer the medication 28.

After the prepared medication 28 arrives to the patient’s floor, the nurse canthen prepare to administer it to the patient 2. in this exemplary scenario, themonitoring client 1 may include an input device such as a bar code reader, whichthe nurse can use to verify that the identifying code on the medication bag matchesthe identity of the patient 2 for whom it has been prescribed. If the identificationmatches the information entered into the monitoring client 1 by the cist, thenurse may be d by the device 1 to hang the medication bag and initiate theinfusion via the infusion pump 7. In an embodiment, the ring client 1displays to the nurse the prescription, including the dose, the maximum fluid rate forthe patient, the concentration of the drug in the bag, and the infusion rate for thepump (which can optionally be calculated by a processor in the monitoring client 1.

With this information, the nurse has the ability to ly calculate and verify thatthe on rate set by the monitoring client 1 for the pump 7 is correct.

Fig. 141 shows an apparatus 14100 formed by a microinfusion pump 14104d to an adapter 14102 in accordance with an embodiment of the presentdisclosure. The adapter 14102 includes a touchscreen 14106 that can be used tocontrol the operation of the microinfusion pump 14104. The microinfusion pump14104 pumps fluid out of a tube 14108.

The adapter 14102 may wirelessly communicate with a monitoring client 1 ofFigs. 3, 5, 7, 8, a monitoring client 902 of Fig. 9, a dock 102 or 104 of Fig. 1, a dock102 or 104 of Fig. 3, a dock 502 of Fig. 5, a hub 802 of Fig. 8, a dock 804, 806 or102 of Fig. 8, the dongle 133 of Figs. 1, 3, 5 or 7, or any patient-care devicedisclosed herein.

The adapter 14102 may include various electrical connectors such that themicroinfusion pump 14104 may be docked to the adapter 4102. The adapter14102 may include an electrical connector on a backside to ace with a patient-care device dock 104. For example, the adapter 14102 may include a connectorsuch that the adapter 14102 docks to theThe touchscreen 4106 may be used to set an infusion rate, a bolus amount,or an extended bolus setting, etc. Additionally or atively, the touchscreen4106 may be used to estimate the amount of liquid medication left within themicroinfusion pump 14104.

Fig. 142 shows a perspective-view of a wireless hub device 14200 thatwirelessly relays data from a patient-care device to a monitoring client, another hub,or a dock in accordance with an embodiment of the present disclosure.

The ss hub device 14200 includes a body 1402 coupled to atouchscreen 14204 and a holder 14206. The wirelessly hub device 1420 maycommunicate data from another patient-care device to a t-care device to amonitoring client, another hub, a dock, etc. For example, the wireless hub device- 14200 may communicate data with a patient-care device according to a firstwireless protocol and relay the information via another wireless protocol toring client, another hub, a dock, etc. For e, the wirelessly hub device14200 may communicate with a patient-care device via Bluetooth and relays thedata to a dock (e.g., dock 104 of Fig. 1) via ield communications; In thisspecific embodiment, the holder 14206 may be shaped such that the holder 14206may rest in a dock, e.g., the dock 104 of Fig. 1.

Fig. 143 shows a front, perspective-view of an electronic patient-care system14300 having modular t-care devices 14304, 14306, 14308, and 14310coupled a monitoring client 1430 via an adapter 14316 and a dock 14314 inaccordance with an embodiment of the present disclosure. The dock 14314 iscoupled to a pole 14312. The adapter 14316 provides an electrical connectionn the dock 14314 and the patient care devices 14304. 14306, 14308, and14310. That is, the adapter 14316 may be changed based upon the type ofpatient-care devices 14304, 14306, 14308, and 14310 used.

Fig. 144 shows a side, perspective-view of the electronic patient-care systemof Fig. 143 in accordance with an embodiment of the t disclosure. Referringto Figs. 143-144, the patient-care device 14306 slides onto the adapter 14316 viarails 14318 and 14320. The infusion pump 14304 may snap onto a spring-loadedflange 14322. A lever on the backside of the adapter 14316 may be pulled to pullaway the flange from the infusion pump 14304.

Fig. 145 shows a close-up, perspective view of the interface of one of thepatient-care devices shown in Fig. 143 in accordance with an embodiment of thepresent disclosure. Referring now to the Figs. 144 and 145, the rail 14318 engagewith the track 14502, and the rail 14320 s with the rail 14504. A space14506 receives the flange 14322 such that the infusion pump 14304 snaps intoplace in the adapter 14316.

Fig. 146 shows a top view of the electronic patient-care system 14300 of Fig.143 in ance with an embodiment of the present sure. The dock 14314is coupled to two adapters 14602 and 14316. The dock 14314 is coupled to thepole 14312 via a clamp 14606. The pump 14304 is shown with the pump door14604 opened.

Fig. 147 shows an illustration of a system 14700 for electronic patient-care inaccordance with an embodiment of the t sure. The system 14700includes a central server 14702, a central server client 14703, a hospital server14704, one or more medical IT systems 14705, dockslhubs 14707, 14708 and14709, and a hospital server client 14706.

The central server 14702 may be an enterprise-level sewer, a hospital-levelserver, or a global server (e.g., a cloud server). The central server 14702 mayprovide software updates, firmware updates, andlor configuration files. Forexample, the central server 14702 may provide updates for the hospital server14704, the docks/hubs 14707, 14708 and 14709, patient-care devices d tothe docks/hubs 14707, 14708 and 14709, or monitoring clients in operativecommunication with the docksfhubs 14707, 14708 and 14709 basedupon a deviceID. Additionally or alternatively, the central server 14702may provide software fordownload into a sandbox as described below (see Fig. 148). Additionally oralternatively, the central server 14702 can receive usage tics (patient-careparameters, patient-treatment parameters, patient-care device operatingparameters, diagnostic information from docks, hubs and ring clients, andthe like). The central server 14702 may log the data in a database,e.g., an SQLdatabase, an associative database, or the like.

The central server client 14703 can communicate with the central server14702 to monitor the ion of the central server 14702, view the log filestherein, or to view data relating to the efficacy of a drug as described above. Insome ments of the present disclosure, the central server client 1403 issoftware at a nurse's station such that the nurse can r dockslhubs, patients,andlor patient-care devices.

The hospital server 14704 may be installed in a hospital, a care unit of ahospital (e.g., Neonatal Intensive Care Unit ('NICU"), Intensive Care Unit (“ICU"),etc.). a floor of a hospital, or for a group of als (e.g., an strative groupof hospitals).

The hospital server 14704: (1) may include a custom set of DERS, may trackpatient-care devices, Docks/Hubs or monitoring clients; (2) may identify and logmpliant patient-care devices, dockslhubs and/or monitoring clients; and/or(3) may configure or update docksfhubs, monitoring clients and/or patient-caredevices (e.g., from updated software files, configuration files or firmware files fromthe central server .

The one or more medical IT s 14705 communicate with the hospitalserver 14704 to provide functionally thereto. The medical IT system 14705 mayprovide computerized provider order entry ”), a drug library, electronicl records (“EMR”), a computerized maintenance management system(”CMMS”), or other database or computerized system.

The docks/hubs 14707, 14708, and 14709 icate with the hospitalserver 14704. There may be one or more of the dockslhubs 14707, 14708, and14709 in a patient’s room.

The hospital server client 14706 allows a user or technical to interface withthe hospital server 14704 to facilitate the updating of software. to monitor the logfiles therein, or to help facilitate continuous quality improvement (”CQI").

Fig. 148 shows a block diagram of an electronic patient-care system 14802in accordance with an embodiment of the present sure. The system 14802includes an enterprise server system 14804, an ation store 14806, a devicemanager 14808, one or more hubs 1426, one or more tablets 14810, one or moreinfusion pumps 14814, and one or more wireless sensors 14816. Thecommunications between the tablet and the dock/hub 14812. between thedocklhub 14816 and the wireless sensor 14816, between the dock/hub 14812 andthe infusion pump 14814, between the dock/hub 14812 and the device manager14808, between the device manager 14808 and the application store 14806, andlorbetween the device manager 14840 and the enterprise server(s) 14804may bemade by using WiFi, Ethernet, Bluetooth, USB, 3G, 4G, HALO, SOAP, XML data,using escribing data, HL7, TCPIIP, Bluetooth templates, a ted, and/oror dicated communications link.

The enterprise server system 14804 may include, in some embodiments, aCMMS database 14832, a CPOE 14834, an EMR 14836, and/or a billing server14838. The enterprise server system 14804 may receive equipment healthinformation ing calibration data, battery life, etc. with the CMMS 14832.

The application store 14806 may include one or more device applications (orprograms) 14850, 14851, 14852 andi’or 14853, which may control or program oneor more patient-care devices, one or more sensors, one or more infusion pumps14814, provide patient diagnostic functions, etc. The application store 14806 mayprovide encrypted ications to facilitate the downloading of one or more ofthe device applications 14850-14853.

The device r 14808 may be a hospital-level server that providesglobal DERS 14840 and local policies 14842. The local policies 14842 may includeadditional hard or soft limits (e.g., on drugs) based upon, for example, the locationof the particular dock/hub 14812 in the hospital (e.g., the ER, NICU, ICU, etc.).

The dockfhub 14812 may be coupled to one or more wired or sssensors 14816, one or more infusion pumps 14814, and/or may be ted toother patient-care devices. The dock/hub 14812 may communicate with the onemore wireless s 14816 using WiFi, Ethernet, Bluetooth, Bluetooth LowEnergy, USB, 3G, 4G, HL7, TCPIlP, Bluetooth templates, or other protocol via adedicated or non-dedicated communications link and may be using self-describingdata. The wireless sensor may use one of the communication modules describedabove (e.g., the wireless sensor 14914 may be coupled to a communicationmodule via a serial link such as SPl). The tablet 14810 may interface into thedock/hub 14812. The dock/hub 14812 may include a local copy of DERS 14826that may be periodically updated by the DERS 14840 from the devicemanager14808. Additionally or alternatively, the docklhub may include a local copy of thelocal policies 14828 that may be ically updated by the device manager14808.

The tablet 14810 may provide care flow sheets that provide the caregiverpatient with a checklist of activities for their day and may record and log data fromweight scales, vital monitors, data on bathing, dressing s, dietaryinformation from patient-care devices or may be manually entered into the tablet14810, which can be updated and stored in the patient's EMR file within the EMR14836. The tablet 14810 may provide tutorials to the home patient or caregiver toserve as a reminder for specific care operations such as how and when to changedressings, measure urine output, or take blood glucose readings. Additionally oralternatively, the tablet 14810 may instruct a ver, patient, or user how toresolve a source of a soft alarm andfor hard alarm.

A patient-care , e.g., the on pump 14814, may include eldcommunications (“NFC") which communicates with the dock/hub 14812 when theinfusion pump 14814 is in close proximity with the dock/hub 14812 to, for e,pair the devices, to pass configuration data, or set the infusion pump 14814parameters for the patient with which the dock/hub 14812 is associated with. Afterthe NFC communications, the infusion pump 14814 may communicate with theub 14812 wirelessly or via a wireless link. For example, an infusion pump14814 may be in close (or contacting) proximity with the dock/hub 14812 in whichNFC ications are used to pair the infusion pump 14814 with the ub14812 using a Bluetooth communications link.

The dock/hub 14812 may execute a device application 14820-14824 with asandbox 14814. The sandbox 14814 may require the application to be written withermined criteria. In some embodiments. the sandbox 14814 may include anAPI having a secure data class. In yet additional embodiments, the sandbox14814 may reside on the monitoring client 14810. The sandbox 14814 may be avirtual machine, may be a m that controls the resources (e.g., hardware orsoftware resources available via an API, for example) the device applications14820-14824 may utilize, may have global variables accessible by the deviceapplications 14820-14824, and may be interpreter based. That is, the sandbox14812 is a protected area that allows the device applications 14820-14824 toexecute in a controlled and limited ce environment. The sandbox 14812 maybe downloaded from the device manager 14808 or the application store 14806.

The sandbox 14812 may be preconfigured for the particular dock/hub type, e.g.,based upon any single or combination of a version number, a serial number, a lotnumber, a hardware version number, a software version number, an ingsystem type, an operating system service pack, other identifier, etc.

For example, the dock/hub may identify the infusion pump 14814 by serialnumber and download from the app store a device application 14850 into thedock/hub 14812 (e.g., the device app 14820). The device apps 14820-14824 maycontrol and/or communicate with the infusion pump 14814 to relay ationabout the infusion pump 14814 to the tablet 14810 for display (e.g., via XML, fore). Additionally or alternatively, the one or more of the device apps 14820-14824 can diSplay data from devices, use complex tics to combine data fromseveral sources, etc. The sandbox 14818 may also control the access to variousresources, such as: memory, non-volatile memory, hard , network interfaces,input devices, output devices, a buzzer, etc. in some embodiments, the sandbox14818 may limit or prohibit the device applications 14820-14824 from readingand/or writing to specific files, such as system files The sandbox 14818 mayprovide temporary and/or protected resources to the device applications 14820-14824, such as: a “scratchpad” memory space and/or a scratchpad harddisk space.

Any attempts by the device app 14820 to violate the DERS 14828, the localpolicies 14828, or inhibit the dock/hub 14828 to perform its primary functions (e.g.,designated, high-priority functions) will be prevented by other re running onthe dock/hub 14812 (e.g., an operating system such as the android operatingsystem, IOs, Linux, s, or Windows CE that controls the execution of thesandbox via one or more process l blocks or one or more threads from athread pool).

The sandbox 14818 may control the launching of one or more of the deviceapps 14820-14824. For e, the x 14818 may check rules or links(e.g., dynamically linked library calls) to ensure that a device app of the device apps14820-14824 designated for execution does not have any broken links andconforms to predetermined criteria controlled by the x 14818. For example,the sandbox 14818 may check that all of the references from a device application14850 to shared ies within the docklhub’s 14812 software exist within specific"safe” shared ies, the particular function or variable within the library exists.and the variable and data type requested by the device applications 14824or communicated by the device applications 14820-14824 conforms to or existswithin the library.

In some embodiments of the present disclosure, the sandbox 14818prioritizes access to resources. For example, if multiple device applications 14820-14824 request access to an alarm device (e.g., a speaker) or variable that indicatesan alarm condition, the sandbox 14812 may prioritize the sources of the requestsand display the prioritized list of alarm causes on the tablet 14810 allowing acaregiver to e certain alarm conditions, address multiple alarm sources andlorassess the ion of the patient.

In some embodiments of the present disclosure, the dock/hub 14812includes a processor with two cores such that one of the cores executes thesandbox 14818 whilst another core executes an operating system which controlsthe allocation of the resources used by the sandbox 14818 via one of the deviceapplications 14820-14824.

In some embodiments of the present disclosure, the dockihub 14812es two processors such that one of the processors executes the sandbox14818 whilst another processor executes an operating system which controls theallocation of resources used by the sandbox 14818 via one of the deviceapplications 14820-14824.

In some embodiments of the present disclosure. the docklhub 14812includes two processors such that one of the processors executes the sandbox14818 whilst r processor executes a watchdog function to ensure safeoperation of resources used by the x 14818 via one of the deviceapplications 14820-14824.

In some embodiments of the present disclosure, the dock/hub 14812includes two processors such that one of the processors executes a real-timesafety processor whilst r processor executes the sandbox 14818 and anoperating system which controls the tion of resources used by the sandbox14818 via one of the device applications 14820-14824.

In some embodiments of the present disclosure, the ub 14812includes one or more processors each with one or more cores such that at leastone process control block es the sandbox 14818 whilst at least anotherprocess control block es an operating system which controls the allocationsof ces used by the sandbox 14818 via one of the device applications 14820-14824.

The dock/hub 14812 may de-identify data from the patient-care devices andupload the data to the database 14830 (e.g., a cloud-based database); the datamay be real-time data aggregated at the national level to facilitate epidemicdetection, resource planning, and deployment planning within a hospital or hospitalsystem.

Fig. 149 shows a block diagram 14900 of a beside portion of the electronicpatient system of Fig. 147 andlor Fig. 148 in accordance with an embodiment of thepresent disclosure. The diagram 14900 es a monitoring client 14902 (whichmay be the tablet 148120), a monitoring-client adapter 14904 such that themonitoring client 14902 can interface with the dock/hub 14906 (which may be thedock/hub 14812), and several on pumps 14910. The dock/hub 14906 maycommunicate with the infusion pumps 14910 via WiFi, Zigbee, Bluetooth, a meshnetwork, a point-to-point protocol (e.g., based upon WiFi), etc. The infusion pumps14910 may be power directly via the AC outlet 14908 (not depicted) and/or from thedock/hub 14906 directly. The ub 14906 is coupled to the wireless s14814 (wirelessly or wired) and to USB sensors 14912 via a USB cable.

In some embodiments of the present disclosure. another in-room displaymay be present, e.g., a hub, monitoring , computer. etc. that can icatewith the dockfhub 14812 and/or tablet 14810 via WiFi, Ethernet, Bluetooth, USB, orother ol via a dedicated or dicated communications link.

Fig. 150 shows a block diagram of the ub 15000 of Figs. 14?, 148,andIor 149 in accordance with an embodiment of the present disclosure. Thedock/hub 15000 includes a primary processor 15003 and a safety sor 15002(which one or both may be a processor, a microprocessor, or a microcontroller, forexample a Snapdragon processor).

The safety processor 15002 is coupled to a speaker driver 15011 whichcontrols a backup speaker 15012. The safety processor 15002 is also coupled to a2X CAN bus connected to a t-care device via the device connector 15014. insome embodiments, the device connector 15014 communicates with a patient-caredevice via a , Bluetooth, WiFi, CAN Bus, or SPI communications link.

The safety processor 15002 is coupled to a voltage regulator 15010 whichreceives power from a backup battery 1501? and/or from a battery charger 15009.

The safety processor 15002 is coupled to an enable switch 15016 that can disablethe power supply to a patient-care device coupled to the device connector 15014.

The current limiter 15015 can also limit the current to a patient-care device coupledto the device connector 15014.

The safety processor 15002 is also coupled to an enable 15020 switchwhich enables/disables a 5 volt power supply to the patient-care device coupled viathe device connector 15014. The 5V signal to the t-care device is receivedfrom the voltage regulator 15010 which receives its power from a primary batterycell 15018 and/or the battery charger 15009. The battery charger receives powervia an AC/DC converter 15008 d to an AC outlet 15007.

The primary processor 15003 is coupled to a camera 15024. a WiFitransceiver 15025, a Bluetooth 15026 transceiver, an RFID interrogator 15027,LED status lights 15029, buttons 15028, and a near-field communicationstransceiver 15030.

The primary processor 15003 is coupled to a USB cable that couples to aUSB port 15023 and/or a monitoring client via a Ul tor 15022. In somements. the primary processor 15003 can icate with a tablet via aWiFi or other wireless communications link. The primary processor 15003 canIS communicate with a patient-care device via the USB connection 15023 and/or themonitoring client via a USB port via the UI connector 15022. The primaryprocessor 15003 communicates a signal to a speaker driver 15006 which drives aprimary speaker .

Fig. 151 is a block diagram illustrating the infusion pump circuitry 15100 ofFigs. 148 and/or 149 in accordance with an ment of the present disclosure.

The circuitry 151 includes a Ullsafety processor 15102 that controls the pumpdisplay 15104 and logs data in non-volatile memory 15105. The Ullsafetyprocessor 15102 communicates with a hubfdock via a CAN bus coupled to thedevice connector 15108. In some embodiments the ime processor 151102and/or Ullsafety processor 15102 communicates with a hubIdock via the deviceconnector 15108 using a Bluetooth. a wireless. or a wired communications link.

The UllSafety processor 15102 may include an image processing library toprocesses imagery from a camera. Additionally or alternatively, the UIISafetyprocessor 15102 may include a library to display a GUI interface on the pumpdisplay 15104 (which may be a touchscreen).

The ety processor 15102 is coupled to an occlude-in-place sensor1516. a latch sensor 15117. an air-in-line sensor 1518. a motor hall sensors 15119,s 15120, and status lights 15112. The safety processor 15102 provideswatchdog functionality to the real-time processor 15103 (which may be a processor.a microprocessor, or a microcontroller. for example a SnapDragon processor) andcan enable the motor drive 1510?.

The ime processor 15103 (which one or both may be a sor. arocessor, or a microcontroller, for example a SnapDragon processor)controls the operation of the pump's motor 15106 via the motor drive 1510?. Thereal-time processor 15103 communicates with the UllSafety processor 15102 (e.g.,to e pump settings) via a serial ace. The real-time processor 15103loads pump calibration data from a non-volatile memory 15122. The non-volatilememory 15122 and/or the non-volatile memory 15105 may be an SD card and/oran RFID tag.

The real-time processor 15103 receives data about the infusion pump fromthe motor t sensor 15109, the motor housing temperature 15110. theocclusion pressure sensor 15111. the cam shaft position sensor 15112. the camfollower position sensors 1513. and/or accelerometer 15114.

In Figs. 151 and 152, the two processors may be used to confirminstructionis), to perform safety checks, or other functionality (e.g., userconfirmation of a patient-treatment parameter) in an identical and/or similar manneras disclosed in US. Patent Application Serial No. 12/249,600. filed October 10a2008 and entitled Multi-LanguageIMulti-Processor Infusion Pump Assembly. nowU.S. Publication No. US0094221. hed April 15, 2010 (Attorney DocketNo. F54). which is hereby incorporated by reference.

Fig. 152 is a block diagram 1500 illustrating the sensors coupled to themechanics of an infusion pump for use with the infusion pump circuitry of Fig. 151in accordance with an embodiment of the present disclosure. The infusion pumpsfluid via a tube 15207. The motor 15204 includes motor hall-effect sensors 15205.a motor housing temperature sensor 15206, ffect sensors 15201 and 15202to detect the nt of the slide-clamp mechanism 15220, a hall-effect sensor15211 for an outlet valve. hall-effect sensors 15212 and 15213 for the plunger-position, a hall-effect sensor 15214 for an inlet valve, and a hall-effect rotaryposition sensor 15208.

Various alternatives and modifications can be d by those skilled in theart without departing from the disclosure. ingly. the present disclosure isintended to embrace all such alternatives. modifications and variances.

Additionally. while several embodiments of the present disclosure have beenshown in the drawings and/or discussed herein. it is not intended that thedisclosure be limited thereto. as it is intended that the disclosure be as broad inscope as the art will allow and that the specification be read se. Therefore,the above description should not be construed as limiting. but merely asexemplifications of particular embodiments. And, those skilled in the art willenvision other modifications within the scope and spirit of the claims appendedhereto. Other elements. steps, methods and techniques that are insubstantiallydifferent from those described above and/or in the appended claims are alsointended to be within the scope of the disclosure.

The ments shown in gs are presented only to traten examples of the sure. And, the drawings described are only illustrativeand are non-limiting. In the drawings, for illustrative purposes. the size of some ofthe elements may be exaggerated and not drawn to a particular scale. Additionally.ts shown within the drawings that have the same numbers may be identicalelements or may be similar elements. depending on the context.

Where the term "comprising" is used in the t description and claims, itdoes not exclude other elements or steps. Where an indefinite or definite article isused when referring to a singular noun. e.g. "a" "an" or "the“, this includes a pluralof that noun unless something othenivise is specifically stated. Hence. the term"comprising" should not be interpreted as being restricted to the items listedthereafter; it does not exclude other elements or steps. and so the scope of theexpression "a device comprising items A and B" should not be limited to devicesconsisting only of components A and B. This expression signifies that. with respectto the present invention, the only relevant components of the device are A and B.

Furthermore, the terms "first", "second", "third" and the like, whether used inthe ption or in the claims. are provided for distinguishing between similarelements and not arily for describing a sequential or chronological order. It isto be understood that the terms so used are interchangeable under appropriatecircumstances (unless y disclosed otherwise) and that the embodiments of theinvention described herein are capable of operation in other sequences and/orarrangements than are described or rated herein.

Claims (3)

What is claimed is:

1. A system for electronic t-care, comprising: a monitoring client configured to communicate with electronic medical records; and a patient-care device; wherein the monitoring client is configured to identify a patient and the patient-care device, and n the monitoring client is configured to download at least one treatment parameter from the electronic medical records and program the patient-care device with the at least one treatment parameter.

2. The system ing to claim 1, wherein the ring client identifies the patient in accordance with at least one of reading an RFID tag using an RFID interrogator, a voice using voice recognition software coupled using a microphone, a face using face-recognition software coupled to a camera, a biometric parameter of biometric read, an identification, a barcode read by a barcode reader.

3. A system according to claim 1, substantially as herein described or ified.