US20230386628A1 - Electronic Patient Monitoring System - Google Patents

Abstract

An electronic patient monitoring system comprising a monitoring client and a remote communicator are provided. The monitoring client is configured to store patient information. The patient information may be patient-specific information. The monitoring client may receive the information from a database, e.g., through a monitoring server.

Description

CROSS-REFERENCES
• The present application is a Continuation Application of U.S. patent application Ser. No. 17/118,801 filed Dec. 11, 2020 (Attorney Docket AA423) and entitled “Electronic Patient Monitoring System”, which is a Continuation Application of U.S. patent Ser. No. 13/971,258, filed Aug. 20, 2013 and entitled Electronic Patient Monitoring System, now U.S. Pat. No. 10,872,685, issued on Dec. 22, 2020 (Attorney Docket No. K84), which is a Continuation Application of U.S. patent application Ser. No. 13/011,543 filed Jan. 21, 2011 and entitled Electronic patient Monitoring System, and was abandoned on Feb. 21, 2012 (Attorney Docket No. 152), which claims the benefit of prior U.S. Provisional Application No. 61/297,544, filed Jan. 22, 2010 and entitled Electronic Order Intermediation System for a Medical Facility (Attorney Docket No. H53). Each of these applications is hereby incorporated by reference herein in its entirety.
BACKGROUND
• The present invention relates to systems and methods to provide electronic intermediation among medical devices delivering treatments to patients, medical devices monitoring parameters associated with those patients, and health care providers who order, process or initiate those treatments. An object of the invention is to reduce the incidence of medical treatment errors, and to improve the efficiency of tracking a patient's course of treatment.
• Despite the existence of systems incorporating electronic medical records (“EMR”), and computerized provider order entry (“CPOE”), the process of ordering and delivering medical treatments still has the potential to cause critical information to be miscommunicated, to allow treatment decisions to be made without ready access to complete information, and to delay implementation of treatment orders due to unnecessarily redundant and inefficient procedures. An approach to dealing with this problem is illustrated herein by using medication ordering as an example. It should be noted, however, that the invention as described herein can be applied to other treatment or diagnostic decisions involving the care of a patient.
• Medication errors may be responsible for over 300 deaths and may injure over one million people each year in the United States. Hospitals under financial stress may experience an increased incidence of medication errors. Medications associated with the most dangerous errors include insulin, narcotics, heparin and chemotherapy. Sources of error include administering the wrong drug, the wrong concentration of drug, at the wrong rate, or via the wrong route (medications can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically to the skin, eye or ear, intrathecally, intraperitoneally or even intravesically). Even with proper orders and proper labeling, medications still can be administered improperly because of illegible handwriting, miscommunication of orders, and mispronunciation of drugs having similar names. The trend toward the use of electronic medical records (EMR), and bar coding systems for medications has been shown to reduce the incidence of medication errors. EMR systems, for example, can facilitate computerized provider order entry (CPOE), and flag orders for drugs that do not match a patient's characteristics such as diagnosis, allergies, weight or age. However, these systems have not been widely adopted, and their implementation can result in significant delays and inefficiencies in ordering, preparing and administering medications.
• It has been estimated that medication infusion devices are involved in up to one third of all medication errors that result in significant harm. The wrong drug may be hung, incorrect parameters (e.g. drug concentration or rate of infusion) may be entered, or existing infusion parameters may be improperly changed. Of infusion pump-related deaths, nearly half may be due to user error, and most of these may be due to errors in programming the infusion device.
• An effective Monitoring system should monitor and intercede at any phase of the medication ordering and administration process to help minimize any of a number of adverse events that could result from the treatment. The medication treatment process conceptually can be separated into three phases: a prescription phase, a medication preparation phase, and an administration phase. Errors can occur when a prescription is written or entered, when a drug is retrieved for use or mixed in solution, or when it is administered to the patient. It would be particularly desirable for a monitoring system to not significantly impair the efficiency with which medications are ordered, prepared or administered, and preferably to actually reduce the time required to perform those activities by collecting, organizing and presenting relevant real-time information to the user.
SUMMARY
• In an exemplary embodiment involving the ordering and administration of medications, the Electronic Patient Monitoring system may comprise a first data-gathering module (e.g., a Monitoring Client) and a second order-input module (e.g. a fixed or portable communications device) having a user interface for transmitting an order or receiving patient-related information. The first module may be configured to receive and store measured parameters pertaining to a patient's current condition, such as blood pressure, heart rate, heart rhythm, temperature, oxygenation, respiratory rate, or ventilation, for example. The first module may also be configured to receive information about pre-existing parameters related to the patient from a first database (e.g. an EHR database containing information about the patient), including drug allergies or sensitivities, other currently administered drugs, age, weight, height, kidney or liver function, for example. The first module may also be configured to obtain medication information about the ordered medication and/or pre-existing drugs from a second database (e.g. a drug information database), such as known drug interactions, effects of the medication or pre-existing drugs on blood pressure, pulse, heart rhythm, or respirations, for example. The first module can be configured to compare the patient's currently measured parameters and received pre-existing parameters with known normal ranges, and create a table of patient parameters found to be outside the normal ranges. The first module may then compare the table of patient parameters with a table of corresponding parameters obtained from the drug information database. If a match is found to exist between the table of patient parameters and the table of corresponding parameters, the first module may then retrieve one or more pre-entered and stored messages for transmission to the second (order input) module. These messages may include, for example, warnings to a user of the second module that are appropriate for the particular medication ordered, the patient's pre-existing drugs, and the patient's current and pre-existing medical condition. Optionally, further repetitions of warnings may be avoided once a warning has been received by the second module, and the warning has been acknowledged by the user of the second module through an input signal from the user interface.
• In other embodiments, the Electronic Patient Monitoring system may provide the user with editable default values derived from standard dosing and administration guidelines obtained from the drug information database, and can alert the user to modifications that may be indicated based on the patient's current and pre-existing medical condition, allergies or other existing drugs. The Monitoring system preferably minimizes the amount of typed input required of a user.
• In other embodiments, the first module or other modules of the Electronic Patient Monitoring system may also be used to identify ordered medications to be delivered to the patient's bedside (through the use of, for example, bar codes and readers or RFID tags and scanners), and verify that the appropriate medication and dosage are being prepared and delivered to the patient. In an embodiment, the first module may also interact either in a hard-wired or wireless fashion with a device that administers treatment, such as a solution/medication infusion pump. In the case of an infusion pump, the first module or another connected module may provide the pump with infusion settings such as flow rate or infusion pressure, and receive from it various state parameters such as, for example, the presence of air in the infusion line, the amount of solution remaining in an IV bag to which it is connected, or the pressure of fluid in the infusion line. If the parameters are found to be abnormal, the first module may be configured to respond by signaling the pump to halt infusion, alter the rate of infusion, and/or alert a health care provider or others of the abnormality, either directly through an alarm incorporated in the first module, or by transmission of an alarm to the second module. In a further embodiment, the first module may also be configured to communicate with various medical devices used to monitor a patient's condition, such as, for example, blood pressure monitors, ECG monitors, pulse oximetry monitors, temperature monitors, and the like. In some cases, the first module can be programmed to emit an alert to the patient or other persons if the monitored parameters fall outside a pre-determined range. In some embodiments, the first module can transmit a signal to a monitoring device to conduct an unscheduled measurement by the device. The first module may communicate with various health care providers at various locations, and in an embodiment may be able to notify the patient to whom it is assigned of an abnormality, and recommend corrective action through, for example an audible alert or recorded message.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG.1 is a schematic representation of an exemplary Electronic Patient Monitoring system, showing paths of communication among system components.
• FIG.2 is an illustration of a display screen on a health care provider's portable communications device, showing a list of patients whose information the provider can access.
• FIG.3 is an illustration of a display screen on a health care provider's portable communications device, showing devices associated with a particular patient, with current data from the devices and one-touch access to some of the patient's medical information.
• FIG.4 is an illustration of a display screen on a health care provider's portable communications device, showing data entry fields for a prescription for a medication for use with an intravenous infusion pump.
• FIG.5 is an illustration of a display screen on a health care provider's portable communications device, showing a risk profile associated with an ordered medication, and a suggested course of action, as generated by the Monitoring.
• FIG.6 is an illustration of a display screen on a health care provider's portable communications device, showing a medication prescription ready for submission by the ordering provider.
• FIG.7 is an illustration of a display screen on a health care provider's portable communications device, showing how the Monitoring system can display confirmation to the ordering provider that the prescription has been transmitted to the pharmacist.
DETAILED DESCRIPTION
• As shown inFIG.1, components of the Electronic Patient Monitoring System may include one ormore Monitoring Clients1,4, each of which may be assigned and in physical proximity to anindividual patient2, and a moreremote Monitoring Server3 for the uploading of information from a number ofMonitoring Clients1,4, and for downloading information and instructions from various sources to theMonitoring Clients1,4. When in the patient's room, a health care provider can interact directly with aMonitoring Client1 to obtain information about thepatient2 or to enter orders pertaining to thepatient2. Alternatively, providers at remote locations (e.g., doctor's office,nursing station5, hospital pharmacy6) may interact with anindividual Monitoring Client1 through a communications link with theMonitoring Server3, or directly via a hospital local area network having eachMonitoring Client1,4 as a node.
• In an embodiment, eachMonitoring Client1 is assigned to aspecific patient2, and can be a desk-based, portable or hand-held controller with display and user input capability. Preferably, it is portable and allows for efficient data viewing and data entry, such as a notebook PC, netbook PC, tablet PC, or even a ‘smart-phone,’ with or without touch screen capability. The designation of aparticular Monitoring Client1 to aparticular patient2 may be made using any of a number of methods, including (but not limited to) a unique patient identifier using a bar coded or RFID tag-embedded wrist band, for example. TheMonitoring Client1 may include one or more microprocessors to send and receive information relevant to the patient's care or condition. In some embodiments, theMonitoring Client1 may be physically associated with amedical infusion pump7 either permanently or detachably. This can be accomplished by a docking interface between the two devices. TheMonitoring Client1 can communicate with thepump7 in a number of ways, including, for example, through electrical contacts in the docking interface, by means of an electrical connector, or wirelessly by means of transceivers on each device. TheMonitoring Client1 can also communicate with other databases in thefacility8, with databases external to thefacility9,10, and with health care providers via portable communications devices11 (including, for example, physicians, nurses, and pharmacists). This can be accomplished by a wired connection to a facility server through a connector in the patient's room (such as, for example, aCategory 5 local area network connector), or wirelessly12. In one embodiment, access to intra and extra facility databases is mediated13 through theMonitoring Server3, which can then centralize the software and application programming interfaces required to communicate with databases having disparate organization, formatting and communications protocols. Thus, in an embodiment, any software updates may be largely limited to theMonitoring Server3, reducing the maintenance requirements on theindividual Monitoring Clients1,4. Optionally, aMonitoring Client1 can communicate with medical treatment devices such as infusion pumps7 to receive information about the progress of treatment, and to provide operational instructions to the treatment device. In another embodiment, theMonitoring Client1 may also communicate with medical diagnostic or monitoring devices (such as, for example, an electrocardiographic (ECG) monitor14, a blood pressure (BP) monitor15, a pulse oximeter orCO2 capnometer16, or other devices such as temperature monitors, etc.) to receive readout information from the devices, and potentially to instruct18 the devices to take a reading when desired by a provider or by algorithm.
• In an embodiment, theMonitoring Client1 has the ability to communicate and interact directly with a health care provider using a hand-held orportable communications device11. This may be conveniently accomplished wirelessly12, so that communications can be maintained regardless of the patient's location in the facility, or the provider's location either within or outside the facility. In one aspect, information specific to thepatient2 can be stored locally in theMonitoring Client1, so that the patient's health care provider can access the information directly without having to access theMonitoring Server3. By incorporating appropriate safety and security clearances, changes to the settings or flow parameters of a connected infusion pump7 or monitoring device14-17 can be accomplished directly between a provider'scommunications device11 and theMonitoring Client1, with selected changes being also communicated toMonitoring Server3, and thence to other appropriate locations, such as theNursing Station5, and/orPharmacy6. Furthermore, any new order pertaining to thepatient2 may be entered in the ordering provider'scommunications device11 and transmitted to theMonitoring Client1, which in turn can then notify the care giver (e.g. RN) via the care giver's ownportable communications device11. Preferably, any information acquired and stored in theMonitoring Client1 is periodically uploaded to theMonitoring Server3 and stored in a patient-specific database. Thus, if a patient'sMonitoring Client1 needs to be taken out of service, a new device can be assigned to thepatient2 and quickly re-populated with the patient's current information from theMonitoring Server3. Orders, medications, progress notes, monitoring and treatment data from the patient's attached devices may also be uploaded from theMonitoring Client1 to the patient'sEHR19,19′ for permanent storage.
• TheMonitoring Server3 may comprise a computer that can communicate with and provide some elements of control for a number of Monitoring Clients4 in the facility. It may provide aMonitoring Clients1,4 with data extracted from a number of databases both within 8 and outside9 of the facility. In an embodiment, theMonitoring Server3 can interrogate the facility'sEHR system19 for targeted information pertaining to apatient2, and then populate that patient'sMonitoring Client1 with a pre-defined set of information (such as, for example, the patient's age, height, weight, categories of diagnoses, current medications and medication categories, medication allergies and sensitivities, etc.). TheMonitoring Server3 may establish a link toEHR19,Laboratory20,Radiology21,Pharmacy22 and other systems (such as, e.g.,Cardiology23 or Scheduling database24) in the facility when, for example, aMonitoring Client1 has been assigned to apatient2. With a unique patient identifier, theMonitoring Server3 can obtain electronic access (permission) to receive and send patient-specific data from and to these systems. A pre-determined (but selectable) subset of the data may be downloadable into theMonitoring Client1 memory. The information thus acquired can then serve as a key database against which new orders can be analyzed. Orders entered into aMonitoring Client1 can be checked for compatibility with the patient-specific information obtained by theMonitoring Server3. Optionally, for safety redundancy, orders entered remotely from aportable communications device11 can be intercepted by theMonitoring Server3 and similarly can be checked. TheMonitoring Server3 may also obtain information from medication databases residing in the facility'spharmacy22 or externally9 to determine whether a new patient order may generate an incompatibility with a patient's existing medications, for example. In an embodiment, theMonitoring Server3 may be programmed to access publiclyavailable internet sites25 to determine whether new information pertaining to the patient's ordered medication should be downloaded and transmitted 13 in an alert to the patient's health care provider(s). TheMonitoring Server3 may also route information between remoteportable communications devices11 and a patient'sMonitoring Client1.
• In an embodiment, the patient's physician, nurse or pharmacist may have access to the patient'sMonitoring Client1 to relay or receive new orders (such as medication orders, for example) pertaining to thepatient2. TheMonitoring Client1 orServer3 may then log the new order and relay the request to thepharmacist6, and the patient's nurse via the nurse'sportable communications device11 and/or via a fixed terminal at thenursing station5. A ‘smart phone’ having a customized communications application with Monitoring Client1 (such as, e.g., a Google Nexus One phone or Apple i-phone, among others) may serve as a convenientportable communications device11 for providers who are not at a fixed location (such as at an office or remote nursing station). A tablet PC, netbook, or laptop computer may also serve as a convenientportable communications device11 for both portable and fixed locations. A PC may act as aconvenient communication device11 for fixed or desktop locations. If a provider is located in the patient's room, he or she may enter or receive information pertaining to thepatient2 using a direct input through a keyboard or touch screen on theMonitoring Client1.
Example of Monitoring-Assisted Order Entry
• The functionality of the Patient Monitoring system can be illustrated by an example in which an ordering provider enters a new medication prescription for a patient. In this scenario, the physician may view his list of admitted patients on his hand-held device after entering the appropriate security pass code. In this example, the physician's patients can be listed as shown inFIG.2, with limited and user-selectable information26 on each patient, such as, for example, age, diagnosis, and medical record number.Alert symbols27 may be transmitted by theMonitoring Client1 to the physician'sdevice11 if, for example, orders for thepatient2 are incomplete, the nurse has flagged the patient for attention, or if theMonitoring Client1 has received input from a database or a patient monitoring device14-17 that has exceeded a pre-determined threshold for physician notification.
• After the physician selects a patient for further review, a display such as that shown inFIG.3 may be transmitted to the physician'sdevice11. The physician can view user-selectable data originating from monitors14-17 to which the patient is connected, and the physician may have one-touch access to a number of databases19-21,23 containing patient-specific information. In an embodiment, theMonitoring Client1 may be connected or docked to aninfusion pump7 available for use with thepatient2. In a scenario illustrated inFIG.3, the physician can press on the icon representing theinfusion pump7 to order an intravenous medication for thepatient2.
• FIG.4 shows one of a number of possible prescription ordering screens with which a physician can remotely order a medication. In the example illustrated, the physician enters thedrug IV Nitroglycerin28, which may be entered by typing or via a drop-down screen populated by the hospital pharmacy'sformulary22, accessed by theMonitoring Client1 via theMonitoring Server3. The ‘PDR’button29 may represent the physician's one-touch access to an in-hospital22 orproprietary drug database9 for detailed drug information. The physician can order the dose of medication, either directly or by accepting a defaultstandard starting dose30 provided by theMonitoring Client1 via theMonitoring Server3. The physician may also specify the maximumfluid infusion rate31 for theinfusion pump7, in order to assist the pharmacist in preparing the proper concentration of the drug in a bag for infusion.
• FIG.5 shows an example of how the Patient Monitoring system can detect a risk of an adverse reaction after the physician has entered the prescription. TheMonitoring Client1 can compare thenew medication28 to the patient's existing medications and drug allergy list downloaded from theEHR19. TheMonitoring Server3 preferably will have populated the appropriate patient-specific data into theMonitoring Client1, and theClient1 will be programmed to look up this information after the new medication order has been entered. TheMonitoring Client1 may be programmed to request a listing of significant adverse reactions and drug interactions associated with each of the patient's medications and thenew medication28 from theMonitoring Server3. TheServer3, in turn can access apharmacy database22 orexternal database9 for this information. If a potential drug interaction or adverse reaction common to an existing medication and thenew medication28 are detected, theMonitoring Client1 may issue awarning32 and transmit it to the ordering physician, as shown inFIG.5. If the potential adverse reaction is due to an effect common to both the new medication and an existing medication, theMonitoring Client1 may categorize this as a potentially additive adverse effect and issue arecommendation33 to reduce the initial drug dose, for example, by 50%.
• As shown inFIG.6, the ordering physician has the option either to accept therecommendation33 or edit the recommended dose to another value. In any event, theMonitoring Client1 may generate and log areport34 of thewarning32 and anycorrective action33, if any, taken by the physician, with the option for the physician to further edit the report before logging and entry into the patient'sEHR19.
• Once the medication dosing is finally determined, theMonitoring Client1 can forward the order to the communication devices of both thehospital pharmacist6 and the patient'snurse5. A report of the accomplishment of this task may then be transmitted back to the orderingphysician11, as shown inFIG.7. The pharmacist can use the information provided by the ordering physician to mix an appropriate concentration of the medication in a solution bag. Both the medication vial and the solution bag may have identification tags, such as, e.g., bar code identifiers, that can be read into the pharmacist'scommunications device6, and which can be verified as correct by the Monitoring Client1 (using thepharmacy database22 as accessed by the Monitoring Server3). The pharmacist may then generate a unique identification label, such as a bar code label, to be permanently affixed to the medication bag, the code now being linked uniquely to thepatient2 for whom themedication28 has been prepared. The identifying code on the label may be transmitted to theMonitoring Client1 for later reconciliation when the nurse is about to administer themedication28.
• After theprepared medication28 arrives to the patient's floor, the nurse can then prepare to administer it to thepatient2. In this exemplary scenario, theMonitoring Client1 may include an input device such as a bar code reader, which the nurse can use to verify that the identifying code on the medication bag matches the identity of thepatient2 for whom it has been prescribed. If the identification matches the information entered into theMonitoring Client1 by the pharmacist, the nurse may be cleared by thedevice1 to hang the medication bag and initiate the infusion via theinfusion pump7. In an embodiment, theMonitoring Client1 displays to the nurse the prescription, including the dose, the maximum fluid rate for the patient, the concentration of the drug in the bag, and the infusion rate for the pump (which can optionally be calculated by a processor in the Monitoring Client1). With this information, the nurse has the ability to manually calculate and verify that the infusion rate set by theMonitoring Client1 for thepump7 is correct.
Network Connectivity Among System Components and Devices
• AMonitoring Client device1 can receive, process, and transmit information about aspecific patient2 to which it has been assigned or designated. TheMonitoring Client1 can most conveniently be attachable or dockable to aninfusion pump7, bed, or other device to which thepatient2 may be connected. TheMonitoring Client1 can be a hand-held device about the size of a wireless phone or tablet-style netbook, for example. Conveniently, it may have a touch-screen interface for use by the patient's provider. It may also be capable of providing output to a larger stationary display screen in the patient's room or at anursing station5 or other convenient location, either through a wired or wireless connection. EachMonitoring Client1 may communicate with acentral Monitoring Server3, through which it can access patient data from the facility'sEHR database19,Laboratory database20,Radiology database21,Pharmacy database22, or other databases in various other facility departments. In some cases, theMonitoring Client1 can upload information it receives from patient monitoring systems15-17 or from provider inputs to the patient'sEHR19 via theMonitoring Server3.Monitoring Clients1,4 may also receive information from databases outside of the facility through aMonitoring Server3 having aninternet connection25. Variousexternal databases9 may thus be accessible, including various drug information databases and alert networks dealing with adverse medication-related events. TheMonitoring Server3 could be arranged, for example, to manage various levels of external database information helpful in keeping theMonitoring Client1 contents as up-to-date as possible. This can be accomplished, for example, by comparing safety and drug information related to the patient as it becomes available, and prioritizing for updates/downloads on a data transfer schedule. TheMonitoring Clients1,4 may also communicate either directly or through theMonitoring Server3 withportable communications devices11 used by health care providers such as nurses, physicians and pharmacists. In some cases, these devices can have wired connections to the Monitoring Server3 (if used, for example, in fixed locations such as hospital pharmacies or nursing stations). In other cases, aportable communications device11 may communicate with theMonitoring Server3 through VPN-based internet connections using a computer and a wired or wireless (such as, e.g., Bluetooth or WiFi 802.11)connection13 with thedevice11. Alternatively, a hand-held device11 (such as a wireless smart-phone or tablet netbook) may communicate directly12 with the facility'sMonitoring Client1 via a cellular telephone network.
• The communications link between theMonitoring Clients1,4 and theMonitoring Server3 may exist via a Category-5 wired network if widely available in the facility, or via wireless transmission using one of a number of standards, linking all the patient-specific Monitoring Clients1,4 with thecentral Monitoring Server3. Theserver3 may then serve as a relay for communications withother facility servers8, with web-basedservers25, and with inside and outsideportable communications devices11 carried by medical care providers. A wireless network provides the additional functionality of being able to communicate with theMonitoring Server3 no matter where in the facility thepatient2 may be.
• One method of blanketing an entire facility with wireless coverage involves having the facility obtain a license for a private cell-phone network. It may obtain or lease one or more micro-cellular frequencies to provide for a local communications network throughout the facility. This arrangement can preserve communications when patients and theirMonitoring Clients1,4 are moved from one location to another within the facility, maintaining communications with aMonitoring Server3, various in-hospital and out-of-hospital databases8,25, and users at fixedstations5,6 or with mobile smart-phone, laptop or tablet-type devices11 either inside or outside the hospital. An advantage of this type of system is the level of security provided by a licensed cellular communications infrastructure. In addition, an active wireless system can monitor the intensity of use in an area and direct additional channel frequencies to that area as needed. However, the bandwidth capacity of the network may not allow for efficient transmission of large data files, such as those containing radiology images, for example.
• Alternatively or additionally, a hospital may implement an internet or intranet based communications system, in which an 802.11 WiFi-type protocol is used for wireless communications betweenindividual Monitoring Clients1,4 and themain Monitoring Server3. To ensure adequate signal reception throughout the facility, a broadband antenna may be mounted on the roof of the building to collect cell phone signals from local wireless phone companies. A fiber-optic or cable network may then distribute the signals throughout the facility. Alternatively, theMonitoring Server3 may use the private cell-phone network mentioned above. Although this system may not be as secure as a micro-cell system, it may be capable of providing the data throughput to accommodate large files, such as, for example, radiology images stored in theRadiology database21. Home or office-based users may be able to connect to the hospital server through VPN access using wired or fiber-optic cable, or a DSL phone line. Data encryption may be used to provide needed patient data security. In some applications it may be advantageous to implement an asymmetric bandwidth communications network in order to optimize infrastructure capabilities. An example of this would be using licensed cellular frequencies in the “upstream” direction from theMonitoring Client1 to theMonitoring Server3 and the unlicensed 802.11 WiFi frequencies in the “downstream” direction from theMonitoring Server3 to theMonitoring Client1. In this example the upstream bandwidth and data rate requirements are relatively small compared to the downstream requirements. In low priority upstream transmissions theMonitoring Client1 may allow data to be sent over a more distributed and cost-efficient network, such as, for example, a ZigBee network.
• Communications between various monitoring devices and theMonitoring Client1 may be achieved in a cost effective manner using, for example, a ZigBee wireless mesh network. Exemplary monitoring devices include ECG monitors14, blood pressure monitors15, pulse oximeters/capnometers16, thermometers, and weight scales, among others. A common characteristic of most of these devices is that they provide periodic readouts of a single or small number of parameters. An intra-hospital device communications system such as the wireless mesh network provides for low-power digital radio connectivity among devices, and may employ a widely available, license-free 2.4 GHz frequency band. High-level communications protocols may be employed to ensure data fidelity and security. It is highly scalable, allowing hundreds or thousands of devices to be used on a single self-forming, self-healing mesh network. Devices connected to the network may communicate with one another and serve as repeaters to transfer data efficiently. The advantages of this system are its relatively low cost, scalability and mobility for the patient being monitored. The wireless range for devices linked to the wireless mesh network can approach 70 meters from each node of the system inside a facility. A similar network may be used in providing a wireless link within the facility betweenportable communications devices11 carried by health care providers and their assigned patients through the patients'Monitoring Clients1,4.
• In many cases, the information being transmitted to theMonitoring client1 may include a single parameter value (such as, for example, blood pressure) and a time stamp. TheMonitoring Client1 can be programmed to determine whether the value is outside a predetermined range, record the value in the patient'sEHR19, and notify the appropriate care-giver via theircommunications device11. Furthermore, the network may enable bidirectional communications, and may allow theMonitoring Client1 to query15 the monitoring device, instructing it18 to take an unscheduled reading. This can be useful, for example, when an abnormal reading is received, and its authenticity needs to be verified. TheMonitoring Client1 may be programmed to request a repeat reading to verify the abnormal reading. In a further refinement, theMonitoring Client1 may be programmed to interrupt or adjust theinfusion pump7 flow rate, depending on the value of the reading received from a monitoring device14-17. For example, if the BP monitor15 indicates a blood pressure below a pre-determined acceptable range, theMonitoring Client1 may be programmed to instruct theinfusion pump7 to stop the infusion, and it can transmit anurgent notification12 to the health care provider(s)′communications devices11. In another embodiment, if theinfusion pump7 is capable of measuring the volume of fluid being delivered to thepatient2, a processor in theMonitoring Client1 may track the cumulative volume delivered and estimate the amount of fluid remaining in the medication bag. (Alternatively, a processor in theMonitoring Client1 orinfusion pump7 may calculate the volume delivered from the infusion rate and elapsed time of infusion). Once the estimated residual volume reaches a pre-determined amount, theMonitoring Client1 may signal theinfusion pump7 to reduce its flow rate to keep the patient'sIV access35 from running dry. It may also send a notification to the nurse'scommunications device11, recommending replenishment of the medication or solution.

Claims (50)

We claim:

1. System for electronic patient monitoring comprising a smart phone configured to:

access physiological data of a patient from a tablet;

display the physiological data and editable default values next to a treatment order of a medication with an option to send the treatment order to an infusion pump and an option to view a reference about the medication;

instruct the infusion pump to treat the patient according to the treatment order when said smart phone receives user input to send the treatment order; and

display the reference when said smart phone receives user input to view the reference.

2. System ofclaim 1 further comprising a tablet configured to store the physiological data.

3. System ofclaim 2 wherein said tablet is configured to receive the physiological data from a monitoring-server computer that is configured to retrieve physiological data from a database computer.

4. System ofclaim 1 wherein communications of said system occur across a wireless network that is configured to be operable within a facility.

5. System ofclaim 4 further comprising a tablet configured to store the physiological data;

wherein said smart phone is configured to communicate with said tablet while outside of the facility having an associated patient located therein.

6. System ofclaim 2 wherein the smart phone is configured to:

change a setting of the infusion pump based on data other than the physiological data; and

transmit the setting to said tablet.

7. System ofclaim 6 wherein said system is configured to communicate the setting to a monitoring-server computer.

8. System ofclaim 2 wherein said tablet is configured to store information selected from: orders, medications, progress notes, monitoring and treatment data from a device attached to a patient, and combinations thereof.

9. System ofclaim 8 wherein said tablet is configured to upload the information from a device attached to the patient to a database computer.

10. System ofclaim 1 wherein the physiological data pertains to: age, height, weight, current medication, medication category, medication allergy, medication sensitivity, and combinations thereof.

11. System ofclaim 2 wherein said tablet is configured for assignment to the patient.

12. System ofclaim 11 wherein the assignment utilizes a unique patient identifier.

13. System ofclaim 12 wherein the unique patient identifier is embedded on a bar code or an RFID tag-embedded wrist band.

14. System ofclaim 2 wherein said tablet is physically associated with the infusion pump.

15. System ofclaim 2 further comprising:

a patient monitoring device configured to obtain a measure of a physical characteristic of the patient;

wherein said tablet receives the measure in real time.

16. System ofclaim 2 wherein said tablet is configured to determine if a new order meets criteria based on the physiological data.

17. System ofclaim 4 wherein the wireless network is configured to determine a usage intensity of an area and allocate channel frequencies in accordance with the usage intensity by directing additional channel frequencies to the area.

18. System ofclaim 3 wherein the database computer is an electronic health records database computer.

19. System ofclaim 3 wherein said smart phone is configured to access the physiological data without accessing the database computer.

20. System ofclaim 4 wherein:

the wireless network comprises a WIFI type network; and

said smart phone and the tablet are configured to communicate via the WIFI type network.

21. System ofclaim 1 wherein said smart phone is configured to provide one-touch access to a patient's medical information.

22. System ofclaim 2 wherein said tablet is configured to monitor a progress of treatment.

23. System ofclaim 1 wherein said smart phone is configured to communicate a change to a setting of the infusion pump directly to the tablet.

24. System ofclaim 2 wherein said tablet is configured to receive state parameters.

25. System ofclaim 24 wherein said tablet is configured to signal the infusion pump to: halt infusion, alter a rate of infusion, alert a health care provider when a state parameter is abnormal, and combinations thereof.

26. System ofclaim 25 wherein said tablet is configured to communicate the alert to said smart phone.

27. System ofclaim 1 wherein said smart phone is configured to display a risk profile associated with: an ordered medication, a suggested course of action as generated by the tablet, and combinations thereof.

28. System ofclaim 2 wherein said tablet is configured to access a database computer within the facility and access another database computer outside of the facility.

29. System for electronic patient monitoring comprising a tablet configured to:

receive physiological data of a patient from: a monitoring-server computer, a database computer, and combinations thereof;

store the physiological data; and

provide the physiological data to a smart phone configured to instruct an infusion pump to treat the patient according to a treatment order.

30. System ofclaim 29 wherein communications of said system occur across a wireless network that is configured to be operable within a facility.

31. System ofclaim 30 wherein said tablet is configured to communicate with the smart phone while the smart phone is outside of the facility having an associated patient located therein.

32. System ofclaim 29 further comprising a smart phone that is configured to:

change a setting of the infusion pump based on data other than the physiological data; and

wherein said tablet is configured to receive the setting.

33. System ofclaim 29 wherein said tablet is configured to store information selected from: orders, medications, progress notes, monitoring and treatment data from a device attached to a patient, and combinations thereof.

34. System ofclaim 33 wherein said tablet is configured to upload the information from a device attached to the patient to a database computer.

35. System ofclaim 29 wherein the physiological data pertains to: age, height, weight, current medication, medication category, medication allergy, medication sensitivity, and combinations thereof.

36. System ofclaim 29 wherein said tablet is configured for assignment to the patient.

37. System ofclaim 36 wherein the assignment utilizes a unique patient identifier.

38. System ofclaim 37 wherein the unique patient identifier is embedded on a bar code or an RFID tag-embedded wrist band.

39. System ofclaim 29 wherein said tablet is physically associated with the infusion pump.

40. System ofclaim 29 further comprising:

a patient monitoring device configured to obtain a measure of a physical characteristic of the patient;

wherein said tablet receives the measure in real time.

41. System ofclaim 29 wherein said tablet is configured to determine if a new order meets criteria based on the physiological data.

42. System ofclaim 30 wherein the wireless network is configured to determine a usage intensity of an area and allocate channel frequencies in accordance with the usage intensity by directing additional channel frequencies to the area.

43. System ofclaim 29 wherein the database computer is an electronic health records database computer.

44. System ofclaim 30 wherein:

the wireless network comprises a WIFI type network; and

the smart phone and said tablet are configured to communicate via the WIFI type network.

45. System ofclaim 29 wherein said tablet is configured to monitor a progress of treatment.

46. System ofclaim 29 wherein the smart phone is configured to communicate a change to a setting of the infusion pump directly to said tablet.

47. System ofclaim 46 wherein said tablet is configured to receive state parameters.

48. System ofclaim 29 wherein said tablet is configured to signal the infusion pump to: halt infusion, alter a rate of infusion, alert a health care provider when a state parameter is abnormal, and combinations thereof.

49. System ofclaim 48 wherein said tablet is configured to communicate the alert to the smart phone.

50. System ofclaim 29 wherein said tablet is configured to access a database computer within the facility and access another database computer outside of the facility.

Images