US20100130933A1 - Medication managment system - Google Patents
Medication managment system Download PDFInfo
- Publication number
- US20100130933A1 US20100130933A1 US12/639,485 US63948509A US2010130933A1 US 20100130933 A1 US20100130933 A1 US 20100130933A1 US 63948509 A US63948509 A US 63948509A US 2010130933 A1 US2010130933 A1 US 2010130933A1
- Authority
- US
- United States
- Prior art keywords
- mmu
- medical device
- patient
- drug
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
- G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H70/00—ICT specially adapted for the handling or processing of medical references
- G16H70/40—ICT specially adapted for the handling or processing of medical references relating to drugs, e.g. their side effects or intended usage
Definitions
- the present invention relates to the field of delivering medication to patients, more particularly to an integrated system for maximizing patient safety and caregiver productivity for medication delivery.
- Modern medical care often involves the use of medical pump devices to deliver fluids and/or fluid medicine to patients.
- Medical pumps permit the controlled delivery of fluids to a patient, and such pumps have largely replaced gravity flow systems, primarily due to the pump's much greater accuracy in delivery rates and dosages, and due to the possibility for flexible yet controlled delivery schedules.
- modern medical devices, including medical pumps can be complicated and time-consuming for caregivers to program. Medical facilities struggle to provide appropriate caregiver staffing levels and training while holding down the cost of medical care. Human errors in pump programming and other medication errors can have adverse or even deadly consequences for the patient.
- a principal object of this invention is to provide an integrated medication management system that reduces the risks of medication error and improves patient safety.
- a further object of the invention is to provide a medication management system that improves caregiver productivity.
- Another object of the invention is to provide a medication management system that improves the accuracy of the medication delivery process by eliminating labor-intensive tasks that can lead to human errors.
- a still further object of the invention is to provide a medication management system that relies on an electronically-transmitted medication order and machine readable indicia on the drug container, patient, and medication delivery device to insure the “five rights” of medication management, i.e., that the right medication is delivered to the right patient through the right route in the right dosage at the right time.
- Another object of the invention is to provide the caregiver with a pass code or machine-readable indicia to insure that only an authorized individual caregiver can initiate a medication order and that an authorized caregiver must confirm the medication order prior to its administration to the patient.
- a still further object of the invention is to provide a medication management system wherein the medical device receives delivery information electronically only through a medication management unit.
- Another object of the invention is to provide medication management system wherein the medical device is preprogrammed and executes the medication order only after a user has validated delivery data.
- a still further object of the invention is to provide a medication management system wherein the physical location of a medical device can be determined and pinpointed based on the last access node used by the medical device.
- Another object of the invention is to provide a medication management system for adjusting a patient-specific rule set based on new patient conditions and/or recent lab results.
- a still further object of the invention is to provide a medication management system for determining drug-drug incompatibility between two medication orders for concurrent delivery (to the same patient at the same time) and/or in an unacceptably close time sequence.
- Another object of the invention is to provide a medication management system for remotely sending an order or information to the medical device to modulate a planned or ongoing medication order and delivery thereof to the patient.
- a still further object of the invention is to provide a medication management system for automatically associating a medical device with a patient based on wireless transmission of a patient ID to the medical device, thereby establishing a patient area network.
- Another object of the invention is to provide a medication management system for caching an updated drug library at the medical device to replace an existing drug library, during execution of a medication order.
- a still further object of the invention is to provide a medication management system for displaying a picture of the patient on a device within the system, such as at the medical device, for a caregiver to perform a visual validation of the right patient.
- Another object of the invention is to provide a medication management system for evaluating the performance of multiple medical devices based on information from the multiple medical devices.
- a still further object of the invention is to provide a medication management system for evaluating the performance of one or more caregivers based on information from multiple medical devices.
- Another object of the invention is to provide a medication management system for adjusting medical device output conveyed to a caregiver based on multiple factors.
- a medication management system includes a medication management unit (MMU) associated with a medical device for performing a prescribed medication order.
- the MMU compares medication order information from a first input means to machine readable delivery information from a second input means and downloads a medication order to the medical device only if the information from the first input means matches the information from the second input means.
- the medical device receives medication order information electronically only through the medication management unit (i.e., does not receive delivery information directly from the second input means).
- the MMU permits the medical device to perform the order only after a user has validated delivery data at the medical device.
- the MMU determines the general physical location of a medical device based on the last access node used by the wireless connectivity capability in the medical device and an audible alarm can be activated to allow a user to pinpoint the physical location of the medical device more precisely.
- the MMU uses expert clinical support decision rules to determine drug-drug incompatibility between two medication orders for concurrent delivery (to the same patient at the same time) and/or in an unacceptably close time sequence through the same output IV line. Further, the MMU also adjusts patient-specific rule sets based on newly measured or observed patient conditions and/or recent lab results.
- warnings, alarms or alerts based on violations of these rules are provided as close as possible to the actual delivery time so that they are more meaningful, ripe for corrective action, and less likely to be ignored due to incomplete information.
- the MMU can modulate the medication order planned or currently being delivered.
- the MMU sends an order from the MMU to the medical device to modulate performance of the medication order.
- the patient and the medical device automatically associate with each other to form a patient area network based on wireless transmission of ID information.
- the medical device caches an updated drug library in a cache memory and, upon occurrence of a triggering event, replaces an existing drug library in the primary memory of the device with the updated library.
- a picture of the patient is displayed at a device within the system, such as the medical device, for a caregiver to perform a visual validation of the right patient.
- the MMU evaluates the performance of multiple medical devices and one or more caregivers based on information communicated from the medical devices.
- the MMU adjusts medical device output conveyed to a caregiver based on multiple factors.
- the MMU receives validated, matched or verified correct medication order and delivery information from an information system directly through an electronic network or indirectly through a wireless handheld point-of-care input (scanning) device, such as a personal digital assistant (PDA).
- PDA personal digital assistant
- the PDA transmits the delivery information and the medication order in the form of an infusion rate to the MMU.
- the MMU translates the simple infusion rate of the delivery order into delivery programming code or information suitable for automatically programming the designated pump and further checks the delivery order and delivery programming code against a variety of drug library parameters (including but not limited to hard and/or soft limits for drug delivery rates), patient-specific safety factors, and clinical decision support rules including drug-drug interactions.
- the MMU can be configured by the user at the MMU console to monitor the status of the pump and the infusion (including alarms, event logs, and pump user interface inputs), generate reports, and control the distribution of drug library and operating code updates to one or more pumps.
- a drug library editor deployed as a part of the MMU, its console, or on a separate computer enables the user to import, export and edit whole drug libraries and individual drug library values to control and customize a drug library according to hospital preferences.
- the MMU saves the caregiver time by automatically populating or programming data entry fields in the pump that previously had to be entered manually.
- the medication management system of this invention enhances patient safety by minimizing manual entries.
- the system also enhances patient safety by screening drug delivery orders for conformance with established hospital practices, expert or clinical decision support rules and recommendations before (more preferably immediately before) the pump begins to execute the order.
- the caregiver is provided with a least one and preferably several opportunities to catch a medication error before it happens.
- the caregiver can confirm the order at the point-of-care device and/or before pressing the start button on the pump.
- the system is flexible enough to permit human interventions and overrides, but tracks such events for documentation and trouble-shooting purposes.
- FIG. 1 is a schematic diagram of the medication management system including a medication management unit and a medical device, integrated with an information system, according to the present invention.
- FIG. 1A is an alternative schematic diagram of the medication management system including a medication management unit and a medical device, integrated with an information system, according to the present invention.
- FIG. 2 is a schematic diagram of the medication management unit according to the invention.
- FIG. 3 is a schematic diagram illustrating some of the major functions performed by the medication management unit according to the invention.
- FIG. 4 is a pictorial schematic diagram of the medication management system and its interaction with medical devices and an information system in a hospital environment.
- FIG. 4A is a schematic diagram of the medical device according to the invention.
- FIG. 5 is a partial flow chart of the medication management system processing a drug order through the medication management unit and medical device, and integrated with an information system according to the invention.
- FIG. 5A is a continuation of the flow chart of FIG. 5 .
- FIG. 6 is an alternative flow chart of the medication management system processing a drug order through the medication management unit and medical device, and integrated with an information system according to the invention.
- FIG. 6A is a continuation of the flow chart of FIG. 6 .
- FIG. 7 is a screen shot of a delivery information input device for entry of a caregiver specific pass code.
- FIG. 8 is a screen shot of a delivery information input device for pulling up a scan patient option.
- FIG. 9 is a screen shot of a delivery information input device for entry of patient-specific information.
- FIG. 10 is a screen shot of a delivery information input device displaying a task list.
- FIG. 11 is a screen shot of a delivery information input device displaying a medication order prescribed for a patient.
- FIG. 12 is a front view of a medical device displaying a start up screen.
- FIG. 13 is a front view of a medical device with a display and user interface means for selecting a clinical care area of a medical facility.
- FIG. 14 is a front view of a medical device with a display and user interface means for selecting a desired input channel of the medical device.
- FIG. 15 is a front view of a medical device with a display and user interface means for confirming correct delivery programming code data at the medical device.
- FIG. 16 is a screen shot of a delivery information input device for confirming correct delivery programming code data.
- FIG. 17 is a schematic diagram of the medication management system including a medication management unit and one or more medical devices, showing how the medication management unit communicates with a medical device to locate the device.
- FIG. 18 is a flow chart of the medication management system locating a medical device.
- FIG. 19 is a flow chart of the medical device retrieving/receiving an updated drug library from the medication management unit.
- FIG. 20 is a flow chart of the medication management system updating a delivery program code executed on the medical device based on new information from a lab system, HIS and/or monitoring device.
- FIG. 21 is an alternative pictorial schematic diagram of the medication management system and its interaction with medical devices and the information system.
- FIG. 22 is a flow chart of the medication management system generating an operation evaluation report of a caregiver or medical device.
- FIG. 23 is similar to FIG. 1 , but shows an alternative schematic diagram of the medication management system including a medication management unit and a medical device, integrated with an information system without using a patient link, according to the present invention.
- FIG. 24 is a schematic diagram that provides further detail on the architecture and workflow related to the medication management system depicted in FIG. 23 .
- FIG. 25 is a schematic diagram that depicts the flow of data with respect to the medication management system of FIG. 23 .
- FIG. 26 is a flow chart showing the actions and interactions for automatically programming a medical device such as an infuser and monitoring status of the task programmed using the medication management system of FIG. 23 .
- FIG. 27 is a flow chart showing the actions and interactions for downloading a drug library or other information to a medical device such as an infuser using the medication management system of FIG. 23 .
- FIG. 28 is a flow chart showing the actions and interactions for uploading and monitoring infusion status in the medication management system of FIG. 23 .
- FIG. 29 is a flow chart showing the actions and interactions for uploading and maintaining event logs in the medication management system of FIG. 23 .
- FIG. 30 is a schematic diagram showing the medication management unit server and the drug library editor deployed on separate computing machines according to one embodiment of the present invention.
- the medication management system (MMS) 10 of the present invention includes a medication management unit (MMU) 12 and a medical device 14 , typically operating in conjunction with one or more information systems or components of a hospital environment 16 .
- the term hospital environment should be construed broadly herein to mean any medical care facility, including but not limited to a hospital, treatment center, clinic, doctor's office, day surgery center, hospice, nursing home, and any of the above associated with a home care environment.
- the MMU 12 communicates to a hospital information system (HIS) 18 via a caching mechanism 20 that is part of the hospital environment 16 .
- HIS hospital information system
- the caching mechanism 20 is primarily a pass through device for facilitating communication with the HIS 18 and its functions can be eliminated or incorporated into the MMU 12 ( FIG. 1A ) and/or the medical device 14 and/or the HIS 18 and/or other information systems or components within the hospital environment 16 .
- the Caching Mechanism 20 provides temporary storage of hospital information data separate from the HIS 18 , the medication administration record system (MAR) 22 , pharmacy information system (PhIS) 24 , physician order entry (POE) 26 , and/or Lab System 28 .
- the Caching Mechanism 20 provides information storage accessible to the Medication Management System 10 to support scenarios where direct access to data within the hospital environment 16 is not available or not desired.
- the caching mechanism 20 provides continued flow of information in and out of the MMU 12 in instances where the HIS 18 down or the connectivity between the MMU 12 and the electronic network (not shown) is down.
- the caching mechanism 20 also provides improved response time to queries from the MMU 12 to the HIS 18 , as direct queries to the HIS 18 are not consistently processed at the same speed and often require a longer period of time for the HIS 18 to process.
- the HIS 18 communicates with a medication administration record system (MAR) 22 for maintaining medication records and a pharmacy information system (PhIS) 24 for delivering drug orders to the HIS.
- MAR medication administration record system
- PrIS pharmacy information system
- a physician/provider order entry (POE) device 26 permits a healthcare provider to deliver a medication order prescribed for a patient to the hospital information system directly or indirectly via the PhIS 24 .
- a medication order can be sent to the MMU 12 directly from the PhIS 24 or POE device 26 .
- the term medication order is defined as an order to administer something that has a physiological impact on a person or animal, including but not limited to liquid or gaseous fluids, drugs or medicines, liquid nutritional products and combinations thereof.
- Lab system 28 and monitoring device 30 also communicate with the MMU 12 to deliver updated patient-specific information to the MMU 12 .
- the lab system 28 sends lab results of blood work on a specific patient to the MMU 12
- the monitoring device 30 sends current and/or logged monitoring information such as heart rate to the MMU 12 .
- the MMU 12 communicates directly to the lab system 28 and monitoring device 30 .
- the MMU 12 can communicate to the lab system 28 and monitoring device 30 indirectly via the HIS 18 , the caching mechanism 20 , the medical device 14 or some other intermediary device or system. This real-time or near delivery time patient-specific information is useful in adapting patient therapy because it may not have been available at the time the medication order was prescribed.
- the term real-time denotes a response time with a latency of less than 3 seconds.
- the real-time digital communications between the MMU 12 and other interconnected devices and networks prevents errors in patient care before administration of medications to the patient, especially in the critical seconds just prior to the start of medication delivery.
- Delivery information input device 32 also communicates with the MMU 12 to assist in processing drug orders for delivery through the MMU 12 .
- the delivery information input device 32 can be any sort of data input means, including those adapted to read machine readable indicia such as barcode labels; for example a personal digital assistant (PDA) with a barcode scanner.
- PDA personal digital assistant
- the delivery information input device 32 will be referred to as input device 32 .
- the machine readable indicia may be in other known forms, such as radio frequency identification (RFID) tag, two-dimensional bar code, ID matrix, transmitted radio ID code, human biometric data such as fingerprints, etc. and the input device 32 adapted to “read” or recognize such indicia.
- RFID radio frequency identification
- the input device 32 is shown as a separate device from the medical device 14 ; alternatively, the input device 32 communicates directly with the medical device 14 or may be integrated wholly or in part with the medical device.
- the medication management unit 12 includes a network interface 34 for connecting the MMU 12 to multiple components of a hospital environment 16 , the medical device 14 , and any other desired device or network.
- a processing unit 36 is included in MMU 12 and performs various operations described in greater detail below.
- a display/input device 38 communicates with the processing unit 36 and allows the user to receive output from processing unit 36 and/or input information into the processing unit 36 .
- display/input device 38 may be provided as a separate display device and a separate input device.
- An electronic storage medium 40 communicates with the processing unit 36 and stores programming code and data necessary for the processing unit 36 to perform the functions of the MMU 12 . More specifically, the storage medium 40 stores multiple programs formed in accordance with the present invention for various functions of the MMU 12 including but not limited to the following programs: Maintain Drug Library 42 ; Download Drug Library 44 ; Process Drug Order 46 ; Maintain Expert Clinical Rules 48 ; Apply Expert Clinical Rules 50 ; Monitor Pumps 52 ; Monitor Lines 54 ; Generate Reports 56 ; View Data 58 ; Configure the MMS 60 ; and Monitor the MMS 62 .
- the Maintain Drug Library 42 program creates, updates, and deletes drug entries and establishes a current active drug library.
- the Download Drug Library 44 program updates medical devices 14 with the current drug library.
- the Process Drug Order 46 program processes the medication order for a patient, verifying that the point-of-care (POC) medication and delivery parameters match those ordered.
- the Maintain Expert Clinical Rules 48 program creates, updates, and deletes the rules that describe the hospital's therapy and protocol regimens.
- the Apply Expert Clinical Rules 50 program performs logic processing to ensure safety and considers other infusions or medication orders, patient demographics, and current patient conditions that include blood chemistry values such as insulin/glucose, monitored data such as pulse and respiration, and clinician assessments such as pain or responsiveness.
- the Monitor Pumps 52 program acquires ongoing updates of status, events, and alarms transmitted both real-time and in batch mode, as well as tracking the location, current assignment, and software versions such as the drug library version residing on medical device 14 .
- the Monitor Lines 54 program acquires ongoing updates of status, events and alarms for each channel or line for a medical device 14 that supports multiple drug delivery channels or lines.
- the Generate Reports 56 program provides a mechanism that allows the user to generate various reports of the data held in the MMU storage medium 40 .
- the View Data 58 program provides a mechanism that supports various display or view capabilities for users of the MMU 12 .
- the Notifications 59 program provides a mechanism for scheduling and delivery of events to external systems and users.
- the Configure the MMS 60 program provides a mechanism for system administrators to install and configure the MMS 10 .
- the Monitor the MMS 62 program enables information technology operations staff capabilities to see the current status of MMS 10 components and processing, and other aspects of day-to-day operations such as system start up, shut down, backup and restore.
- the various functional programs 42 - 62 of the MMU 12 are partitioned (at a higher level than shown in FIG. 2 ) and logically organized into interrelated managing units of the MMU 12 .
- the MMU 12 includes an asset manager 64 , an alarm manager 66 , a drug library manager (such as, for example, HOSPIRA MEDNETTM) 68 , a caregiver manager 70 , a therapy manager 72 , and/or a clinical data manager 73 .
- a drug library manager such as, for example, HOSPIRA MEDNETTM
- the MMU 12 includes a master adjudicator 74 between the separate interrelated hospital system managing units 64 - 73 of the MMU 12 , to regulate the interaction between the separate management units.
- the MMU 12 as described herein appears as a single device, there may be more than one MMU 12 operating harmoniously and sharing the same database.
- the MMU 12 can consist of a collection of MMU specific applications running on distinct servers in order to avoid a single point of failure, address availability requirements, and handle a high volume of requests.
- each individual server portion of the MMU 12 operates in conjunction with other server portions of the MMU 12 to redirect service requests to another server portion of the MMU 12 .
- the master adjudicator 74 assigns redirected service requests to another server portion of the MMU 12 , prioritizing each request and also ensuring that each request is processed.
- the managing units 64 - 72 each include separate features and rules to govern their operation.
- the asset manager 64 governs the execution of the Monitor Pumps 52 and Monitor Lines 54 programs
- the drug library manager 68 governs the execution of the Drug Library 42 and Download Drug Library 44 programs
- the therapy manager 72 governs the execution of the Process Drug Order 46 , Maintain Expert Clinical Rules 48 , and Apply Expert Clinical Rules 50 programs
- the clinical data manager 73 governs the execution of the Generate Reports 56 and View Data 58 programs.
- Other distribution of the functional MMU programs 42 - 62 among the hospital system managing units 64 - 73 can be made in accordance with the present invention.
- an electronic network 76 connects the MMU 12 , medical device 14 , HIS 18 , and input device 32 for electronic communication.
- the electronic network 76 can be a completely wireless network, a completely hard wired network, or some combination thereof.
- the medical device 14 and input device 32 are located in a treatment location 77 . As shown, the medical device 14 and input device 32 are equipped with antennas 78 and 80 , respectively.
- the antennae 78 and 80 provide for wireless communication to the electronic network 76 via an antenna 82 of access node 84 connected to the electronic network 76 .
- the term “medical device” includes without limitation a device that acts upon a cassette, reservoir, vial, syringe, or tubing to convey medication or fluid to or from a patient (for example, an enteral pump, infusion pump, a patient controlled analgesia (PCA) or pain management medication pump, or a suction pump), a monitor for monitoring patient vital signs or other parameters, or a diagnostic device.
- a patient for example, an enteral pump, infusion pump, a patient controlled analgesia (PCA) or pain management medication pump, or a suction pump
- PCA patient controlled analgesia
- suction pump a monitor for monitoring patient vital signs or other parameters
- the medical device 14 of FIG. 4 is disclosed as a cassette type infusion pump.
- the pump style medical device 14 includes a user interface means 86 , display 88 , first channel 90 , and first channel machine readable indicator 92 .
- a first IV line 98 has a conventional cassette 99 A (not shown) that is inserted into the first channel 90 , and includes a medication bag 100 with a machine readable indicator 102 .
- a second IV line 101 is connected to an input port of the cassette 99 A, and includes a medication bag 106 with a machine readable indicator 108 .
- a single output IV line 98 is connected to an outlet port of the cassette 99 A and connected to a patient 110 who has a machine readable indicator 112 on a wristband, ankle band, badge or similar article that includes patient-specific and or identifying information, including but not limited to patient ID, and demographics.
- the medical device 14 is a multi-channel pump having a first channel 90 with first channel machine readable indicator 92 and at least a second channel 94 with a second channel machine readable indicator 96 .
- the line 101 from the medication bag 106 is eliminated and replaced by line 104 with a cassette 99 B (not shown) inserted into the second channel 94 and an output line 104 extends from the cassette to the patient.
- the same type of cassette 99 (not shown) is inserted in the first channel 90 . Additional details on such a multi-channel pump and cassette 99 A can be found in commonly owned U.S.
- a caregiver 114 (if present) has a machine readable indicator 116 on a wristband, badge, or similar article and operates the input device 32 .
- the input device 32 includes an input means 118 for reading the machine readable indicators 92 , 96 , 102 , 108 , 112 , and 116 .
- An input/output device 120 is included on the input device 32 .
- the input/output device 120 allows the user to receive output from the input device 32 and/or input into the input device 32 .
- display/input device 120 may be provided as a separate display device and a separate input device.
- the pump style medical device 14 includes a network interface 122 for connecting the medical device 14 to the electronic network 76 .
- the network interface 122 operates the antenna 78 for wireless connection to the electronic network 76 .
- a processor 124 is included in the medical device 14 and performs various operations described in greater detail below.
- the input/output device 87 (display 88 and user interface means 86 ) allows the user to receive output from the medical device 14 and/or input information into the medical device 14 .
- input/output device 87 may be provided as a separate display device and a separate input device (as shown in FIG. 4 , display 88 and user interface means 86 ) or combined into a touch screen for both input and output.
- a memory 126 communicates with the processor 124 and stores code and data necessary for the processor 124 to perform the functions of the medical device 14 . More specifically, the memory 126 stores multiple programs formed in accordance with the present invention for various functions of the medical device 14 as is relates to the MMU 12 including the following programs: Process Drug Order 128 , Monitor Pump 130 , and Download Drug Library 132 .
- the input device 32 displays a default screen (not shown) on input/output device 120 which the caregiver uses to access password screen 133 B ( FIG. 7 ).
- the password screen 133 B prompts the caregiver 114 to enter caregiver specific identification information (caregiver ID).
- the caregiver 114 enters caregiver ID such as a username and/or password or pass code, or the machine readable indicator 116 .
- the input device 32 enters this caregiver ID at step 134 .
- the input device 32 then displays a scan patient screen 135 A ( FIG. 8 ) which prompts the caregiver 114 to enter patient-specific identification information (patient ID).
- patient ID patient-specific identification information
- the caregiver 114 enters the patient ID such as the machine readable indicator 112 .
- the input device 32 enters this patient ID and at step 136 , and displays a confirmed scan patient screen 135 B ( FIG. 9 ) indicating that the patient ID was successfully entered into the input device 32 .
- the input device 32 then transmits the patient ID to the caching mechanism 20 at step 138 .
- the caching mechanism 20 transmits the patient ID to the HIS 18 at step 140 .
- the HIS 18 retrieves a patient-specific task list and patient-specific order information based on the patient ID and transmits both to the caching mechanism 20 at step 142 .
- the order information includes but is not limited to an order detail for a medication order, patient demographic information, and other hospital information systems data such as lab results data.
- the caching mechanism 20 transmits the task list to the input device 32 at step 143 .
- the input device 32 then displays a task list screen 143 A ( FIG. 10 ) which prompts the caregiver 114 to access the task list on the input device 32 .
- the input device 32 prompts the caregiver 114 to enter drug specific identification information or drug ID from the container 100 .
- the caregiver 114 enters a drug ID such as the drug container specific machine-readable indicator 102 .
- the input device 32 enters this drug ID at step 144 .
- the input device 32 processes the drug ID to select the correct task from the task list, then displays a task screen 143 B ( FIG. 11 ), and transmits a request (dispense ID) based upon the entered drug ID to the caching mechanism 20 requesting an order ID at step 146 .
- the caching mechanism 20 transmits a request (dispense ID) to the HIS 18 requesting an order ID at step 148 .
- the order ID is simply a unique identifier for the medication order, lab test, or other task or procedure to be performed.
- the order ID can be a number, alphanumeric code, etc.
- the HIS 18 transmits an order ID to the caching mechanism 20 at step 150 .
- the caching mechanism 20 forwards this order ID to the input device 32 at step 152 .
- the input device 32 matches the order ID with an item in the task list to ensure a Five Rights check at step 154 .
- the “Five Rights” in this section refer to the “Five Rights of Medical Administration”.
- the Five Rights check is done at the MMU 12 once the MMU 12 receives the order information as well as the patient, dispense, and channel IDs. A description of these “rights” follows.
- Right patient is the drug being administered to the correct patient.
- Right drug is the correct drug being administered to the patient.
- Right dose is the correct dosage of the drug being administered to the patient.
- Right time is the drug being administered to the patient at the correct time.
- Right route is the drug being administered into the patient by the correct route, in this case intravenously through an IV.
- the input device 32 sends an order confirmed message to the caching mechanism 20 at step 156 .
- the caching mechanism 20 sends the order detail (medication order prescribed for a patient) of the order information to the input device 32 at step 158 .
- the input device 32 displays a scan device/channel screen 143 B ( FIG. 11 ) which prompts the caregiver 114 to enter channel identification information (channel ID) regarding which channels of the medical device 14 are to be used for the delivery.
- the caregiver 114 enters a channel ID such as the machine readable indicator 92 .
- the input device 32 enters this channel ID at step 160 , and displays a confirmed scan device screen 159 B ( FIG. 11B ) indicating that the channel ID was successfully entered into the input device 32 .
- the channel ID indicator 92 can include information also identifying the medical device 14 (medical device ID).
- an additional machine readable indicator may be provided for the medical device itself separate from the channel ID machine readable indicator 92 . If the medical device 14 has a single channel, a single indicator will clearly suffice. If the medical device 14 is a multi-channel device, the channel indicators can also carry information that uniquely identifies the device the channel is on. At any rate, it should be apparent that a second entry of a combined device/channel ID may be redundant and could be eliminated.
- the input device 32 then transmits the delivery information including caregiver ID, patient ID, medical device ID and/or channel ID, drug ID, and order ID to the MMU 12 at step 162 .
- the three entered IDs are entered in a different specific order or without regard to order.
- the IDs are entered without regard to order, the IDs would be maintained within the MMS 10 and/or caching mechanism 20 as they are entered, so that the IDs can be recalled when needed to complete the medication delivery workflow.
- the medical device 14 when the medical device 14 is turned on at step 164 the medical device 14 displays a start up screen 163 A ( FIG. 12 ) on the display 88 of the medical device 14 .
- the medical device 14 then displays a clinical care area selection screen 163 B ( FIG. 13 ) which prompts the caregiver 114 to select the clinical care area (CCA) that the medical device 14 is being assigned to.
- the caregiver 114 enters or selects the CCA at step 166 using scroll and select/enter keys on the user interface means 86 .
- the medical device 14 then displays a channel selection screen 163 C ( FIG.
- the medical device 14 that prompts the caregiver 114 to select the desired channel ( 90 or 94 ) or bag source ( 100 or 106 ) using soft keys 163 D-G, more particularly 163 E, 163 F respectively.
- the medical device 14 enters this channel ID at step 168 .
- the CCA information is transmitted to the MMU 12 by the medical device 14 at step 170 .
- the CCA can be automatically generated for the medical device 14 , and sent from the HIS 18 to the MMU 12
- the MMU 12 executes the Process Drug Order 46 program and sends an active order request based on the delivery information from the input device 32 to the caching mechanism 20 at step 172 .
- the caching mechanism 20 responds by sending the corresponding patient-specific order information to the MMU 12 at step 174 .
- the caching mechanism 20 may send to the MMU 12 order information regarding all information associated with the particular patient, including but not limited to order detail for a medication order, patient demographic information, and other hospital information systems data such as lab results data or monitoring data.
- the MMU 12 then executes the Apply Expert Clinical Rules 50 program to process the CCA information from the medical device 14 and the delivery information from the input device 32 , at step 178 .
- the Apply Expert Clinical Rules 50 program compares the delivery information with an expert rule set to determines expert rule set violations based on correlating treatment based protocols, disease based protocols, drug-drug incompatibility, patient data (age, height, weight, etc), vital signs, fluid in/out, blood chemistry, and status assessments (such as pain and cognition).
- drug-drug incompatibility includes but is not limited to determinations of drug-drug interactions and/or drug-drug compatibility between two or more medication orders for concurrent delivery (to the same patient at the same time) and/or in a time sequence for the same patient (i.e. through a common output IV line).
- the Apply Expert Clinical Rules 50 program finds an expert rule set violation (such as a drug-drug incompatibility)
- the Apply Expert Clinical Rules 50 program generates an alarm and/or requires a time delay in execution for one of the two separate delivery information submissions.
- the Apply Expert Clinical Rules 50 program also establishes a patient-specific rule algorithm.
- the patient-specific rule algorithm is primarily based on the expert rule set described above applied to a specific order detail.
- the patient-specific rule algorithm generates a patient-specific rule set (discussed in greater detail below, at the description of FIG. 20 ) according to patient-specific order information including but not limited to patient demographic information, and other hospital information systems data such as lab results data or monitoring data.
- the patient-specific rule set includes hard and soft dosage limits for each drug being administered.
- the patient-specific rule set is included in the delivery programming code sent to the medical device 14 at step 182 .
- any alarms generated by the Process Drug Order 46 or Apply Expert Clinical Rules 50 programs are delivered to the medical device 14 , HIS 18 , and/or input device 32 , computer 254 ( FIG. 17 ), at step 180 .
- Computer 254 can be located in a remote nurse station or a biomedical technician area.
- the MMU 12 transmits a delivery program code to the medical device 14 , at step 182 .
- the delivery program code sent from MMU 12 to the medical device 14 includes a patient-specific rule set generated from any rule based adjudication at the MMU 12 , including hard and soft dosage limits for each drug being administered.
- the medical device 14 caches the patient-specific rule set contained in the delivery program code.
- the MMU 12 can generate an alarm at the medical device 14 or another location and not download the delivery program code.
- the medical device 14 displays an order dose confirmation screen 187 A ( FIG. 15 ) which prompts the caregiver 114 to confirm the delivery data.
- the caregiver 114 selects the “yes” soft key 187 B on the medical device 14 to confirm the delivery data and the no soft key 187 C to cancel the delivery.
- the caregiver 114 confirms the delivery data at the medical device 14 at step 188 .
- the medical device 14 executes the delivery program code and begins infusion at step 198 . As part of the program code, the infusion may be delayed for a predetermined period of time.
- confirmation from the caregiver can be made at the input device 32 or required from both the input device 32 and medical device 14 .
- a redundant additional confirmation performed by the caregiver 114 at the input device 32 after the medical device has received the delivery program code.
- the medical device 14 transmits a canonical representation of the delivery programming code data (delivery data) to the MMU 12 detailing the infusion to be performed by the medical device 14 , at step 184 .
- the MMU 12 then transmits the same delivery data that was originally transmitted to the medical device 14 to the input device 32 at step 186 .
- the delivery data can be passed to another remote computer ( 254 in FIG. 17 ), including but not limited to a computer at a nurse station, for confirmation.
- the input device 32 displays an order dose confirmation screen 191 A ( FIG. 16 ) that prompts the caregiver 114 to confirm the delivery data.
- the caregiver 114 selects the complete button 191 B on the input device 32 to confirm the delivery data and the cancel button 191 C to cancel the delivery.
- the caregiver 114 confirms the delivery data at the input device 32 at step 192 , and the confirmation is used for documentation by the HIS 18 , or other systems within the hospital environment 16 .
- the medical device 14 executes its Process Drug Order 128 program.
- the Process Drug Order 128 program sends infusion change events and infusion time events in a delivery event log message 200 to the MMU 12 .
- the MMU 12 forwards these delivery event log messages to the input device 32 or other system within the hospital environment 16 at step 202 .
- the caregiver 114 acknowledges these delivery event log messages on the input device 32 , at step 204 .
- the input device 32 then sends an acknowledged delivery event log message 206 to the caching mechanism 20 , detailing the delivery event, the caregiver ID, and the caregiver acknowledgment.
- the caching mechanism passes the delivery event message to the HIS 18 at step 208 .
- the medical device 14 sends an infusion ended message 212 to the MMU 12 .
- the MMU 12 then aggregates all the delivery event messages 200 sent during the infusion at step 214 .
- the MMU 12 sends the aggregated delivery events 216 to the input device 32 .
- the caregiver 114 enters a completed task 218 on the input device 32 , and sends the aggregated delivery events to the caching mechanism at step 220 , which in turn passes the delivery event log messages to the HIS 18 at step 222 .
- FIGS. 6 and 6A an alternative flow chart of the MMS 10 processing a drug order through the MMU 12 and medical device 14 is shown.
- the caregiver 114 enters the patient ID, which then is stored in the caching mechanism 20 .
- the caching mechanism 20 transmits the patient ID to the HIS 18 and retrieves a patient-specific task list for that patient ID.
- the caregiver 114 then enters the drug ID from the indicator 102 of the container 100 that may be translated into a dispense ID, which subsequently is stored in the caching mechanism 20 .
- the caching mechanism 20 transmits the drug ID or dispense ID to the HIS 18 , and retrieves a patient-specific order information, including but not limited to an order detail, patient demographic information, and other hospital information systems data such as lab results data.
- the caregiver 114 then enters the channel ID, which is stored in the MMU 12 .
- the three entered IDs are entered in a different specific order or without regard to order.
- the IDs are entered without regard to order, the IDs would be maintained within the MMS 10 and or caching mechanism 20 as they are entered, so that the IDs can be recalled when needed to complete the medication delivery workflow.
- the MMU 12 Upon receipt of the channel ID, the MMU 12 requests the order information (order detail, patient demographic information, and other hospital information systems data) and retrieves it from the caching mechanism 20 . This order information is stored within the MMU 12 and utilized for subsequent rule processing such as “Five Rights” checking and other rule set algorithms.
- the Process Drug Order 46 program processes the delivery information from the input device 32 (including caregiver ID, patient ID, medical device/channel ID, and drug ID or dispense ID) and compares this delivery information with the corresponding order detail portion of the order information from the caching mechanism 20 , at step 176 . Where the order information and delivery information do not match, the device program code downloaded to the medical device 14 at step 182 includes an alarm message indicating that the five rights check was not met. Additionally, the alarm message can include a description of which particular right(s) did not match. Alternatively, the NMU 12 can generate an alarm at the medical device 14 or another location and not download the program code for delivery of the medication order.
- the MMU 12 can accept a Five Rights check from another device, such as a HIS 18 or an input device 32 .
- This check can be accepted either by a direct data element being sent to the MMU 12 indicating a Five Rights check, or implied through the workflow provided by the HIS 18 or input device 32 .
- FIGS. 6 and 6A are similar to corresponding steps in FIGS. 5 and 5A . Accordingly, these steps will not be described with any further detail here.
- the vertical lines in FIGS. 5 , 5 A, 6 , 6 A do not necessarily represent a firm time sequence. Some steps may be done sooner than shown (for example, turning on the medical device) or later than shown (for example, aggregate delivery events).
- the Process Drug Order 46 program of the MMU 12 and the corresponding Process Drug Order 128 program of the medical device 14 permit the MMU 12 to remotely control the medical device 14 to modulate performance of a medication order.
- the MMU 12 can remotely start and/or stop the medical device 14 .
- the Process Drug Order 46 of MMU 12 remotely starts execution of the infusion by sending a start order 224 , which triggers the medical device to begin infusion at step 225 .
- the Process Drug Order 46 program can remotely stop the infusion by sending a stop order 226 to the medical device 14 , which triggers the medical device to end infusion at step 228 .
- the MMU 12 requires the caregiver to confirm the start or stop of execution. This confirmation by the caregiver may take place at the input device 32 or the medical device 14 .
- the Apply Expert Clinical Rules 50 program of the MMU 12 permits the MMU 12 to adjust a previously fixed patient-specific rule set based on new patient conditions and/or recent lab results, and notify the caregiver that adjustment is recommended by the MMU 12 .
- the Apply Expert Clinical Rules 50 program establishes a patient-specific rule algorithm.
- the patient-specific rule algorithm is primarily based on the expert rule set described above applied to a specific order detail.
- the patient-specific rule algorithm generates a patient-specific rule set according to patient-specific order information including but not limited to patient demographic information, and other hospital information systems data such as lab results data or monitoring data.
- the patient-specific rule set includes hard and soft dosage limits for each drug being administered, and these hard and soft dosage limits likewise are adjusted when the patient-specific rule set is adjusted.
- the MMU 12 may receive updated patient information that can impact an ongoing or impending infusion.
- the lab 28 sends updated patient-specific lab results to the MMU 12 at step 230 .
- the monitoring device 30 sends updated patient-specific monitoring information to the MMU 12 at step 232 .
- the MMU 12 queries the HIS 18 for patient information including: Patient Allergies, Patient Diet, and Current Patient Medical Orders. Patient Allergies are used to check for drug-allergy interactions, at step 231 . Patient Diet information is used to check for drug-food interactions. Current Patient Medical Orders are used to check for drug-drug incompatibility.
- the patient information from HIS 18 is also used by the MMU 12 to update the delivery program order.
- the MMU 12 executes the Apply Expert Clinical Rules 50 program at step 178 to establish a patient-specific rule set based on updated patient information received or retrieved from the lab 28 , the monitoring device 30 , and or the HIS 18 ( FIG. 20 ).
- This real-time or near delivery time updated patient-specific information is useful in adapting patient therapy because it may not have been available at the time the medication order was prescribed.
- the MMU 12 also modifies the existing patient-specific rule set in the existing delivery program code at step 234 based on updated patient information received or retrieved from the lab 28 , the monitoring device 30 , and or the HIS 18 .
- the MMU 12 optionally alerts the input device 32 and/or the medical device 14 of changes to the patient-specific rule set.
- MMU 12 also optionally generates an alert message if the delivery programming code violates any parameter of the adjusted hard and soft dosage limits.
- the MMU 12 optionally requests confirmation by the caregiver prior to instituting the new patient-specific rule set.
- the MMU 12 then delivers an updated delivery program code to the medical device 14 for execution at step 236 .
- the medical device 14 then executes this updated delivery program code as step 238 .
- the updated delivery program code sent from MMU 12 to the medical device 14 includes an updated patient-specific rule set generated from any rule based adjudication at the MMU 12 , including hard and soft dosage limits for each drug being administered.
- the medical device 14 caches the updated patient-specific rule set contained in the delivery program code. Additionally, the MMU 12 collects, stores, and reports the changes to the patient-specific rule set, changes to the hard and soft limits, as well as the history of each medication order.
- the hospital may establish expert rules or clinical decision support rules in the MMU 12 that will be applied automatically to incoming prescribed orders, such that the physician may simply write an order for 1000 or 1200 units/hour.
- the hospital best practices formulated by the appropriate medical personnel are established in the MMU 12 and can dictate that all heparin orders are to be conditioned on the APTT lab result and such an expert rule or clinical decision support rule will be used by the MMU 12 to govern the operation of the medical device 14 .
- the MMU 12 also can check the most recent patient data and provide an alarm and/or temporarily modify the delivery order prior to the start of the infusion if the prescribed order is no longer appropriate given the expert rules or clinical decision support rules and the latest lab results or monitored patient conditions. It should be apparent that this kind of intervention by the MMU 12 during or immediately prior to an infusion is particularly useful in preventing adverse consequences for the patient and the hospital.
- the MMU 12 adjusts a previously fixed patient-specific rule set based on new patient conditions and/or recent lab results, as described above, the MMU 12 provides dynamic advanced reports of real-time rule set changes in relation to changes in the condition of the patient (an “information cascade”). These advanced reports detail the history of both hard and soft upper and lower limits, as well as the activation of overrides and confirmations based on these limits for each medical device 14 managed by the MMU 12 . Further details on this feature can be found in commonly owned co-pending application entitled SYSTEM FOR MAINTAINING DRUG INFORMATION AND COMMUNICATING WITH MEDICATION DELIVERY DEVICES filed on Feb. 20, 2004, which is expressly incorporated herein in its entirety.
- the Download Drug Library 44 program in the MMU 12 and the corresponding Download Drug Library 132 program in the medical device 14 operate to send a drug library to the medical device 14 from the MMU 12 .
- the drug library includes drug and device related information, which may include but is not limited to drug name, drug class, drug concentration, drug amount, drug units, diluent amount, diluent units, dosing units, delivery dose or rate, medication parameters or limits, device/infuser settings and/or modes, CCA designations and constraints, and library version.
- the Download Drug Library 132 program is designed to cache in a cache memory 126 A a new database or drug library at medical device 14 while maintaining an existing older version database or drug library in its primary memory 126 .
- the medical device can operate or deliver an infusion based on the older version of the drug library without disruption until a trigger event occurs, at which time the new drug library replaces the older version in the primary memory 126 . It is contemplated that the medical device 14 can be equipped with an initial drug library at the factory.
- the Download Drug Library 132 program in the medical device 14 begins at a block 240 and at block 242 a determination is made that a drug library update needed event has occurred.
- the drug library update needed event could be a completed infusion, a stopped infusion, elapsed time, a specific date and time, creation of the new drug library, the medical device 14 being or entering into a particular configurable mode such as stop, “sleep” or “wakeup”, connection of the medical device 14 to an access node 84 in a new CCA, a download of a new or modified drug library to the medication management unit, or a determination that the existing drug library at the medical device needs updating.
- the configurable mode could be any number of device modes including a power-on sleeping mode and a power-off mode.
- the determination that a drug library update needed event has occurred can be made by (at) the MMU 12 , the medical device 14 or by a combination of the two.
- the Download Drug Library 132 proceeds to block 244 where it retrieves or receives a new drug library. Once retrieved or received, the Download Drug Library 132 proceeds to block 246 where it stores the new drug library in the cache memory 126 A of the medical device 14 . While a medical device 14 is operating on a patient or in an otherwise nonconfigurable mode, information such as a new drug library or database is stored in a cache memory 126 A of the medical device 14 as the information is received from a wired or wireless link through the network interface 122 . The Download Drug Library 132 proceeds to block 248 where it determines if a specific trigger event has occurred.
- the trigger event could be a completed infusion, a stopped infusion, a determination that the device is in a configurable mode, elapsed time, a specific date and time, creation of the new drug library, a download of a new or modified drug library to the medication management unit, and a determination that the existing drug library at the medical device needs updating.
- the configurable mode could be any number of device modes including a power-on sleeping mode and a power-off mode.
- the determination that a trigger event has occurred can be made by (at) the MMU 12 , the medical device 14 or by a combination of the two.
- the Download Drug Library 132 then proceeds to block 250 where it deletes the existing drug library in primary memory 126 and installs the new drug library, and the new drug library from cache memory 126 A will replace the older information in the memory 126 of the medical device 14 .
- the Download Drug Library 132 process is then complete and ends in block 252 .
- Additional related features of the Download Drug Library 44 program in the MMU 12 and the corresponding Download Drug Library 132 program include recording the history of the download, verify the correct download, notification to the caregiver of a change of library, and a preliminary note on the medical device 14 display stating that the drug library will be changed after any current infusion (i.e., before the next infusion).
- the MMU 12 is supplied with a drug database that allows a user to update a single data item (row, column, or cell) in the database without re-writing the entire database. This provides faster processing and downloading times when modifying the drug database.
- the Download Drug Library 44 program in the MMU 12 is designed to modify a medication library from the HIS 18 in such a way that only a single configuration of a single drug library is necessary to provide download information to multiple separate and different medical devices 14 where each device has unique parameters (different models, processors, computer architecture, software, binary format, or manufacturers, for example).
- the configured drug library is designed so that only a subset of the configured drug library is specific for each unique type of medical device 14 , and only the specific information is selected for transfer to each medical device 14 .
- pre-validation of the configured drug library is done through use of a rule set editor prior to sending from the MMU 12 to the medical device 14 , and post-validation occurs where the medical device 14 confirms receipt of an acceptable drug library back to the MMU 12 .
- the Monitor Pump 44 program in the MMU 12 and the corresponding Monitor Pump 130 program in the medical device 14 operate to map the approximate or general physical location of each medical device 14 within the hospital environment and to enable a user to trigger a locator alarm to locate a particular medical device 14 . Additionally, the programming enabling the medical device locator would be located in an asset manager 64 portion of the MMU 12 .
- the MMU 12 communicates with one or more (more preferably a plurality of) medical devices 14 A, 14 B, and 14 C through the electronic network 76 .
- the medical device or devices 14 A, 14 B, and 14 C connect to the electronic network 76 through one or more (more preferably a plurality of) access nodes 84 A, 84 B, and 84 C distributed in one or more (more preferably a plurality of) CCAs 253 A and 253 B.
- More than one medical device 14 can operate from an individual access node 84 and be associated with a particular patient.
- a user access device such as a computer system 254 is remotely located from the MMU 12 and the medical device 14 and communicates with the MMU 12 to permit a user 256 to activate the Monitor Pump 44 program in the MMU 12 and remotely activate the corresponding Monitor Pump 130 program in the medical device 14 .
- the computer 254 can be located in a variety of locations, including but not limited to a nurse station or a biomedical technician area.
- the functional steps of the Monitor Pump 52 program in the MMU 12 and the corresponding Monitor Pump 130 program in the medical device 14 A are shown in operation with the computer 254 .
- the user 256 enters a query for the location of a medical device 14 A.
- the computer 254 sends a request device location 258 message to the MMU 12 .
- the MMU 12 in turn sends a request last used access node 260 message to the medical device 14 A.
- the Monitor Pump Program 130 can be operated with the input device 32 .
- the medical device 14 A determines the last access node 84 A- 84 C used to connect with the electronic network 76 at step 262 .
- a report of the last used access node 264 is sent from the medical device 14 to the MMU 12 .
- the MMU 12 processes the report of the last used access node 264 to determine the general physical location of the device at step 266 .
- a report physical location 268 message is sent from the MMU 12 to the computer 254 .
- the MMU 12 tracks “change of infuser access node” events, when a medical device 14 begins to communicate through a different network access node 84 .
- the MMU 12 communicates the physical locations of medical devices 14 to the HIS 18 .
- the user 256 can instruct the computer 254 to send a request audio location alarm 270 message to the MMU 12 .
- the MMU 12 in turn sends an order audio locator alarm 272 message to the medical device 14 A.
- the medical device 14 A then activates an audio alarm at step 274 to assist the user 256 in locating the medical device 14 A.
- the audio alarm activation can be delayed by a predetermined time to allow the user time to travel to the area of the last used access node.
- the audio alarm feature is useful in allowing the user to more precisely pinpoint the location of the medical device 14 .
- the audio alarm feature is particularly useful if the medical device 14 is very close to other medical devices or has been moved to a storage closet or other location where it is not readily apparent visually.
- the functional steps of the Monitor Pump 44 program in the MMU 12 and the corresponding the Monitor Pump 130 program shown in FIG. 18 can be performed as a series of “push” steps instead of a series of “pull” steps (as shown in FIG. 18 ).
- the medical device 14 A periodically determines the last used access node and periodically reports the last used access node to the MMU 12 as a “here I am” signal.
- the MMU 12 periodically determines the physical location of the medical device 14 A based on the last access node 84 A used by the medical device 14 , and periodically reports the physical location of the medical device 14 A to the user access device 254 .
- the MMU 12 programming allows it to determine which of access nodes 84 was the last access node used by the device 14 (step 259 indicated by a dashed line) and the MMU can report the general physical location of the medical device 14 to the computer 254 without requesting a report from the medical device 14 .
- the association between medical devices 14 , patient 110 , drug 100 , and caregiver 114 is accomplished by swiping machine readable indicators on each of these elements of the PAN 113 (See FIG. 4 ). This association is made in software residing the MMU 12 . Alternatively, the association is made in software residing in the medical device 14 . With reference to FIG. 21 , in another embodiment, the association between medical devices 14 A, patient 110 , drug 100 , and caregiver 114 , is accomplished by “auto-association”. Auto-association is desirable in situations where the patient's wrist is not readily accessible (e.g. during surgery, or a neonate in an incubator).
- the MMU 12 and medical device 14 A are designed to establish the patient as the focus of the MMS 10 .
- the patient 110 is equipped with a machine readable indicator 112 A on a wristband, toe tag, badge or similar article.
- the machine readable indicator 112 A contains transmitter/receiver chip 278 , capable of short-range transmission.
- the transmitter/receiver chip 278 is a low power RF BluetoothTM, a dedicated RF transmitter working with a PIC processor, or any other suitable transmitter/receiver.
- the patient 110 is fitted with the machine readable indicator 112 A at the time of admission.
- the unique ID number of the particular machine readable indicator 112 A is stored with an electronic patient record at the HIS 18 and hence MMU 12 .
- the MMU 12 is thereby notified of the particular machine readable indicator 112 A associated with the particular patient 110 .
- any other machine readable indicator used with the present invention may also contains transmitter/receiver chip capable of short-range transmission.
- the caregiver machine readable indicator 116 and medication machine readable indicator 102 may also be equipped with a transmitter/receiver chip.
- Each medical device 14 A is also equipped with a transmitter/receiver chip 280 A.
- the transmitter/receiver chip 280 A of the medical device 14 A “pings” by sending out a “request for patient” command to any transmitter/receiver chip 278 that is in the area.
- Each transmitter/receiver chip 278 which is in the area (usually about 0-10 meters, more preferably about 0-3 meters), replies to the ping by sending the transmitter/receiver chip 280 of the medical device 14 A the unique ID number of the particular machine readable indicator 112 A.
- the medical device 14 A Upon receipt of a signal from the machine readable indicator 112 A, the medical device 14 A places the ID number of the machine readable indicator 112 A in memory 126 (See FIG. 4A ) and also transmits the same to the MMU 12 .
- the unique ID of the indicator 112 A can be transmitted directly to an MMU 12 located in the area or indirectly through another route, including but not limited to the medical device 14 .
- the MMU 12 Process Drug Order 46 program then checks the patient ID entered at step 162 and the device/channel ID entered at step 160 to ensure the correct match.
- the MMU 12 associates the medical device 14 A only to the identified patient based on the patient ID number sent to the MMU 12 . Dissociating the medical device 14 A from the patient is done based on a command from a user, or other method.
- machine readable indicator 112 A (as well as the machine readable indicator 112 ), can include equipment for monitoring the wearer, and transmitting this monitored information to the medical device 14 and/or the MMU 12 .
- placing a second medical device 14 B within the PAN 113 leads to a repeat of the same process.
- the first medical device 14 A “pings” any transmitter/receiver chip that is in the area.
- the transmitter/receiver chip 280 B of the second medical device 14 B replies to the ping by sending the transmitter/receiver chip 280 A of the first medical device 14 A the unique ID number of the particular machine readable indicator 92 B.
- the first medical device 14 A places the ID number of the machine readable indicator 92 B in memory 126 (See FIG. 4A ) and also transmits the same to the MMU 12 .
- the patient ID number is then sent from the first medical device 14 A to the second medical device 14 B.
- An additional or alternative validation of the “right patient” can be accomplished by caregiver visual confirmation of the patient following the auto-association procedure described above in relation to FIG. 21 , and is also applicable to the five-rights procedures described above with respect to FIGS. 5 , 5 A, 6 and 6 A.
- the patient 110 is photographed with a digital camera (not shown) at the time of admission and the digital photo is stored with the electronic patient record at the HIS 18 .
- the digital photo is sent to the MMU 12 and upon completion of the association process, the digital photo is transmitted from MMU 12 to the medical device 14 at the patient 110 bedside.
- the image of the patient 110 is sent to the display 88 of the medical device 14 , which is preferably a high resolution touch screen at least approximately 12 cm by 12 cm.
- the image of the patient 110 is then placed on the display 88 and the caregiver 114 is prompted by the display 88 to “Confirm Patient”.
- the caregiver 114 confirms a patient match upon visual comparison of the patient 110 with the image on the display 88 .
- the digital photo information alternatively can be stored on the indicator 112 or 112 A and transmitted by the transmitter/receiver 178 thereof.
- the digital photo is transmitted to the medical device 14 when the medical device 14 has been associated with the patient 110 .
- FIG. 22 another portion of the functional steps of the Monitor Pump 52 program in the MMU 12 and the corresponding Monitor Pump 130 program in the medical device 14 are shown in operation with the computer 254 .
- the user 256 enters a query for the operation evaluation of a medical device 14 .
- the computer 254 sends an operation evaluation request 282 message to the MMU 12 .
- the MMU 12 in turn sends a request operation data 284 message to the medical device 14 .
- the medical device 14 sends a report operation data 286 message (including but not limited to event logs, settings, CCA and utilization information) back to the MMU 12 at step 286 .
- the MMU 12 processes the report operation data 286 to generate an operational evaluation at step 288 .
- a report operational evaluation 290 message is sent from the MMU 12 to the computer 254 .
- the functional steps of the Monitor Pump 44 program in the MMU 12 and the corresponding the Monitor Pump 130 program shown in FIG. 22 can be performed as a series of “push” steps instead of a series of “pull” steps (as shown in FIG. 22 ).
- the medical device 14 periodically reports the operation data to the MMU 12 .
- the MMU 12 periodically processes the report operation data 286 to generate an operational evaluation at step 288 , and periodically reports the operational evaluation of the medical device 14 to the user access device 254 at step 290 .
- the automated operational evaluation described above provides a method of evaluating medical device 14 while in operation; thus eliminating the need to postpone evaluation until the medical device 14 is taken out of use.
- the real-time data collection capabilities of the MMU 12 and Monitor Pump 52 program allow the MMU 12 to determine medical device 14 performance including advanced statistical operations in order to provide quality control data sorting algorithms and aggregation of data and control for a PAN 113 (not shown). For example, consider a MMS 10 where multiple discreet single or multiple channel medical devices 14 (or channels) are connected to a single patient 110 (not shown).
- the Monitor Pump 52 program collects all medical device 14 information in real-time and then compares medical device 14 statistics to one another.
- infuser channels can be compared to other infuser channels within the same multiple channel medical device or in other devices.
- Monitor Pump 52 program therefore can detect a “bad actor” if any one of the medical devices 14 or channels is operating at a level statistically lower or higher than the other medical devices 14 or channels.
- This statistical determination can be made by collecting and comparing the mean and standard deviation of appropriate data elements.
- This statistical determination can be performed selectably on any of the data that is routinely collected by the medical device 14 event log and any that may be acquired from the instrumentation of the medical device 14 . For example, statistical determinations could be performed based on air alarm events, occlusion alarm events, battery usage data, screen response time, etc.
- MMU 12 then sends the operational evaluation message (including any relevant quality control alert) to an appropriate area (including but not limited to the computer 254 ) in a form that is appropriate for the particular alert (usually including but not limited to graphically or audibly). Additionally, operational evaluation message (including any relevant quality control alert) can be sent to any number of individuals including but not limited to the caregiver, a biomedical engineer, caregiver supervisor, and a doctor.
- the medical device 14 is designed as a multi-processor, where many features are not hardwired, but instead can be uniquely configured based on rules, the location of the medical device 14 , etc.
- the medical device 14 is designed to allow a customized display based on the Clinical Care Area (CCA) 253 A or 253 B the medical device 14 is located in and/or assigned too.
- CCA Clinical Care Area
- An example of this would be the MMU 12 instructing the medical device 14 to have a display of a particular color or warning tones/volumes based on the location of the medical device 14 in the hospital, time of day, caregiver information, patient information, or the type of medication being supplied.
- the patient information could include a patient diagnosis and/or a disease state.
- alarm volumes and display brightness can be set lower in the pediatric clinical care area or at night than in the emergency room clinical care area or during the daytime.
- the medical device 14 is designed to allow a customized display based on user information supplied to the medical device 14 (from the MMU 12 for example).
- user based customized display could include changes in language preference, limited access depending on the security level of the caregiver 114 , customizing the displayed information based on the training level of the individual or recent interactions therewith, and/or customizing an automated help function based on training level of the user or recent interactions therewith.
- the MMU 12 presents a user with a default view based on the user's role.
- the MMU 12 permits a default view for each role to be configurable in terms of the data detail presented.
- the MMU 12 allows a user with the appropriate privilege to set a particular presented view as the preferred or default starting view for that user following login.
- the MMU 12 allows a user to access databases and details based on role and privilege.
- the MMU 12 allows a user to access other views based on role and privilege.
- Each presented view includes: a common means of navigating among views, both summary and detail, access to privacy, security, and other policy statements, access to online help, and a logoff capability. Additionally, an emergency bypass (such as a pass-code) would be provided to bypass security restrictions in case of an emergency.
- the MMU 12 tracks and records actions taken by the caregiver 114 based on operational data reported from one or more medical devices 14 .
- the MMU 12 can likewise generating an operational evaluation of each caregiver 114 (not shown) at step 288 .
- This operational evaluation of each caregiver 114 includes records of each caregiver's 114 actions (or, in some cases, inactions), sorting of these actions based on given criteria, and tracking of any trends in these actions.
- these records of actions include any task lists, medication administration records, treatments, and other actions associated with the caregiver's 114 responsibilities. Such records of actions may combine medications administered, treatments, and other actions for multiple patients under the care of an individual caregiver.
- MMU 12 then sends the operational evaluation message (including any relevant quality control alert) to an appropriate area (e.g. to the computer 254 or caregiver supervisor's computer (not shown)) in a form that is appropriate for the particular alert (usually including but not limited to graphically or audibly).
- operational evaluation message can be sent to any number of individuals including but not limited to the caregiver, a biomedical engineer, caregiver supervisor, and a doctor.
- the MMU 12 can instruct the medical device 14 to customized display 88 based on the operational evaluation message.
- the display 88 is adjusted by the MMU 12 based a determination that the caregiver 114 requires additional or different information displayed to improve caregiver 114 interaction with the medical device 14 .
- detailed step by step instructions can be placed on display 88 , where the MMU 12 recognizes a caregiver 114 who is not familiar with a particular therapy, using the display 88 as the instruction means.
- the MMU 12 instructs the medical device 14 to display pertinent training information.
- the medical device 14 is designed to act as a web server for the input device 32 or other similar devices within proximity to the medical device 14 .
- medical device 14 is equipped to supply the input device 32 web browser (client) with medical device related information as well as non-medical device related information such as task lists, etc.
- client web browser
- the medical device 14 displays a dual function screen having both a pump monitor screen portion and a web browser screen portion. Further, supplying the medical device 14 as a web server permits a remote web browser to associate with the medical device 14 to configure the medical device 14 or run diagnostics on the medical device 14 .
- FIGS. 2 and 4A another portion of the Monitor Pump 52 program in the MMU 12 and the corresponding Monitor Pump 130 program in the medical device 14 is directed to cloning between medical devices 14 .
- the medical devices 14 are designed to have wireless data sharing between each medical device 14 sufficient to permit cloning of all patient information between each medical device 14 , and/or the multi-sequencing of a set of medical devices 14 without a hardwired connection.
- the MMU 12 adjudicates this cloning and/or multi-sequencing.
- FIGS. 23-30 assist in illustrating another set of embodiments of the invention.
- the patient link 20 is eliminated from the system in this set of embodiments and an input device 32 , including but not limited to a point-of-care (POC) device such as a personal digital assistant (PDA) equipped with a scanner or machine label reader, connects or communicates with the HIS 18 and the MMU 12 of the MMS 10 .
- POC point-of-care
- PDA personal digital assistant
- another input means 26 or device such as a POE (physician order entry) computer connects and communicates with the HIS 18 in order to allow a physician to deliver a medication order prescribed for a particular patient.
- POE chemical order entry
- the medication order is generally routed through the pharmacy and the pharmacy information system or PhIS 24 so that the medication can be physically prepared and, if necessary, repackaged, reconstituted, and labeled with identification for delivery.
- the medication order typically includes instructions regarding the drug (drug name, concentration, and amount such as volume, quantity, or mass), the patient, the route of administration, and the prescribed time(s) of administration or execution.
- the MMU 12 includes a processing unit 36 and at least one input/output device 38 as discussed above.
- one input/output device 38 is provided for monitoring the MMU 12 and medical devices 14 (pumps or infusers and lines or channels thereof, for example) connected to the MMU, entering clinical or expert decision rules, entering or editing data to configure the MMU 12 , running various programs thereon, and extracting reports.
- the processing unit 36 is a computer server and a separate MMU console 38 connects or communicates with it.
- the MMU console 38 is physically located in a biomedical engineering area, although other locations including but not limited to a nursing station, security desk, administrative area, or physician's desk would be possible.
- Another input/output device 38 A in the form of a drug library editor (DLE) console connects or communicates with the processing unit 36 to enter, edit, import and export data relating to the drug library.
- DLE console 38 A is physically located in the pharmacy under the control of a licensed pharmacist.
- a standard personal or laptop computer can function as both the processing unit 36 and one or more of the input/output devices 38 , 38 A.
- the input/output devices 38 , 38 A can also be provided as separate input and output devices.
- FIGS. 2 , 4 , 4 A, 25 and 26 illustrate basic components of the system, depict the flow of certain data within the system, and depict the steps for automatically programming and monitoring the medical device 14 , an infuser or multi-channel pump in this example.
- the entry of the prescribed drug order into the HIS 18 by the physician causes a medication container 100 to be selected or prepared by a pharmacist in the pharmacy using information from the PhIS 24 and the HIS 18 .
- Many modern drug containers come from the manufacturer pre-filled and now include machine-readable labels with drug identification information thereon.
- the pharmacist provides drug identification information on a PhIS computer generated machine-readable label for attachment to the container.
- drug identification information includes the drug name, concentration, and amount in volume or mass.
- the manufacturer or pharmacist may supplement this basic label information with additional information including manufacturer name, expiration date, production lot, patient identification, and other information in a format readable by a machine or a human as required by the health care facility, government agencies or industry practice.
- the container 100 with its label 102 is provided to the caregiver 114 or placed in an appropriate storage area for later administration to the patient.
- the caregiver 114 enters caregiver specific identification (caregiver ID) with the input device 32 , for example by scanning the machine-readable indicator 116 on their badge or similar article at step 300 , to verify that the caregiver 114 is an authorized user.
- the input device 32 gets from the HIS 18 a list of task or orders the caregiver 114 is authorized and scheduled to perform on various patients. This task list is presented on the screen of the input device or PDA 32 .
- the caregiver 114 enters the patient-specific identification information by using the input device 32 to enter, read or scan the machine-readable indicator 112 associated with the patient 110 .
- the input device 32 gets, displays, selects, or highlights a list of orders or tasks associated with the specific patient 110 scanned.
- the caregiver 114 uses the input device 32 to scan the label 102 on the drug container 100 , which triggers the input device to select, highlight or display a specific order or task on its display screen.
- the input device 32 uses the drug ID to get the details of the specific order from the HIS 18 .
- the caregiver 114 uses the input device 32 to enter, scan or read the machine-readable channel/infuser ID indicator 92 , 96 on the channel 90 , 94 of the medical device 14 to be used to dispense the order. If the appropriate channel/infuser has been selected and scanned, the input device 32 submits the delivery order to the MMU 12 at step 314 . Alternatively, the HIS 18 can submit the order directly to the MMU 12 , preferably after confirmation by the caregiver 114 at the PDA 32 . At any rate, prior to submission of the medication delivery order to the MMU 12 and the medical device 14 , up to seven “rights” of medication management have been matched, verified, or validated as correct. The right caregiver will be administering the right drug to the right patient at the right time, in the right dosage, through the right route/device, and through the right device channel.
- the pre-submission steps 300 - 312 can be done in any order necessary to conform to hospital practices and desired workflow.
- the caregiver 114 can scan the drug container label 102 (step 308 ) before scanning the patient ID 112 (step 304 ).
- Step 304 which includes entering the patient ID 112 , may be done prior to the step 300 of entering the caregiver ID 116 . In that case, for security and patient privacy purposes, the system would delay the display of the order list for the patient until after the caregiver's authorization has been verified.
- the HIS 18 is the most efficient place to perform the above date comparisons, one skilled in the art will recognize that the necessary comparisons between the scanned caregiver, patient, drug and device specific delivery information and the originally entered infusion order may take place at the PDA 32 , the MMU 12 , the HIS 18 or some combination thereof.
- the MMU 12 translates the order at step 316 into a format that the medical device 14 can recognize. Then the MMU 12 submits the order to the medical device 14 at step 318 .
- the medical device 14 confirms the order with the MMU.
- the pump can automatically confirm the order or, more preferably, a caregiver can verify and confirm the order at the pump.
- the medical device 14 communicates the status of the infusion to the MMU 12 in real-time or at periodic intervals in step 322 . As desired by the caregiver or other authorized users, the input device or PDA 32 can poll the MMU 12 for the status of the infusion at step 324 .
- the MMU 12 can respond to this request, polling, or “pull” of information at step 326 as illustrated by the dashed line in FIG. 26 , or the polling step 324 can be eliminated and MMU 12 can “push” the infusion status to the PDA 32 or another computer associated with the system at predetermined times or stages of infusion completion.
- the PDA 32 can share the infusion status data with the HIS 18 or the HIS 18 can receive the data from the MMU 12 .
- the MMS 10 can include a MMU 12 and a DLE 38 A, 38 B that are deployed on separate computers (terminals) or on the same machine.
- the DLE (drug library editor) 38 A, 38 B includes a user interface 37 and a drug library database 39 formulated and editable using a conventional database management software platform such as SQL Server or SQL Desktop Engine by Microsoft of Redmond, Wash., USA.
- the drug library editor communicates with the MMU 12 and performs various functions related to the drug library, including but not limited to importing, maintaining or editing, and exporting the final drug library (FDL).
- the drug library can be stored in a local or network storage location 40 , 328 , with local storage being understood to be in a memory or storage medium 40 of the MMU or DLE and network storage 328 being understood to be in a location remote from the MMU or DLE and connected thereto by the electronic network 76 ( FIG. 4 ).
- the MMU 12 includes a web browser 41 for producing various predetermined and user customizable views and reports.
- the MMU 12 further includes a business logic unit 43 and a reporting engine 45 .
- the logic unit 43 and reporting engine 45 communicate with and interact with the web browser 41 and a MMU database 47 formulated using any conventional database management software, such as Microsoft SQL Server 2000.
- the drug library can be edited in the DLE 38 A and the updated or final drug library version (FDL) can be exported into storage 40 , 328 and then imported in the MMU 12 for eventual download to medical devices.
- FDL final drug library version
- Utilizing separate machines or terminals for the MMU console 38 and the DLE console 38 A is advantageous in that control, maintenance and editing of the drug library can be done by licensed pharmacists or doctors in one physical location, while monitoring of the MMU 12 and thus the pumps 14 in communication with the MMU 12 can be done by less costly caregivers in another physical location, such in the patient's ward where they can respond quickly to any problems.
- the storage 40 , 328 can be a database that is shared by the MMU 12 and the DLE 38 A or 38 B.
- This database can be managed by a database management software package, such as Microsoft SQL Server 2000.
- the MMU console 38 and the DLE console 38 A can still be in two separate locations and connected to the same common database, which can be stored on any machine in the network, including but not limited to on the same machine as MMU console 38 or DLE console 38 A, for exporting a drug library from DLE to MMU 12 . This would allow the export/import of the drug library from DLE to MMU to be done with or without user intervention.
- the MMU 12 of this invention allows a user 330 to select one or more medical devices 14 , such as infusers or pumps, at step 332 and launch or initiate a drug library download at step 334 .
- the MMU 12 downloads a drug library to a communication engine or network interface 122 associated with the infuser 14 .
- the MMU 12 and the interface 122 preferably communicate wirelessly.
- the interface 122 is preferably attached to or, more preferably, internal to the infuser 14 (“internal” should be understood as having a majority of its circuit board residing inside the housing of the infuser).
- the interface 122 communicates the status of the drug library download back to the MMU 12 at step 338 , reporting whether any errors were encounter or verifying that the download was successfully received.
- the infuser or pump 14 includes the interface 122 that includes or communicates with a cache memory 126 A to store the new drug library information so the pump 14 may continue to use an existing drug library to complete an infusion.
- the interface 122 notifies the infuser 14 that a drug library update has been received. An alert or notice, in visual or audible form, that a drug library update has been received may be communicated to the infuser user interface.
- a triggering event at step 342 causes the new drug library to be pulled from the cache memory 126 A, which is associated with the interface 122 and pump 14 , in step 344 .
- the new drug library replaces the existing active drug library in the infuser when the triggering event occurs.
- the infuser 14 also reports its status, including which active drug library it is using, to the MMU 12 through the network interface at steps 346 and 348 .
- Detailed logs of the actions of the pump 14 and the interactions of the caregiver 114 with it are uploaded from the pump 14 to the MMU 12 in step 350 .
- the network interface 122 may erase the logs in the pump 14 at step 352 , if desired, to save space in the memory of the medical device 14 .
- the MMU 12 includes respective programs 61 , 63 for downloading or updating pump software code and managing a master drug ID map.
- the medical device 14 includes respective programs 131 , 133 for receiving downloads of this code and information.
- the download pump software programs 61 , 131 allow the MMU user to download a particular version of device-specific overall system operating code to the processing unit 36 of one or more medical devices.
- the new code can efficiently be loaded onto machines in the field, as an alternative to being returned to the factory for upgrade.
- the manage drug map programs 63 and 133 allow the MMU 12 and medical device 14 to recognize and cross-reference drug information from a variety of drug manufacturers, HIS vendors and other sources, for example, including but not limited to Abbott Laboratories, Hospira, Inc., Cerner Multum, First Data Bank and other similar sources.
- the MMU 12 only manages the latest version of the information and any one of those downloads can be “pulled” or initiated by the user at the user interface on the medical device 14 , using the network interface 122 as a pass through device or as an intermediate cache device.
- the medical device 14 could also be programmed to automatically pull the most recent information from the MMU 12 at startup or under other predetermined conditions, including but not limited to a specific day, date, time of day, etc., without operator input.
- FIG. 28 shows a couple of possible ways the MMU 12 can receive uploads regarding the status of an infusion.
- the information about the status of an infusion is pushed from the infuser 14 to the MMU 12 through the network interface 122 in steps 354 and 356 .
- the network interface 122 pulls information by querying the pump 14 about the status of the infusion at step 358 .
- the pump 14 responds to this call by providing in step 360 the status of the infusion, which is then sent to the MMU 12 in step 362 .
- steps are not shown in order to avoid overcomplicating the figures with alternative or optional steps, one skilled in the art will understand that either of the two status update processes shown in FIG. 28 and described above can be preceded by the step of the MMU 12 querying or polling the pump 14 through network interface 122 for its status.
- FIG. 29 illustrates a couple of possible ways the MMU 12 can receive event logs with detailed information regarding the actions of the pump 14 and the interactions of the caregiver 114 with it.
- the event log information can include, but is not limited to, pump status, pump activity, alerts, alarms, and caregiver activity such as keystrokes and alarm overrides.
- the event log information is pushed from the infuser 14 to the MMU 12 through the network interface 122 in steps 363 and 364 .
- the network interface 122 pulls event log information by querying the pump 14 at step 366 .
- the pump 14 responds to this call by providing in step 368 the event log information, which is then sent to the MMU 12 in step 370 .
- the HIS 18 and MMU 12 can be hard-wired and stationary, while it is preferable that the point-of-care (POC) input device or means 32 and the medical device 14 be mobile and equipped to transmit and receive communication wirelessly.
- the point of care input device 32 can be personal digital assistant (PDA), a notebook or laptop computer, a tabletop or cart-mounted personal computer, a bar code point-of-care (BPOC) scanning device, or other similar active or passive data input means.
- PDA personal digital assistant
- BPOC bar code point-of-care
- the POC input device is a PDA equipped with a bar code scanner.
- the physician enters or inputs a medication (infusion) order into the HIS 18 through means of the physician order entry (POE) computer 26 .
- the medication order specifies or prescribes that a specific patient is to receive a particular dosage of a specific medication or drug at a particular time via a prescribed administration route.
- An authorized caregiver 114 uses the POC device 32 to provide caregiver identification and to request or receive a list of tasks to be accomplished.
- the list may include medication orders for various patients under the caregiver's care.
- the caregiver enters or scans the machine-readable indicia 112 on a patient 110 with the POC device 32 and is able to access a list of one or more medication orders for the specific patient scanned.
- the caregiver 114 enters or scans the machine-readable indicia 102 on the drug container 100 and the machine-readable indicia 92 , 96 on the particular channel of the medical device or infusion pump 14 to be used for the infusion.
- the caregiver 114 can then confirm with POC device 32 and the HIS 18 that the information scanned matches the medication order.
- the POC device 32 transmits a medication delivery order including but not limited to some or all of the identification information discussed above and an infusion rate to the MMU 12 .
- the MMU 12 translates the simple infusion rate of the delivery order into delivery programming code or information suitable for automatically programming the designated pump 14 and further checks the delivery order and delivery programming code against a variety of drug library parameters (including but not limited to hard and/or soft limits for drug delivery rates), patient-specific safety factors, and clinical decision support rules.
- the MMU 12 can be configured by the user at the MMU console to monitor the status of the pump 14 and the infusion (including alarms, event logs, and pump user interface inputs), generate reports, and control the distribution of drug library and operating code updates to one or more pumps 14 .
- a drug library editor deployed as a part of the MMU 12 , its console 38 , or on a separate computer 38 A, enables the user to import, export and edit whole drug libraries and individual drug library values to control and customize a drug library according to hospital preferences.
- the MMU 12 saves the caregiver time by automatically populating or programming data entry fields in the pump 14 that previously had to be entered manually.
- the medication management system 10 of this invention enhances patient safety by minimizing manual entries.
- the system 10 also enhances patient safety by screening drug delivery orders for conformance with established hospital practices, expert or clinical decision support rules and recommendations before (more preferably immediately before) the pump 14 begins to execute the order.
- the system 10 can provide alerts in various locations, including but not limited to at the POC device 32 or at the medical device 14 , when the clinical decision rules are not met.
- the alerts can take many possible forms, including but not limited to visible or audible alarms.
- the caregiver 114 is provided with a least one and preferably several opportunities to catch a medication error before it happens. For example, the caregiver 114 can confirm the order at the POC device 32 and/or before pressing the start button on the pump 14 .
- the system is flexible enough to permit human interventions and overrides, but tracks such events for documentation purposes.
Abstract
A medication management system (MMS) includes a medication management unit (MMU) associated with a medical device. The MMU downloads medication delivery code based on a medication delivery order to the medical device only if information from a first input matches information from a second input. The medical device receives delivery information electronically only from the MMU. The medication order is performed only after delivery data validation. The MMU also determines drug-drug incompatibility. The MMU can modulate (start, stop, sequence and dynamically adjust) medication order performance.
Description
- This application is a continuation of U.S. Ser. No. 10/930,358 filed on Aug. 31, 2004, which is a continuation-in-part of U.S. Ser. No. 10/783,641 filed Feb. 20, 2004, which claims priority based upon U.S. Provisional Application Ser. No. 60/509,404 filed Oct. 7, 2003 and U.S. Provisional Application Ser. No. 60/527,583 filed Dec. 5, 2003, all of which are expressly incorporated herein by reference in their entirety.
- The present invention relates to the field of delivering medication to patients, more particularly to an integrated system for maximizing patient safety and caregiver productivity for medication delivery.
- Modern medical care often involves the use of medical pump devices to deliver fluids and/or fluid medicine to patients. Medical pumps permit the controlled delivery of fluids to a patient, and such pumps have largely replaced gravity flow systems, primarily due to the pump's much greater accuracy in delivery rates and dosages, and due to the possibility for flexible yet controlled delivery schedules. However, modern medical devices, including medical pumps, can be complicated and time-consuming for caregivers to program. Medical facilities struggle to provide appropriate caregiver staffing levels and training while holding down the cost of medical care. Human errors in pump programming and other medication errors can have adverse or even deadly consequences for the patient.
- Therefore, a principal object of this invention is to provide an integrated medication management system that reduces the risks of medication error and improves patient safety.
- A further object of the invention is to provide a medication management system that improves caregiver productivity.
- Another object of the invention is to provide a medication management system that improves the accuracy of the medication delivery process by eliminating labor-intensive tasks that can lead to human errors.
- A still further object of the invention is to provide a medication management system that relies on an electronically-transmitted medication order and machine readable indicia on the drug container, patient, and medication delivery device to insure the “five rights” of medication management, i.e., that the right medication is delivered to the right patient through the right route in the right dosage at the right time.
- Another object of the invention is to provide the caregiver with a pass code or machine-readable indicia to insure that only an authorized individual caregiver can initiate a medication order and that an authorized caregiver must confirm the medication order prior to its administration to the patient.
- A still further object of the invention is to provide a medication management system wherein the medical device receives delivery information electronically only through a medication management unit.
- Another object of the invention is to provide medication management system wherein the medical device is preprogrammed and executes the medication order only after a user has validated delivery data.
- A still further object of the invention is to provide a medication management system wherein the physical location of a medical device can be determined and pinpointed based on the last access node used by the medical device.
- Another object of the invention is to provide a medication management system for adjusting a patient-specific rule set based on new patient conditions and/or recent lab results.
- A still further object of the invention is to provide a medication management system for determining drug-drug incompatibility between two medication orders for concurrent delivery (to the same patient at the same time) and/or in an unacceptably close time sequence.
- Another object of the invention is to provide a medication management system for remotely sending an order or information to the medical device to modulate a planned or ongoing medication order and delivery thereof to the patient.
- A still further object of the invention is to provide a medication management system for automatically associating a medical device with a patient based on wireless transmission of a patient ID to the medical device, thereby establishing a patient area network.
- Another object of the invention is to provide a medication management system for caching an updated drug library at the medical device to replace an existing drug library, during execution of a medication order.
- A still further object of the invention is to provide a medication management system for displaying a picture of the patient on a device within the system, such as at the medical device, for a caregiver to perform a visual validation of the right patient.
- Another object of the invention is to provide a medication management system for evaluating the performance of multiple medical devices based on information from the multiple medical devices.
- A still further object of the invention is to provide a medication management system for evaluating the performance of one or more caregivers based on information from multiple medical devices.
- Another object of the invention is to provide a medication management system for adjusting medical device output conveyed to a caregiver based on multiple factors.
- These and other objects will be apparent to those skilled in the art.
- A medication management system includes a medication management unit (MMU) associated with a medical device for performing a prescribed medication order. The MMU compares medication order information from a first input means to machine readable delivery information from a second input means and downloads a medication order to the medical device only if the information from the first input means matches the information from the second input means. The medical device receives medication order information electronically only through the medication management unit (i.e., does not receive delivery information directly from the second input means). The MMU permits the medical device to perform the order only after a user has validated delivery data at the medical device.
- The MMU determines the general physical location of a medical device based on the last access node used by the wireless connectivity capability in the medical device and an audible alarm can be activated to allow a user to pinpoint the physical location of the medical device more precisely.
- Using expert clinical support decision rules, the MMU also determines drug-drug incompatibility between two medication orders for concurrent delivery (to the same patient at the same time) and/or in an unacceptably close time sequence through the same output IV line. Further, the MMU also adjusts patient-specific rule sets based on newly measured or observed patient conditions and/or recent lab results. Advantageously, warnings, alarms or alerts based on violations of these rules are provided as close as possible to the actual delivery time so that they are more meaningful, ripe for corrective action, and less likely to be ignored due to incomplete information.
- Based on laboratory data or other newly received patient information, the MMU can modulate the medication order planned or currently being delivered. The MMU sends an order from the MMU to the medical device to modulate performance of the medication order. The patient and the medical device automatically associate with each other to form a patient area network based on wireless transmission of ID information. During execution of a medication order, the medical device caches an updated drug library in a cache memory and, upon occurrence of a triggering event, replaces an existing drug library in the primary memory of the device with the updated library. A picture of the patient is displayed at a device within the system, such as the medical device, for a caregiver to perform a visual validation of the right patient. The MMU evaluates the performance of multiple medical devices and one or more caregivers based on information communicated from the medical devices. The MMU adjusts medical device output conveyed to a caregiver based on multiple factors.
- In other embodiments of the medication management system of this invention, the MMU receives validated, matched or verified correct medication order and delivery information from an information system directly through an electronic network or indirectly through a wireless handheld point-of-care input (scanning) device, such as a personal digital assistant (PDA). The PDA transmits the delivery information and the medication order in the form of an infusion rate to the MMU.
- The MMU translates the simple infusion rate of the delivery order into delivery programming code or information suitable for automatically programming the designated pump and further checks the delivery order and delivery programming code against a variety of drug library parameters (including but not limited to hard and/or soft limits for drug delivery rates), patient-specific safety factors, and clinical decision support rules including drug-drug interactions. The MMU can be configured by the user at the MMU console to monitor the status of the pump and the infusion (including alarms, event logs, and pump user interface inputs), generate reports, and control the distribution of drug library and operating code updates to one or more pumps. A drug library editor deployed as a part of the MMU, its console, or on a separate computer, enables the user to import, export and edit whole drug libraries and individual drug library values to control and customize a drug library according to hospital preferences.
- The MMU saves the caregiver time by automatically populating or programming data entry fields in the pump that previously had to be entered manually. The medication management system of this invention enhances patient safety by minimizing manual entries. The system also enhances patient safety by screening drug delivery orders for conformance with established hospital practices, expert or clinical decision support rules and recommendations before (more preferably immediately before) the pump begins to execute the order. The caregiver is provided with a least one and preferably several opportunities to catch a medication error before it happens. The caregiver can confirm the order at the point-of-care device and/or before pressing the start button on the pump. The system is flexible enough to permit human interventions and overrides, but tracks such events for documentation and trouble-shooting purposes.
-
FIG. 1 is a schematic diagram of the medication management system including a medication management unit and a medical device, integrated with an information system, according to the present invention. -
FIG. 1A is an alternative schematic diagram of the medication management system including a medication management unit and a medical device, integrated with an information system, according to the present invention. -
FIG. 2 is a schematic diagram of the medication management unit according to the invention. -
FIG. 3 is a schematic diagram illustrating some of the major functions performed by the medication management unit according to the invention. -
FIG. 4 is a pictorial schematic diagram of the medication management system and its interaction with medical devices and an information system in a hospital environment. -
FIG. 4A is a schematic diagram of the medical device according to the invention. -
FIG. 5 is a partial flow chart of the medication management system processing a drug order through the medication management unit and medical device, and integrated with an information system according to the invention. -
FIG. 5A is a continuation of the flow chart ofFIG. 5 . -
FIG. 6 , is an alternative flow chart of the medication management system processing a drug order through the medication management unit and medical device, and integrated with an information system according to the invention. -
FIG. 6A is a continuation of the flow chart ofFIG. 6 . -
FIG. 7 is a screen shot of a delivery information input device for entry of a caregiver specific pass code. -
FIG. 8 is a screen shot of a delivery information input device for pulling up a scan patient option. -
FIG. 9 is a screen shot of a delivery information input device for entry of patient-specific information. -
FIG. 10 is a screen shot of a delivery information input device displaying a task list. -
FIG. 11 is a screen shot of a delivery information input device displaying a medication order prescribed for a patient. -
FIG. 12 is a front view of a medical device displaying a start up screen. -
FIG. 13 is a front view of a medical device with a display and user interface means for selecting a clinical care area of a medical facility. -
FIG. 14 is a front view of a medical device with a display and user interface means for selecting a desired input channel of the medical device. -
FIG. 15 is a front view of a medical device with a display and user interface means for confirming correct delivery programming code data at the medical device. -
FIG. 16 is a screen shot of a delivery information input device for confirming correct delivery programming code data. -
FIG. 17 is a schematic diagram of the medication management system including a medication management unit and one or more medical devices, showing how the medication management unit communicates with a medical device to locate the device. -
FIG. 18 is a flow chart of the medication management system locating a medical device. -
FIG. 19 is a flow chart of the medical device retrieving/receiving an updated drug library from the medication management unit. -
FIG. 20 is a flow chart of the medication management system updating a delivery program code executed on the medical device based on new information from a lab system, HIS and/or monitoring device. -
FIG. 21 is an alternative pictorial schematic diagram of the medication management system and its interaction with medical devices and the information system. -
FIG. 22 is a flow chart of the medication management system generating an operation evaluation report of a caregiver or medical device. -
FIG. 23 is similar toFIG. 1 , but shows an alternative schematic diagram of the medication management system including a medication management unit and a medical device, integrated with an information system without using a patient link, according to the present invention. -
FIG. 24 is a schematic diagram that provides further detail on the architecture and workflow related to the medication management system depicted inFIG. 23 . -
FIG. 25 is a schematic diagram that depicts the flow of data with respect to the medication management system ofFIG. 23 . -
FIG. 26 is a flow chart showing the actions and interactions for automatically programming a medical device such as an infuser and monitoring status of the task programmed using the medication management system ofFIG. 23 . -
FIG. 27 is a flow chart showing the actions and interactions for downloading a drug library or other information to a medical device such as an infuser using the medication management system ofFIG. 23 . -
FIG. 28 is a flow chart showing the actions and interactions for uploading and monitoring infusion status in the medication management system ofFIG. 23 . -
FIG. 29 is a flow chart showing the actions and interactions for uploading and maintaining event logs in the medication management system ofFIG. 23 . -
FIG. 30 is a schematic diagram showing the medication management unit server and the drug library editor deployed on separate computing machines according to one embodiment of the present invention. - With reference to
FIGS. 1 and 1A , the medication management system (MMS) 10 of the present invention includes a medication management unit (MMU) 12 and amedical device 14, typically operating in conjunction with one or more information systems or components of ahospital environment 16. The term hospital environment should be construed broadly herein to mean any medical care facility, including but not limited to a hospital, treatment center, clinic, doctor's office, day surgery center, hospice, nursing home, and any of the above associated with a home care environment. As discussed below, there can be a variety of information systems in a hospital environment. As shown inFIG. 1 , theMMU 12 communicates to a hospital information system (HIS) 18 via acaching mechanism 20 that is part of thehospital environment 16. - It will be understood by those of skill in art that the
caching mechanism 20 is primarily a pass through device for facilitating communication with the HIS 18 and its functions can be eliminated or incorporated into the MMU 12 (FIG. 1A ) and/or themedical device 14 and/or the HIS 18 and/or other information systems or components within thehospital environment 16. TheCaching Mechanism 20 provides temporary storage of hospital information data separate from theHIS 18, the medication administration record system (MAR) 22, pharmacy information system (PhIS) 24, physician order entry (POE) 26, and/orLab System 28. TheCaching Mechanism 20 provides information storage accessible to theMedication Management System 10 to support scenarios where direct access to data within thehospital environment 16 is not available or not desired. For example, thecaching mechanism 20 provides continued flow of information in and out of theMMU 12 in instances where the HIS 18 down or the connectivity between theMMU 12 and the electronic network (not shown) is down. Thecaching mechanism 20 also provides improved response time to queries from theMMU 12 to theHIS 18, as direct queries to theHIS 18 are not consistently processed at the same speed and often require a longer period of time for the HIS 18 to process. - The HIS 18 communicates with a medication administration record system (MAR) 22 for maintaining medication records and a pharmacy information system (PhIS) 24 for delivering drug orders to the HIS. A physician/provider order entry (POE)
device 26 permits a healthcare provider to deliver a medication order prescribed for a patient to the hospital information system directly or indirectly via thePhIS 24. One skilled in the art will also appreciate that a medication order can be sent to theMMU 12 directly from thePhIS 24 orPOE device 26. As used herein the term medication order is defined as an order to administer something that has a physiological impact on a person or animal, including but not limited to liquid or gaseous fluids, drugs or medicines, liquid nutritional products and combinations thereof. -
Lab system 28 andmonitoring device 30 also communicate with theMMU 12 to deliver updated patient-specific information to theMMU 12. For example, thelab system 28 sends lab results of blood work on a specific patient to theMMU 12, while themonitoring device 30 sends current and/or logged monitoring information such as heart rate to theMMU 12. As shown, theMMU 12 communicates directly to thelab system 28 andmonitoring device 30. However, it will be understood to those of skill in art that theMMU 12 can communicate to thelab system 28 andmonitoring device 30 indirectly via theHIS 18, thecaching mechanism 20, themedical device 14 or some other intermediary device or system. This real-time or near delivery time patient-specific information is useful in adapting patient therapy because it may not have been available at the time the medication order was prescribed. As used herein, the term real-time denotes a response time with a latency of less than 3 seconds. The real-time digital communications between theMMU 12 and other interconnected devices and networks prevents errors in patient care before administration of medications to the patient, especially in the critical seconds just prior to the start of medication delivery. - Delivery
information input device 32 also communicates with theMMU 12 to assist in processing drug orders for delivery through theMMU 12. The deliveryinformation input device 32 can be any sort of data input means, including those adapted to read machine readable indicia such as barcode labels; for example a personal digital assistant (PDA) with a barcode scanner. Hereinafter the deliveryinformation input device 32 will be referred to asinput device 32. Alternatively, the machine readable indicia may be in other known forms, such as radio frequency identification (RFID) tag, two-dimensional bar code, ID matrix, transmitted radio ID code, human biometric data such as fingerprints, etc. and theinput device 32 adapted to “read” or recognize such indicia. Theinput device 32 is shown as a separate device from themedical device 14; alternatively, theinput device 32 communicates directly with themedical device 14 or may be integrated wholly or in part with the medical device. - With reference to
FIG. 2 , themedication management unit 12 includes anetwork interface 34 for connecting theMMU 12 to multiple components of ahospital environment 16, themedical device 14, and any other desired device or network. Aprocessing unit 36 is included inMMU 12 and performs various operations described in greater detail below. A display/input device 38 communicates with theprocessing unit 36 and allows the user to receive output from processingunit 36 and/or input information into theprocessing unit 36. Those of ordinary skill in the art will appreciate that display/input device 38 may be provided as a separate display device and a separate input device. - An
electronic storage medium 40 communicates with theprocessing unit 36 and stores programming code and data necessary for theprocessing unit 36 to perform the functions of theMMU 12. More specifically, thestorage medium 40 stores multiple programs formed in accordance with the present invention for various functions of theMMU 12 including but not limited to the following programs: MaintainDrug Library 42;Download Drug Library 44;Process Drug Order 46; Maintain ExpertClinical Rules 48; Apply ExpertClinical Rules 50; Monitor Pumps 52;Monitor Lines 54; GenerateReports 56;View Data 58; Configure theMMS 60; and Monitor theMMS 62. The MaintainDrug Library 42 program creates, updates, and deletes drug entries and establishes a current active drug library. TheDownload Drug Library 44 program updatesmedical devices 14 with the current drug library. TheProcess Drug Order 46 program processes the medication order for a patient, verifying that the point-of-care (POC) medication and delivery parameters match those ordered. The Maintain ExpertClinical Rules 48 program creates, updates, and deletes the rules that describe the hospital's therapy and protocol regimens. The Apply ExpertClinical Rules 50 program performs logic processing to ensure safety and considers other infusions or medication orders, patient demographics, and current patient conditions that include blood chemistry values such as insulin/glucose, monitored data such as pulse and respiration, and clinician assessments such as pain or responsiveness. The Monitor Pumps 52 program acquires ongoing updates of status, events, and alarms transmitted both real-time and in batch mode, as well as tracking the location, current assignment, and software versions such as the drug library version residing onmedical device 14. TheMonitor Lines 54 program acquires ongoing updates of status, events and alarms for each channel or line for amedical device 14 that supports multiple drug delivery channels or lines. The Generate Reports 56 program provides a mechanism that allows the user to generate various reports of the data held in theMMU storage medium 40. TheView Data 58 program provides a mechanism that supports various display or view capabilities for users of theMMU 12. The Notifications 59 program provides a mechanism for scheduling and delivery of events to external systems and users. The Configure theMMS 60 program provides a mechanism for system administrators to install and configure theMMS 10. The Monitor theMMS 62 program enables information technology operations staff capabilities to see the current status ofMMS 10 components and processing, and other aspects of day-to-day operations such as system start up, shut down, backup and restore. - With reference to
FIG. 3 , the various functional programs 42-62 of theMMU 12, each including separate features and rules, are partitioned (at a higher level than shown inFIG. 2 ) and logically organized into interrelated managing units of theMMU 12. As shown, theMMU 12 includes anasset manager 64, analarm manager 66, a drug library manager (such as, for example, HOSPIRA MEDNET™) 68, acaregiver manager 70, atherapy manager 72, and/or a clinical data manager 73. However, one of ordinary skill in the art will appreciate that additional or alternative hospital system managing units can be provided without departing from the present invention. Additionally, theMMU 12 includes a master adjudicator 74 between the separate interrelated hospital system managing units 64-73 of theMMU 12, to regulate the interaction between the separate management units. - Further, while the
MMU 12 as described herein appears as a single device, there may be more than oneMMU 12 operating harmoniously and sharing the same database. For example theMMU 12 can consist of a collection of MMU specific applications running on distinct servers in order to avoid a single point of failure, address availability requirements, and handle a high volume of requests. In this example, each individual server portion of theMMU 12 operates in conjunction with other server portions of theMMU 12 to redirect service requests to another server portion of theMMU 12. Additionally, the master adjudicator 74 assigns redirected service requests to another server portion of theMMU 12, prioritizing each request and also ensuring that each request is processed. - With reference to
FIGS. 2 and 3 , the managing units 64-72 each include separate features and rules to govern their operation. For example theasset manager 64 governs the execution of the Monitor Pumps 52 andMonitor Lines 54 programs; thedrug library manager 68 governs the execution of theDrug Library 42 and DownloadDrug Library 44 programs; thetherapy manager 72 governs the execution of theProcess Drug Order 46, Maintain ExpertClinical Rules 48, and Apply ExpertClinical Rules 50 programs; and the clinical data manager 73 governs the execution of the GenerateReports 56 andView Data 58 programs. Other distribution of the functional MMU programs 42-62 among the hospital system managing units 64-73 can be made in accordance with the present invention. - With reference to
FIG. 4 , anelectronic network 76 connects theMMU 12,medical device 14, HIS 18, andinput device 32 for electronic communication. Theelectronic network 76 can be a completely wireless network, a completely hard wired network, or some combination thereof. Themedical device 14 andinput device 32 are located in a treatment location 77. As shown, themedical device 14 andinput device 32 are equipped withantennas antennae electronic network 76 via anantenna 82 ofaccess node 84 connected to theelectronic network 76. Further details on theantenna 78 can be found in commonly assigned co-pending application entitled SYSTEM FOR MAINTAINING DRUG INFORMATION AND COMMUNICATING WITH MEDICATION DELIVERY DEVICES filed on Feb. 20, 2004, which is expressly incorporated herein in its entirety. - In the context of the present invention, the term “medical device” includes without limitation a device that acts upon a cassette, reservoir, vial, syringe, or tubing to convey medication or fluid to or from a patient (for example, an enteral pump, infusion pump, a patient controlled analgesia (PCA) or pain management medication pump, or a suction pump), a monitor for monitoring patient vital signs or other parameters, or a diagnostic device.
- For the purpose of exemplary illustration only, the
medical device 14 ofFIG. 4 is disclosed as a cassette type infusion pump. The pump stylemedical device 14 includes a user interface means 86,display 88,first channel 90, and first channel machinereadable indicator 92. Afirst IV line 98 has a conventional cassette 99A (not shown) that is inserted into thefirst channel 90, and includes amedication bag 100 with a machinereadable indicator 102. Asecond IV line 101 is connected to an input port of the cassette 99A, and includes amedication bag 106 with a machinereadable indicator 108. A singleoutput IV line 98 is connected to an outlet port of the cassette 99A and connected to apatient 110 who has a machinereadable indicator 112 on a wristband, ankle band, badge or similar article that includes patient-specific and or identifying information, including but not limited to patient ID, and demographics. - In an alternative embodiment illustrated by dashed lines in
FIG. 4 , themedical device 14 is a multi-channel pump having afirst channel 90 with first channel machinereadable indicator 92 and at least asecond channel 94 with a second channel machinereadable indicator 96. Theline 101 from themedication bag 106 is eliminated and replaced byline 104 with a cassette 99B (not shown) inserted into thesecond channel 94 and anoutput line 104 extends from the cassette to the patient. The same type of cassette 99 (not shown) is inserted in thefirst channel 90. Additional details on such a multi-channel pump and cassette 99A can be found in commonly owned U.S. patent application Ser. No. 10/696,830 entitled MEDICAL DEVICE SYSTEM, which is incorporated by reference herein in its entirety. - Within a patient area network 113 (hereinafter, PAN 113), a caregiver 114 (if present) has a machine
readable indicator 116 on a wristband, badge, or similar article and operates theinput device 32. Theinput device 32 includes an input means 118 for reading the machinereadable indicators output device 120 is included on theinput device 32. The input/output device 120 allows the user to receive output from theinput device 32 and/or input into theinput device 32. Those of ordinary skill in the art will appreciate that display/input device 120 may be provided as a separate display device and a separate input device. - With reference to
FIG. 4A , the pump stylemedical device 14 includes anetwork interface 122 for connecting themedical device 14 to theelectronic network 76. Thenetwork interface 122 operates theantenna 78 for wireless connection to theelectronic network 76. Aprocessor 124 is included in themedical device 14 and performs various operations described in greater detail below. The input/output device 87 (display 88 and user interface means 86) allows the user to receive output from themedical device 14 and/or input information into themedical device 14. Those of ordinary skill in the art will appreciate that input/output device 87 may be provided as a separate display device and a separate input device (as shown inFIG. 4 ,display 88 and user interface means 86) or combined into a touch screen for both input and output. Amemory 126 communicates with theprocessor 124 and stores code and data necessary for theprocessor 124 to perform the functions of themedical device 14. More specifically, thememory 126 stores multiple programs formed in accordance with the present invention for various functions of themedical device 14 as is relates to theMMU 12 including the following programs:Process Drug Order 128,Monitor Pump 130, and DownloadDrug Library 132. - With reference to
FIGS. 5 and 5A , the functional steps of theProcess Drug Order 46 and Apply ExpertClinical Rules 50 programs of theMMU 12 and theProcess Drug Order 128 program of themedical device 14 are shown in operation with theHIS 18, thecaching mechanism 20 and theinput device 32. - With reference to
FIGS. 4 , 5 and 7, to begin to process a drug order, theinput device 32 displays a default screen (not shown) on input/output device 120 which the caregiver uses to accesspassword screen 133B (FIG. 7 ). Thepassword screen 133B prompts thecaregiver 114 to enter caregiver specific identification information (caregiver ID). Thecaregiver 114 enters caregiver ID such as a username and/or password or pass code, or the machinereadable indicator 116. Theinput device 32 enters this caregiver ID atstep 134. - With reference to
FIGS. 4 , 5 and 8-9, theinput device 32 then displays ascan patient screen 135A (FIG. 8 ) which prompts thecaregiver 114 to enter patient-specific identification information (patient ID). Thecaregiver 114 enters the patient ID such as the machinereadable indicator 112. Theinput device 32 enters this patient ID and atstep 136, and displays a confirmedscan patient screen 135B (FIG. 9 ) indicating that the patient ID was successfully entered into theinput device 32. - With reference to
FIG. 5 , theinput device 32 then transmits the patient ID to thecaching mechanism 20 atstep 138. Thecaching mechanism 20 transmits the patient ID to the HIS 18 atstep 140. The HIS 18 retrieves a patient-specific task list and patient-specific order information based on the patient ID and transmits both to thecaching mechanism 20 atstep 142. The order information includes but is not limited to an order detail for a medication order, patient demographic information, and other hospital information systems data such as lab results data. Thecaching mechanism 20 transmits the task list to theinput device 32 atstep 143. - With reference to
FIGS. 4 , 5 and 10-11, theinput device 32 then displays atask list screen 143A (FIG. 10 ) which prompts thecaregiver 114 to access the task list on theinput device 32. Theinput device 32 prompts thecaregiver 114 to enter drug specific identification information or drug ID from thecontainer 100. Thecaregiver 114 enters a drug ID such as the drug container specific machine-readable indicator 102. Theinput device 32 enters this drug ID atstep 144. Theinput device 32 processes the drug ID to select the correct task from the task list, then displays atask screen 143B (FIG. 11 ), and transmits a request (dispense ID) based upon the entered drug ID to thecaching mechanism 20 requesting an order ID atstep 146. Thecaching mechanism 20 transmits a request (dispense ID) to the HIS 18 requesting an order ID atstep 148. The order ID is simply a unique identifier for the medication order, lab test, or other task or procedure to be performed. The order ID can be a number, alphanumeric code, etc. The HIS 18 transmits an order ID to thecaching mechanism 20 atstep 150. Thecaching mechanism 20 forwards this order ID to theinput device 32 atstep 152. - The
input device 32 matches the order ID with an item in the task list to ensure a Five Rights check atstep 154. The “Five Rights” in this section refer to the “Five Rights of Medical Administration”. Alternatively, the Five Rights check is done at theMMU 12 once theMMU 12 receives the order information as well as the patient, dispense, and channel IDs. A description of these “rights” follows. Right patient, is the drug being administered to the correct patient. Right drug, is the correct drug being administered to the patient. Right dose, is the correct dosage of the drug being administered to the patient. Right time, is the drug being administered to the patient at the correct time. Right route, is the drug being administered into the patient by the correct route, in this case intravenously through an IV. Once the order ID and item in the task list are reconciled, theinput device 32 sends an order confirmed message to thecaching mechanism 20 atstep 156. In response, thecaching mechanism 20 sends the order detail (medication order prescribed for a patient) of the order information to theinput device 32 atstep 158. - With reference to
FIGS. 4 , 5, 11, theinput device 32 then displays a scan device/channel screen 143B (FIG. 11 ) which prompts thecaregiver 114 to enter channel identification information (channel ID) regarding which channels of themedical device 14 are to be used for the delivery. Thecaregiver 114 enters a channel ID such as the machinereadable indicator 92. Theinput device 32 enters this channel ID atstep 160, and displays a confirmed scan device screen 159B (FIG. 11B ) indicating that the channel ID was successfully entered into theinput device 32. It will be appreciated that thechannel ID indicator 92 can include information also identifying the medical device 14 (medical device ID). Alternatively, it is contemplated that an additional machine readable indicator (not shown) may be provided for the medical device itself separate from the channel ID machinereadable indicator 92. If themedical device 14 has a single channel, a single indicator will clearly suffice. If themedical device 14 is a multi-channel device, the channel indicators can also carry information that uniquely identifies the device the channel is on. At any rate, it should be apparent that a second entry of a combined device/channel ID may be redundant and could be eliminated. Theinput device 32 then transmits the delivery information including caregiver ID, patient ID, medical device ID and/or channel ID, drug ID, and order ID to theMMU 12 atstep 162. - Alternatively, the three entered IDs (patient ID, drug ID, and channel ID) are entered in a different specific order or without regard to order. Where the IDs are entered without regard to order, the IDs would be maintained within the
MMS 10 and/orcaching mechanism 20 as they are entered, so that the IDs can be recalled when needed to complete the medication delivery workflow. - With reference to
FIGS. 4 , 5 and 12-14, when themedical device 14 is turned on atstep 164 themedical device 14 displays a start upscreen 163A (FIG. 12 ) on thedisplay 88 of themedical device 14. Themedical device 14 then displays a clinical carearea selection screen 163B (FIG. 13 ) which prompts thecaregiver 114 to select the clinical care area (CCA) that themedical device 14 is being assigned to. Thecaregiver 114 enters or selects the CCA atstep 166 using scroll and select/enter keys on the user interface means 86. Themedical device 14 then displays achannel selection screen 163C (FIG. 14 ) that prompts thecaregiver 114 to select the desired channel (90 or 94) or bag source (100 or 106) usingsoft keys 163D-G, more particularly 163E, 163F respectively. Themedical device 14 enters this channel ID atstep 168. The CCA information is transmitted to theMMU 12 by themedical device 14 atstep 170. Alternatively, where the CCA is known and available to theHIS 18, the CCA can be automatically generated for themedical device 14, and sent from the HIS 18 to theMMU 12 - With reference to
FIGS. 2 and 5 , theMMU 12 executes theProcess Drug Order 46 program and sends an active order request based on the delivery information from theinput device 32 to thecaching mechanism 20 atstep 172. Thecaching mechanism 20 responds by sending the corresponding patient-specific order information to theMMU 12 atstep 174. Thecaching mechanism 20 may send to theMMU 12 order information regarding all information associated with the particular patient, including but not limited to order detail for a medication order, patient demographic information, and other hospital information systems data such as lab results data or monitoring data. - Referring to
FIG. 5A , theMMU 12 then executes the Apply ExpertClinical Rules 50 program to process the CCA information from themedical device 14 and the delivery information from theinput device 32, atstep 178. The Apply ExpertClinical Rules 50 program compares the delivery information with an expert rule set to determines expert rule set violations based on correlating treatment based protocols, disease based protocols, drug-drug incompatibility, patient data (age, height, weight, etc), vital signs, fluid in/out, blood chemistry, and status assessments (such as pain and cognition). As used herein, the term drug-drug incompatibility includes but is not limited to determinations of drug-drug interactions and/or drug-drug compatibility between two or more medication orders for concurrent delivery (to the same patient at the same time) and/or in a time sequence for the same patient (i.e. through a common output IV line). In cases where the Apply ExpertClinical Rules 50 program finds an expert rule set violation (such as a drug-drug incompatibility), the Apply ExpertClinical Rules 50 program generates an alarm and/or requires a time delay in execution for one of the two separate delivery information submissions. - The Apply Expert
Clinical Rules 50 program also establishes a patient-specific rule algorithm. The patient-specific rule algorithm is primarily based on the expert rule set described above applied to a specific order detail. The patient-specific rule algorithm generates a patient-specific rule set (discussed in greater detail below, at the description ofFIG. 20 ) according to patient-specific order information including but not limited to patient demographic information, and other hospital information systems data such as lab results data or monitoring data. The patient-specific rule set includes hard and soft dosage limits for each drug being administered. The patient-specific rule set is included in the delivery programming code sent to themedical device 14 atstep 182. - Any alarms generated by the
Process Drug Order 46 or Apply ExpertClinical Rules 50 programs are delivered to themedical device 14, HIS 18, and/orinput device 32, computer 254 (FIG. 17 ), atstep 180.Computer 254 can be located in a remote nurse station or a biomedical technician area. If no alarms are generated, theMMU 12 transmits a delivery program code to themedical device 14, atstep 182. The delivery program code sent fromMMU 12 to themedical device 14 includes a patient-specific rule set generated from any rule based adjudication at theMMU 12, including hard and soft dosage limits for each drug being administered. Themedical device 14 caches the patient-specific rule set contained in the delivery program code. Alternatively, theMMU 12 can generate an alarm at themedical device 14 or another location and not download the delivery program code. - With reference to
FIGS. 5 , 5A and 15, themedical device 14 displays an orderdose confirmation screen 187A (FIG. 15 ) which prompts thecaregiver 114 to confirm the delivery data. As shown, thecaregiver 114 selects the “yes” soft key 187B on themedical device 14 to confirm the delivery data and the no soft key 187C to cancel the delivery. Thecaregiver 114 confirms the delivery data at themedical device 14 atstep 188. Once thecaregiver 114 confirms the delivery data at themedical device 14, themedical device 14 then executes the delivery program code and begins infusion atstep 198. As part of the program code, the infusion may be delayed for a predetermined period of time. - Alternatively, confirmation from the caregiver can be made at the
input device 32 or required from both theinput device 32 andmedical device 14. As shown, a redundant additional confirmation performed by thecaregiver 114 at theinput device 32 after the medical device has received the delivery program code. Specifically, themedical device 14 transmits a canonical representation of the delivery programming code data (delivery data) to theMMU 12 detailing the infusion to be performed by themedical device 14, atstep 184. TheMMU 12 then transmits the same delivery data that was originally transmitted to themedical device 14 to theinput device 32 atstep 186. Alternatively, the delivery data can be passed to another remote computer (254 inFIG. 17 ), including but not limited to a computer at a nurse station, for confirmation. - With reference to
FIGS. 5A and 16 , theinput device 32 displays an orderdose confirmation screen 191A (FIG. 16 ) that prompts thecaregiver 114 to confirm the delivery data. As shown, thecaregiver 114 selects thecomplete button 191B on theinput device 32 to confirm the delivery data and the cancelbutton 191C to cancel the delivery. Thecaregiver 114 confirms the delivery data at theinput device 32 atstep 192, and the confirmation is used for documentation by theHIS 18, or other systems within thehospital environment 16. - With reference to
FIGS. 4A and 5A , during infusion, themedical device 14 executes itsProcess Drug Order 128 program. TheProcess Drug Order 128 program sends infusion change events and infusion time events in a deliveryevent log message 200 to theMMU 12. TheMMU 12 forwards these delivery event log messages to theinput device 32 or other system within thehospital environment 16 atstep 202. Thecaregiver 114 acknowledges these delivery event log messages on theinput device 32, atstep 204. Theinput device 32 then sends an acknowledged deliveryevent log message 206 to thecaching mechanism 20, detailing the delivery event, the caregiver ID, and the caregiver acknowledgment. The caching mechanism passes the delivery event message to the HIS 18 atstep 208. - Once infusion has ended at
step 210, themedical device 14 sends an infusion endedmessage 212 to theMMU 12. TheMMU 12 then aggregates all thedelivery event messages 200 sent during the infusion atstep 214. TheMMU 12 sends the aggregateddelivery events 216 to theinput device 32. Thecaregiver 114 enters a completedtask 218 on theinput device 32, and sends the aggregated delivery events to the caching mechanism atstep 220, which in turn passes the delivery event log messages to the HIS 18 atstep 222. - With reference to
FIGS. 6 and 6A , an alternative flow chart of theMMS 10 processing a drug order through theMMU 12 andmedical device 14 is shown. With reference toFIGS. 4 , 6 and 6A, thecaregiver 114 enters the patient ID, which then is stored in thecaching mechanism 20. Thecaching mechanism 20 transmits the patient ID to the HIS 18 and retrieves a patient-specific task list for that patient ID. Thecaregiver 114 then enters the drug ID from theindicator 102 of thecontainer 100 that may be translated into a dispense ID, which subsequently is stored in thecaching mechanism 20. Thecaching mechanism 20 transmits the drug ID or dispense ID to theHIS 18, and retrieves a patient-specific order information, including but not limited to an order detail, patient demographic information, and other hospital information systems data such as lab results data. Thecaregiver 114 then enters the channel ID, which is stored in theMMU 12. - Alternatively, the three entered IDs (patient ID, drug ID, and channel ID) are entered in a different specific order or without regard to order. Where the IDs are entered without regard to order, the IDs would be maintained within the
MMS 10 and orcaching mechanism 20 as they are entered, so that the IDs can be recalled when needed to complete the medication delivery workflow. - Upon receipt of the channel ID, the
MMU 12 requests the order information (order detail, patient demographic information, and other hospital information systems data) and retrieves it from thecaching mechanism 20. This order information is stored within theMMU 12 and utilized for subsequent rule processing such as “Five Rights” checking and other rule set algorithms. TheProcess Drug Order 46 program processes the delivery information from the input device 32 (including caregiver ID, patient ID, medical device/channel ID, and drug ID or dispense ID) and compares this delivery information with the corresponding order detail portion of the order information from thecaching mechanism 20, atstep 176. Where the order information and delivery information do not match, the device program code downloaded to themedical device 14 atstep 182 includes an alarm message indicating that the five rights check was not met. Additionally, the alarm message can include a description of which particular right(s) did not match. Alternatively, theNMU 12 can generate an alarm at themedical device 14 or another location and not download the program code for delivery of the medication order. - Alternatively, the
MMU 12 can accept a Five Rights check from another device, such as a HIS 18 or aninput device 32. This check can be accepted either by a direct data element being sent to theMMU 12 indicating a Five Rights check, or implied through the workflow provided by theHIS 18 orinput device 32. - The other steps shown in
FIGS. 6 and 6A are similar to corresponding steps inFIGS. 5 and 5A . Accordingly, these steps will not be described with any further detail here. One skilled in the art will appreciate that the vertical lines inFIGS. 5 , 5A, 6, 6A do not necessarily represent a firm time sequence. Some steps may be done sooner than shown (for example, turning on the medical device) or later than shown (for example, aggregate delivery events). - With reference to
FIGS. 2 , 4A, 5, 5A and 20, in one embodiment, theProcess Drug Order 46 program of theMMU 12 and the correspondingProcess Drug Order 128 program of themedical device 14 permit theMMU 12 to remotely control themedical device 14 to modulate performance of a medication order. For example, theMMU 12 can remotely start and/or stop themedical device 14. Once the delivery program code is received by themedical device 14 atstep 184, theProcess Drug Order 46 ofMMU 12 remotely starts execution of the infusion by sending astart order 224, which triggers the medical device to begin infusion atstep 225. Likewise, when the infusion is to end atstep 228, theProcess Drug Order 46 program can remotely stop the infusion by sending astop order 226 to themedical device 14, which triggers the medical device to end infusion atstep 228. Inmost cases, theMMU 12 requires the caregiver to confirm the start or stop of execution. This confirmation by the caregiver may take place at theinput device 32 or themedical device 14. However, one skilled in the art will appreciate that there may be emergency situations where an order could and should be stopped without human confirmation. - With reference to
FIGS. 2 , 5, 5A and 20, in one embodiment, the Apply ExpertClinical Rules 50 program of theMMU 12 permits theMMU 12 to adjust a previously fixed patient-specific rule set based on new patient conditions and/or recent lab results, and notify the caregiver that adjustment is recommended by theMMU 12. As discussed above in regard toFIGS. 5 and 5A , the Apply ExpertClinical Rules 50 program establishes a patient-specific rule algorithm. The patient-specific rule algorithm is primarily based on the expert rule set described above applied to a specific order detail. The patient-specific rule algorithm generates a patient-specific rule set according to patient-specific order information including but not limited to patient demographic information, and other hospital information systems data such as lab results data or monitoring data. The patient-specific rule set includes hard and soft dosage limits for each drug being administered, and these hard and soft dosage limits likewise are adjusted when the patient-specific rule set is adjusted. - For example, during or even before an infusion, the
MMU 12 may receive updated patient information that can impact an ongoing or impending infusion. As shown inFIG. 20 , thelab 28 sends updated patient-specific lab results to theMMU 12 atstep 230. Likewise, themonitoring device 30 sends updated patient-specific monitoring information to theMMU 12 atstep 232. Additionally theMMU 12 queries the HIS 18 for patient information including: Patient Allergies, Patient Diet, and Current Patient Medical Orders. Patient Allergies are used to check for drug-allergy interactions, atstep 231. Patient Diet information is used to check for drug-food interactions. Current Patient Medical Orders are used to check for drug-drug incompatibility. Like the patient information gathered from theLab 28 and themonitoring device 30, the patient information from HIS 18 is also used by theMMU 12 to update the delivery program order. - As shown in
FIGS. 5 and 5A , in cases where theMMU 12 is processing a drug order for themedical device 14, theMMU 12 executes the Apply ExpertClinical Rules 50 program atstep 178 to establish a patient-specific rule set based on updated patient information received or retrieved from thelab 28, themonitoring device 30, and or the HIS 18 (FIG. 20 ). This real-time or near delivery time updated patient-specific information is useful in adapting patient therapy because it may not have been available at the time the medication order was prescribed. - As shown in
FIG. 20 , TheMMU 12 also modifies the existing patient-specific rule set in the existing delivery program code atstep 234 based on updated patient information received or retrieved from thelab 28, themonitoring device 30, and or theHIS 18. TheMMU 12 optionally alerts theinput device 32 and/or themedical device 14 of changes to the patient-specific rule set.MMU 12 also optionally generates an alert message if the delivery programming code violates any parameter of the adjusted hard and soft dosage limits. Additionally, theMMU 12 optionally requests confirmation by the caregiver prior to instituting the new patient-specific rule set. TheMMU 12 then delivers an updated delivery program code to themedical device 14 for execution atstep 236. Themedical device 14 then executes this updated delivery program code asstep 238. The updated delivery program code sent fromMMU 12 to themedical device 14 includes an updated patient-specific rule set generated from any rule based adjudication at theMMU 12, including hard and soft dosage limits for each drug being administered. Themedical device 14 caches the updated patient-specific rule set contained in the delivery program code. Additionally, theMMU 12 collects, stores, and reports the changes to the patient-specific rule set, changes to the hard and soft limits, as well as the history of each medication order. - An example of how the
MMU 12 updates the patient-specific rule set based on lab results or monitored patient conditions is provided below with respect to the drug Heparin, which is a blood thinner. The medication order entered by the physician might be: -
- Give
heparin 1000 units/hour. If the activated partial thromboplastin time (APTT) >75 seconds then decrease heparin to 800 units/hour.
If themedical device 14 has started the infusion at 1000 units/hour and theMMU 12 subsequently receives an updated APTT value of 100 seconds from thelab 28 on the patient, the MMU automatically commands themedical device 14 to decrease the infusion rate to 800 units/hour. Alternatively, when the MMU is notified bylab 28, an alarm will be generated to thePDA 32 and/or themedical device 14 to notify the caregiver of the need to change the infusion rate. The MMU can preprogram the pump for the caregiver to confirm the recommended change.
- Give
- In further embodiment or method, the hospital may establish expert rules or clinical decision support rules in the
MMU 12 that will be applied automatically to incoming prescribed orders, such that the physician may simply write an order for 1000 or 1200 units/hour. The hospital best practices formulated by the appropriate medical personnel are established in theMMU 12 and can dictate that all heparin orders are to be conditioned on the APTT lab result and such an expert rule or clinical decision support rule will be used by theMMU 12 to govern the operation of themedical device 14. TheMMU 12 also can check the most recent patient data and provide an alarm and/or temporarily modify the delivery order prior to the start of the infusion if the prescribed order is no longer appropriate given the expert rules or clinical decision support rules and the latest lab results or monitored patient conditions. It should be apparent that this kind of intervention by theMMU 12 during or immediately prior to an infusion is particularly useful in preventing adverse consequences for the patient and the hospital. - Where the
MMU 12 adjusts a previously fixed patient-specific rule set based on new patient conditions and/or recent lab results, as described above, theMMU 12 provides dynamic advanced reports of real-time rule set changes in relation to changes in the condition of the patient (an “information cascade”). These advanced reports detail the history of both hard and soft upper and lower limits, as well as the activation of overrides and confirmations based on these limits for eachmedical device 14 managed by theMMU 12. Further details on this feature can be found in commonly owned co-pending application entitled SYSTEM FOR MAINTAINING DRUG INFORMATION AND COMMUNICATING WITH MEDICATION DELIVERY DEVICES filed on Feb. 20, 2004, which is expressly incorporated herein in its entirety. - With reference to
FIGS. 2 , 4A and 19, theDownload Drug Library 44 program in theMMU 12 and the correspondingDownload Drug Library 132 program in themedical device 14 operate to send a drug library to themedical device 14 from theMMU 12. The drug library includes drug and device related information, which may include but is not limited to drug name, drug class, drug concentration, drug amount, drug units, diluent amount, diluent units, dosing units, delivery dose or rate, medication parameters or limits, device/infuser settings and/or modes, CCA designations and constraints, and library version. TheDownload Drug Library 132 program is designed to cache in acache memory 126A a new database or drug library atmedical device 14 while maintaining an existing older version database or drug library in itsprimary memory 126. This allows the medical device to operate or deliver an infusion based on the older version of the drug library without disruption until a trigger event occurs, at which time the new drug library replaces the older version in theprimary memory 126. It is contemplated that themedical device 14 can be equipped with an initial drug library at the factory. - The
Download Drug Library 132 program in themedical device 14 begins at ablock 240 and at block 242 a determination is made that a drug library update needed event has occurred. For instance the drug library update needed event could be a completed infusion, a stopped infusion, elapsed time, a specific date and time, creation of the new drug library, themedical device 14 being or entering into a particular configurable mode such as stop, “sleep” or “wakeup”, connection of themedical device 14 to anaccess node 84 in a new CCA, a download of a new or modified drug library to the medication management unit, or a determination that the existing drug library at the medical device needs updating. The configurable mode could be any number of device modes including a power-on sleeping mode and a power-off mode. The determination that a drug library update needed event has occurred can be made by (at) theMMU 12, themedical device 14 or by a combination of the two. - Based on the specific drug library update needed event, the
Download Drug Library 132 proceeds to block 244 where it retrieves or receives a new drug library. Once retrieved or received, theDownload Drug Library 132 proceeds to block 246 where it stores the new drug library in thecache memory 126A of themedical device 14. While amedical device 14 is operating on a patient or in an otherwise nonconfigurable mode, information such as a new drug library or database is stored in acache memory 126A of themedical device 14 as the information is received from a wired or wireless link through thenetwork interface 122. TheDownload Drug Library 132 proceeds to block 248 where it determines if a specific trigger event has occurred. For instance, the trigger event could be a completed infusion, a stopped infusion, a determination that the device is in a configurable mode, elapsed time, a specific date and time, creation of the new drug library, a download of a new or modified drug library to the medication management unit, and a determination that the existing drug library at the medical device needs updating. The configurable mode could be any number of device modes including a power-on sleeping mode and a power-off mode. The determination that a trigger event has occurred can be made by (at) theMMU 12, themedical device 14 or by a combination of the two. - The
Download Drug Library 132 then proceeds to block 250 where it deletes the existing drug library inprimary memory 126 and installs the new drug library, and the new drug library fromcache memory 126A will replace the older information in thememory 126 of themedical device 14. TheDownload Drug Library 132 process is then complete and ends inblock 252. - Additional related features of the
Download Drug Library 44 program in theMMU 12 and the correspondingDownload Drug Library 132 program include recording the history of the download, verify the correct download, notification to the caregiver of a change of library, and a preliminary note on themedical device 14 display stating that the drug library will be changed after any current infusion (i.e., before the next infusion). - Additionally, partial updates of the drug database within the
medical device 14 are also made possible by the present invention. TheMMU 12 is supplied with a drug database that allows a user to update a single data item (row, column, or cell) in the database without re-writing the entire database. This provides faster processing and downloading times when modifying the drug database. - Further, the
Download Drug Library 44 program in theMMU 12 is designed to modify a medication library from theHIS 18 in such a way that only a single configuration of a single drug library is necessary to provide download information to multiple separate and differentmedical devices 14 where each device has unique parameters (different models, processors, computer architecture, software, binary format, or manufacturers, for example). In this embodiment, the configured drug library is designed so that only a subset of the configured drug library is specific for each unique type ofmedical device 14, and only the specific information is selected for transfer to eachmedical device 14. Additionally, pre-validation of the configured drug library is done through use of a rule set editor prior to sending from theMMU 12 to themedical device 14, and post-validation occurs where themedical device 14 confirms receipt of an acceptable drug library back to theMMU 12. - Further details on these additional related features can be found in commonly owned co-pending application entitled SYSTEM FOR MAINTAINING DRUG INFORMATION AND COMMUNICATING WITH MEDICATION DELIVERY DEVICES filed on Feb. 20, 2004, which is expressly incorporated herein in its entirety.
- With reference to
FIGS. 2 , 3, and 4A, theMonitor Pump 44 program in theMMU 12 and thecorresponding Monitor Pump 130 program in themedical device 14 operate to map the approximate or general physical location of eachmedical device 14 within the hospital environment and to enable a user to trigger a locator alarm to locate a particularmedical device 14. Additionally, the programming enabling the medical device locator would be located in anasset manager 64 portion of theMMU 12. - With reference to
FIG. 17 , theMMU 12 communicates with one or more (more preferably a plurality of)medical devices electronic network 76. The medical device ordevices electronic network 76 through one or more (more preferably a plurality of)access nodes CCAs medical device 14 can operate from anindividual access node 84 and be associated with a particular patient. Typically, there is one access node per room (101, 103, and 301), but it also is possible to have more than one access node per room and more than one room or CCA per access node. Additionally, as discussed above with regard toFIG. 4 , the connection between themedical devices access nodes computer system 254 is remotely located from theMMU 12 and themedical device 14 and communicates with theMMU 12 to permit auser 256 to activate theMonitor Pump 44 program in theMMU 12 and remotely activate thecorresponding Monitor Pump 130 program in themedical device 14. Thecomputer 254 can be located in a variety of locations, including but not limited to a nurse station or a biomedical technician area. - With reference to
FIG. 18 , the functional steps of theMonitor Pump 52 program in theMMU 12 and thecorresponding Monitor Pump 130 program in themedical device 14A are shown in operation with thecomputer 254. To begin to request a physical location for amedical device 14, the user 256 (not shown) enters a query for the location of amedical device 14A. Thecomputer 254 sends arequest device location 258 message to theMMU 12. TheMMU 12 in turn sends a request last usedaccess node 260 message to themedical device 14A. It is also contemplated that theMonitor Pump Program 130 can be operated with theinput device 32. - The
medical device 14A determines thelast access node 84A-84C used to connect with theelectronic network 76 atstep 262. A report of the last usedaccess node 264 is sent from themedical device 14 to theMMU 12. TheMMU 12 processes the report of the last usedaccess node 264 to determine the general physical location of the device atstep 266. Once the physical location of themedical device 14A is determined by theMMU 12, a reportphysical location 268 message is sent from theMMU 12 to thecomputer 254. Additionally, theMMU 12 tracks “change of infuser access node” events, when amedical device 14 begins to communicate through a differentnetwork access node 84. TheMMU 12 communicates the physical locations ofmedical devices 14 to theHIS 18. - If the
user 256 requires additional assistance in locating the particularmedical device 14A, theuser 256 can instruct thecomputer 254 to send a requestaudio location alarm 270 message to theMMU 12. TheMMU 12 in turn sends an orderaudio locator alarm 272 message to themedical device 14A. Themedical device 14A then activates an audio alarm atstep 274 to assist theuser 256 in locating themedical device 14A. The audio alarm activation can be delayed by a predetermined time to allow the user time to travel to the area of the last used access node. The audio alarm feature is useful in allowing the user to more precisely pinpoint the location of themedical device 14. The audio alarm feature is particularly useful if themedical device 14 is very close to other medical devices or has been moved to a storage closet or other location where it is not readily apparent visually. - Alternatively, the functional steps of the
Monitor Pump 44 program in theMMU 12 and the corresponding theMonitor Pump 130 program shown inFIG. 18 can be performed as a series of “push” steps instead of a series of “pull” steps (as shown inFIG. 18 ). In a “push” embodiment themedical device 14A periodically determines the last used access node and periodically reports the last used access node to theMMU 12 as a “here I am” signal. Likewise, theMMU 12 periodically determines the physical location of themedical device 14A based on thelast access node 84A used by themedical device 14, and periodically reports the physical location of themedical device 14A to theuser access device 254. Alternatively, theMMU 12 programming allows it to determine which ofaccess nodes 84 was the last access node used by the device 14 (step 259 indicated by a dashed line) and the MMU can report the general physical location of themedical device 14 to thecomputer 254 without requesting a report from themedical device 14. - In one embodiment described above, the association between
medical devices 14,patient 110,drug 100, and caregiver 114 (if present), is accomplished by swiping machine readable indicators on each of these elements of the PAN 113 (SeeFIG. 4 ). This association is made in software residing theMMU 12. Alternatively, the association is made in software residing in themedical device 14. With reference toFIG. 21 , in another embodiment, the association betweenmedical devices 14A,patient 110,drug 100, andcaregiver 114, is accomplished by “auto-association”. Auto-association is desirable in situations where the patient's wrist is not readily accessible (e.g. during surgery, or a neonate in an incubator). - In the auto-association embodiment, the
MMU 12 andmedical device 14A are designed to establish the patient as the focus of theMMS 10. In this embodiment, thepatient 110 is equipped with a machinereadable indicator 112A on a wristband, toe tag, badge or similar article. The machinereadable indicator 112A contains transmitter/receiver chip 278, capable of short-range transmission. The transmitter/receiver chip 278 is a low power RF Bluetooth™, a dedicated RF transmitter working with a PIC processor, or any other suitable transmitter/receiver. Thepatient 110 is fitted with the machinereadable indicator 112A at the time of admission. The unique ID number of the particular machinereadable indicator 112A is stored with an electronic patient record at theHIS 18 and henceMMU 12. TheMMU 12 is thereby notified of the particular machinereadable indicator 112A associated with theparticular patient 110. Additionally, it is contemplated, that any other machine readable indicator used with the present invention, may also contains transmitter/receiver chip capable of short-range transmission. For instance, the caregiver machinereadable indicator 116 and medication machinereadable indicator 102 may also be equipped with a transmitter/receiver chip. - Each
medical device 14A is also equipped with a transmitter/receiver chip 280A. Upon placing amedical device 14 at thepatient 110 bedside, within thePAN 113, the transmitter/receiver chip 280A of themedical device 14A “pings” by sending out a “request for patient” command to any transmitter/receiver chip 278 that is in the area. Each transmitter/receiver chip 278, which is in the area (usually about 0-10 meters, more preferably about 0-3 meters), replies to the ping by sending the transmitter/receiver chip 280 of themedical device 14A the unique ID number of the particular machinereadable indicator 112A. Upon receipt of a signal from the machinereadable indicator 112A, themedical device 14A places the ID number of the machinereadable indicator 112A in memory 126 (SeeFIG. 4A ) and also transmits the same to theMMU 12. Alternatively, the unique ID of theindicator 112A can be transmitted directly to anMMU 12 located in the area or indirectly through another route, including but not limited to themedical device 14. With reference toFIGS. 5 , 5A, 6 and 6A, theMMU 12Process Drug Order 46 program then checks the patient ID entered atstep 162 and the device/channel ID entered atstep 160 to ensure the correct match. TheMMU 12 associates themedical device 14A only to the identified patient based on the patient ID number sent to theMMU 12. Dissociating themedical device 14A from the patient is done based on a command from a user, or other method. - It should be noted, that the machine
readable indicator 112A (as well as the machine readable indicator 112), can include equipment for monitoring the wearer, and transmitting this monitored information to themedical device 14 and/or theMMU 12. - With reference back to
FIG. 21 , placing a secondmedical device 14B within thePAN 113 leads to a repeat of the same process. In this case the firstmedical device 14A “pings” any transmitter/receiver chip that is in the area. The transmitter/receiver chip 280B of the secondmedical device 14B replies to the ping by sending the transmitter/receiver chip 280A of the firstmedical device 14A the unique ID number of the particular machinereadable indicator 92B. Upon receipt of a signal from the machinereadable indicator 92B, the firstmedical device 14A places the ID number of the machinereadable indicator 92B in memory 126 (SeeFIG. 4A ) and also transmits the same to theMMU 12. The patient ID number is then sent from the firstmedical device 14A to the secondmedical device 14B. - An additional or alternative validation of the “right patient” can be accomplished by caregiver visual confirmation of the patient following the auto-association procedure described above in relation to
FIG. 21 , and is also applicable to the five-rights procedures described above with respect toFIGS. 5 , 5A, 6 and 6A. In this process, thepatient 110 is photographed with a digital camera (not shown) at the time of admission and the digital photo is stored with the electronic patient record at theHIS 18. When a medication order is requested for a specific patient, the digital photo is sent to theMMU 12 and upon completion of the association process, the digital photo is transmitted fromMMU 12 to themedical device 14 at thepatient 110 bedside. The image of thepatient 110 is sent to thedisplay 88 of themedical device 14, which is preferably a high resolution touch screen at least approximately 12 cm by 12 cm. The image of thepatient 110 is then placed on thedisplay 88 and thecaregiver 114 is prompted by thedisplay 88 to “Confirm Patient”. Thecaregiver 114 confirms a patient match upon visual comparison of thepatient 110 with the image on thedisplay 88. - Alternatively, the digital photo information alternatively can be stored on the
indicator receiver 178 thereof. The digital photo is transmitted to themedical device 14 when themedical device 14 has been associated with thepatient 110. - With reference to
FIG. 22 , another portion of the functional steps of theMonitor Pump 52 program in theMMU 12 and thecorresponding Monitor Pump 130 program in themedical device 14 are shown in operation with thecomputer 254. To begin to request a specific evaluation for the operation of a specificmedical device 14, or group ofmedical devices 14, the user 256 (not shown) enters a query for the operation evaluation of amedical device 14. Thecomputer 254 sends anoperation evaluation request 282 message to theMMU 12. TheMMU 12 in turn sends arequest operation data 284 message to themedical device 14. Themedical device 14 sends areport operation data 286 message (including but not limited to event logs, settings, CCA and utilization information) back to theMMU 12 atstep 286. TheMMU 12 processes thereport operation data 286 to generate an operational evaluation atstep 288. Once the operational evaluation of themedical device 14 is determined by theMMU 12, a reportoperational evaluation 290 message is sent from theMMU 12 to thecomputer 254. - Alternatively, the functional steps of the
Monitor Pump 44 program in theMMU 12 and the corresponding theMonitor Pump 130 program shown inFIG. 22 can be performed as a series of “push” steps instead of a series of “pull” steps (as shown inFIG. 22 ). In a “push” embodiment themedical device 14 periodically reports the operation data to theMMU 12. Likewise, theMMU 12 periodically processes thereport operation data 286 to generate an operational evaluation atstep 288, and periodically reports the operational evaluation of themedical device 14 to theuser access device 254 atstep 290. - The automated operational evaluation described above, provides a method of evaluating
medical device 14 while in operation; thus eliminating the need to postpone evaluation until themedical device 14 is taken out of use. The real-time data collection capabilities of theMMU 12 andMonitor Pump 52 program allow theMMU 12 to determinemedical device 14 performance including advanced statistical operations in order to provide quality control data sorting algorithms and aggregation of data and control for a PAN 113 (not shown). For example, consider aMMS 10 where multiple discreet single or multiple channel medical devices 14 (or channels) are connected to a single patient 110 (not shown). TheMonitor Pump 52 program collects allmedical device 14 information in real-time and then comparesmedical device 14 statistics to one another. Likewise, infuser channels can be compared to other infuser channels within the same multiple channel medical device or in other devices.Monitor Pump 52 program therefore can detect a “bad actor” if any one of themedical devices 14 or channels is operating at a level statistically lower or higher than the othermedical devices 14 or channels. This statistical determination can be made by collecting and comparing the mean and standard deviation of appropriate data elements. This statistical determination can be performed selectably on any of the data that is routinely collected by themedical device 14 event log and any that may be acquired from the instrumentation of themedical device 14. For example, statistical determinations could be performed based on air alarm events, occlusion alarm events, battery usage data, screen response time, etc.MMU 12 then sends the operational evaluation message (including any relevant quality control alert) to an appropriate area (including but not limited to the computer 254) in a form that is appropriate for the particular alert (usually including but not limited to graphically or audibly). Additionally, operational evaluation message (including any relevant quality control alert) can be sent to any number of individuals including but not limited to the caregiver, a biomedical engineer, caregiver supervisor, and a doctor. - With reference to
FIG. 17 , themedical device 14 is designed as a multi-processor, where many features are not hardwired, but instead can be uniquely configured based on rules, the location of themedical device 14, etc. For example, themedical device 14 is designed to allow a customized display based on the Clinical Care Area (CCA) 253A or 253B themedical device 14 is located in and/or assigned too. An example of this would be theMMU 12 instructing themedical device 14 to have a display of a particular color or warning tones/volumes based on the location of themedical device 14 in the hospital, time of day, caregiver information, patient information, or the type of medication being supplied. For example, the patient information could include a patient diagnosis and/or a disease state. For example, alarm volumes and display brightness can be set lower in the pediatric clinical care area or at night than in the emergency room clinical care area or during the daytime. - With reference to
FIG. 4 , similarly, themedical device 14 is designed to allow a customized display based on user information supplied to the medical device 14 (from theMMU 12 for example). Such user based customized display could include changes in language preference, limited access depending on the security level of thecaregiver 114, customizing the displayed information based on the training level of the individual or recent interactions therewith, and/or customizing an automated help function based on training level of the user or recent interactions therewith. TheMMU 12 presents a user with a default view based on the user's role. TheMMU 12 permits a default view for each role to be configurable in terms of the data detail presented. TheMMU 12 allows a user with the appropriate privilege to set a particular presented view as the preferred or default starting view for that user following login. TheMMU 12 allows a user to access databases and details based on role and privilege. TheMMU 12 allows a user to access other views based on role and privilege. Each presented view includes: a common means of navigating among views, both summary and detail, access to privacy, security, and other policy statements, access to online help, and a logoff capability. Additionally, an emergency bypass (such as a pass-code) would be provided to bypass security restrictions in case of an emergency. - With reference to
FIG. 22 , another portion of the functional steps of theMonitor Pump 52 program in theMMU 12 and thecorresponding Monitor Pump 130 program in themedical device 14 are shown in operation with thecomputer 254. TheMMU 12 tracks and records actions taken by thecaregiver 114 based on operational data reported from one or moremedical devices 14. Just as theMMU 12 is capable of generating an operational evaluation of eachmedical device 14, theMMU 12 can likewise generating an operational evaluation of each caregiver 114 (not shown) atstep 288. This operational evaluation of eachcaregiver 114 includes records of each caregiver's 114 actions (or, in some cases, inactions), sorting of these actions based on given criteria, and tracking of any trends in these actions. In general, these records of actions include any task lists, medication administration records, treatments, and other actions associated with the caregiver's 114 responsibilities. Such records of actions may combine medications administered, treatments, and other actions for multiple patients under the care of an individual caregiver.MMU 12 then sends the operational evaluation message (including any relevant quality control alert) to an appropriate area (e.g. to thecomputer 254 or caregiver supervisor's computer (not shown)) in a form that is appropriate for the particular alert (usually including but not limited to graphically or audibly). Additionally, operational evaluation message (including any relevant quality control alert) can be sent to any number of individuals including but not limited to the caregiver, a biomedical engineer, caregiver supervisor, and a doctor. - Additionally, the
MMU 12 can instruct themedical device 14 to customizeddisplay 88 based on the operational evaluation message. Thus, thedisplay 88 is adjusted by theMMU 12 based a determination that thecaregiver 114 requires additional or different information displayed to improvecaregiver 114 interaction with themedical device 14. For example, detailed step by step instructions can be placed ondisplay 88, where theMMU 12 recognizes acaregiver 114 who is not familiar with a particular therapy, using thedisplay 88 as the instruction means. Likewise, where theMMU 12 recognizes that acaregiver 114 has limited experience programming the medical device 14 (caregiver experience) or in previous interactions had made errors programming a particular function (caregiver error rate) or was a statistically longer than the norm at programming a particular function (caregiver response time), theMMU 12 instructs themedical device 14 to display pertinent training information. - In another embodiment best understood with reference to
FIG. 4A , themedical device 14 is designed to act as a web server for theinput device 32 or other similar devices within proximity to themedical device 14. In this embodiment,medical device 14 is equipped to supply theinput device 32 web browser (client) with medical device related information as well as non-medical device related information such as task lists, etc. Additionally, themedical device 14 displays a dual function screen having both a pump monitor screen portion and a web browser screen portion. Further, supplying themedical device 14 as a web server permits a remote web browser to associate with themedical device 14 to configure themedical device 14 or run diagnostics on themedical device 14. - With reference to
FIGS. 2 and 4A , another portion of theMonitor Pump 52 program in theMMU 12 and thecorresponding Monitor Pump 130 program in themedical device 14 is directed to cloning betweenmedical devices 14. Themedical devices 14 are designed to have wireless data sharing between eachmedical device 14 sufficient to permit cloning of all patient information between eachmedical device 14, and/or the multi-sequencing of a set ofmedical devices 14 without a hardwired connection. TheMMU 12 adjudicates this cloning and/or multi-sequencing. -
FIGS. 23-30 assist in illustrating another set of embodiments of the invention. As best understood in view ofFIGS. 1 and 23 , thepatient link 20 is eliminated from the system in this set of embodiments and aninput device 32, including but not limited to a point-of-care (POC) device such as a personal digital assistant (PDA) equipped with a scanner or machine label reader, connects or communicates with the HIS 18 and theMMU 12 of theMMS 10. With reference toFIGS. 23-24 , another input means 26 or device such as a POE (physician order entry) computer connects and communicates with the HIS 18 in order to allow a physician to deliver a medication order prescribed for a particular patient. Although it may not always be the case, the medication order is generally routed through the pharmacy and the pharmacy information system orPhIS 24 so that the medication can be physically prepared and, if necessary, repackaged, reconstituted, and labeled with identification for delivery. The medication order typically includes instructions regarding the drug (drug name, concentration, and amount such as volume, quantity, or mass), the patient, the route of administration, and the prescribed time(s) of administration or execution. - The
MMU 12 includes aprocessing unit 36 and at least one input/output device 38 as discussed above. When multiple input/output devices are used, one input/output device 38 is provided for monitoring theMMU 12 and medical devices 14 (pumps or infusers and lines or channels thereof, for example) connected to the MMU, entering clinical or expert decision rules, entering or editing data to configure theMMU 12, running various programs thereon, and extracting reports. InFIG. 24 , theprocessing unit 36 is a computer server and aseparate MMU console 38 connects or communicates with it. TheMMU console 38 is physically located in a biomedical engineering area, although other locations including but not limited to a nursing station, security desk, administrative area, or physician's desk would be possible. Another input/output device 38A in the form of a drug library editor (DLE) console connects or communicates with theprocessing unit 36 to enter, edit, import and export data relating to the drug library. Although many locations within the health care facility are possible without detracting from the invention, theDLE console 38A is physically located in the pharmacy under the control of a licensed pharmacist. One skilled in the art will appreciate that a standard personal or laptop computer can function as both theprocessing unit 36 and one or more of the input/output devices output devices -
FIGS. 2 , 4, 4A, 25 and 26 illustrate basic components of the system, depict the flow of certain data within the system, and depict the steps for automatically programming and monitoring themedical device 14, an infuser or multi-channel pump in this example. The entry of the prescribed drug order into the HIS 18 by the physician (FIG. 24 ) causes amedication container 100 to be selected or prepared by a pharmacist in the pharmacy using information from thePhIS 24 and theHIS 18. Many modern drug containers come from the manufacturer pre-filled and now include machine-readable labels with drug identification information thereon. Alternatively, the pharmacist provides drug identification information on a PhIS computer generated machine-readable label for attachment to the container. Typically, drug identification information includes the drug name, concentration, and amount in volume or mass. The manufacturer or pharmacist may supplement this basic label information with additional information including manufacturer name, expiration date, production lot, patient identification, and other information in a format readable by a machine or a human as required by the health care facility, government agencies or industry practice. When ready, thecontainer 100 with itslabel 102 is provided to thecaregiver 114 or placed in an appropriate storage area for later administration to the patient. - As the time of scheduled administration approaches, the
caregiver 114 enters caregiver specific identification (caregiver ID) with theinput device 32, for example by scanning the machine-readable indicator 116 on their badge or similar article atstep 300, to verify that thecaregiver 114 is an authorized user. Atstep 302, which is optional, theinput device 32 gets from the HIS 18 a list of task or orders thecaregiver 114 is authorized and scheduled to perform on various patients. This task list is presented on the screen of the input device orPDA 32. Alternatively, in other embodiments, it may be unnecessary to scan theindicator 116 on the caregiver badge because the hospital has elected not to track such information or the caregiver has already identified themselves in another manner before using theinput device 32, including but not limited to logging in to the system or device with an appropriate login user ID and password combination or using a designated authorization code. - At the bedside, in
step 304, thecaregiver 114 enters the patient-specific identification information by using theinput device 32 to enter, read or scan the machine-readable indicator 112 associated with thepatient 110. Instep 306, theinput device 32 gets, displays, selects, or highlights a list of orders or tasks associated with thespecific patient 110 scanned. Instep 308, thecaregiver 114 uses theinput device 32 to scan thelabel 102 on thedrug container 100, which triggers the input device to select, highlight or display a specific order or task on its display screen. Instep 310, theinput device 32 uses the drug ID to get the details of the specific order from theHIS 18. - In
step 312, thecaregiver 114 uses theinput device 32 to enter, scan or read the machine-readable channel/infuser ID indicator channel medical device 14 to be used to dispense the order. If the appropriate channel/infuser has been selected and scanned, theinput device 32 submits the delivery order to theMMU 12 atstep 314. Alternatively, the HIS 18 can submit the order directly to theMMU 12, preferably after confirmation by thecaregiver 114 at thePDA 32. At any rate, prior to submission of the medication delivery order to theMMU 12 and themedical device 14, up to seven “rights” of medication management have been matched, verified, or validated as correct. The right caregiver will be administering the right drug to the right patient at the right time, in the right dosage, through the right route/device, and through the right device channel. - One skilled in the art will appreciate that the pre-submission steps 300-312 can be done in any order necessary to conform to hospital practices and desired workflow. For example, the
caregiver 114 can scan the drug container label 102 (step 308) before scanning the patient ID 112 (step 304).Step 304, which includes entering thepatient ID 112, may be done prior to thestep 300 of entering thecaregiver ID 116. In that case, for security and patient privacy purposes, the system would delay the display of the order list for the patient until after the caregiver's authorization has been verified. Although it is contemplated that theHIS 18 is the most efficient place to perform the above date comparisons, one skilled in the art will recognize that the necessary comparisons between the scanned caregiver, patient, drug and device specific delivery information and the originally entered infusion order may take place at thePDA 32, theMMU 12, theHIS 18 or some combination thereof. - The
MMU 12 translates the order atstep 316 into a format that themedical device 14 can recognize. Then theMMU 12 submits the order to themedical device 14 atstep 318. Instep 320, themedical device 14 confirms the order with the MMU. The pump can automatically confirm the order or, more preferably, a caregiver can verify and confirm the order at the pump. Themedical device 14 communicates the status of the infusion to theMMU 12 in real-time or at periodic intervals instep 322. As desired by the caregiver or other authorized users, the input device orPDA 32 can poll theMMU 12 for the status of the infusion atstep 324. TheMMU 12 can respond to this request, polling, or “pull” of information atstep 326 as illustrated by the dashed line inFIG. 26 , or thepolling step 324 can be eliminated andMMU 12 can “push” the infusion status to thePDA 32 or another computer associated with the system at predetermined times or stages of infusion completion. ThePDA 32 can share the infusion status data with the HIS 18 or the HIS 18 can receive the data from theMMU 12. - From
FIGS. 2 , 24, 25 and 30, it will be understood that theMMS 10 can include aMMU 12 and aDLE user interface 37 and adrug library database 39 formulated and editable using a conventional database management software platform such as SQL Server or SQL Desktop Engine by Microsoft of Redmond, Wash., USA. The drug library editor communicates with theMMU 12 and performs various functions related to the drug library, including but not limited to importing, maintaining or editing, and exporting the final drug library (FDL). The drug library can be stored in a local ornetwork storage location 40, 328, with local storage being understood to be in a memory orstorage medium 40 of the MMU or DLE and network storage 328 being understood to be in a location remote from the MMU or DLE and connected thereto by the electronic network 76 (FIG. 4 ). TheMMU 12 includes aweb browser 41 for producing various predetermined and user customizable views and reports. TheMMU 12 further includes abusiness logic unit 43 and areporting engine 45. Thelogic unit 43 andreporting engine 45 communicate with and interact with theweb browser 41 and aMMU database 47 formulated using any conventional database management software, such as Microsoft SQL Server 2000. When theMMU 12 andDLE 38A are deployed on separate machines, as shown inFIG. 30 , the drug library can be edited in theDLE 38A and the updated or final drug library version (FDL) can be exported intostorage 40, 328 and then imported in theMMU 12 for eventual download to medical devices. Utilizing separate machines or terminals for theMMU console 38 and theDLE console 38A is advantageous in that control, maintenance and editing of the drug library can be done by licensed pharmacists or doctors in one physical location, while monitoring of theMMU 12 and thus thepumps 14 in communication with theMMU 12 can be done by less costly caregivers in another physical location, such in the patient's ward where they can respond quickly to any problems. Alternatively, thestorage 40, 328 can be a database that is shared by theMMU 12 and theDLE MMU console 38 and theDLE console 38A can still be in two separate locations and connected to the same common database, which can be stored on any machine in the network, including but not limited to on the same machine asMMU console 38 orDLE console 38A, for exporting a drug library from DLE toMMU 12. This would allow the export/import of the drug library from DLE to MMU to be done with or without user intervention. - Referring to
FIG. 27 , theMMU 12 of this invention allows auser 330 to select one or moremedical devices 14, such as infusers or pumps, atstep 332 and launch or initiate a drug library download atstep 334. TheMMU 12 downloads a drug library to a communication engine ornetwork interface 122 associated with theinfuser 14. Although hard-wired communication is possible, theMMU 12 and theinterface 122 preferably communicate wirelessly. Although other locations are possible, theinterface 122 is preferably attached to or, more preferably, internal to the infuser 14 (“internal” should be understood as having a majority of its circuit board residing inside the housing of the infuser). Theinterface 122 communicates the status of the drug library download back to theMMU 12 atstep 338, reporting whether any errors were encounter or verifying that the download was successfully received. As mentioned above with respect toFIG. 4A , the infuser or pump 14 includes theinterface 122 that includes or communicates with acache memory 126A to store the new drug library information so thepump 14 may continue to use an existing drug library to complete an infusion. Atstep 340, theinterface 122 notifies theinfuser 14 that a drug library update has been received. An alert or notice, in visual or audible form, that a drug library update has been received may be communicated to the infuser user interface. A triggering event atstep 342, including but not limited to the consent of acaregiver 114, causes the new drug library to be pulled from thecache memory 126A, which is associated with theinterface 122 and pump 14, instep 344. Thus, the new drug library replaces the existing active drug library in the infuser when the triggering event occurs. Theinfuser 14 also reports its status, including which active drug library it is using, to theMMU 12 through the network interface atsteps pump 14 and the interactions of thecaregiver 114 with it are uploaded from thepump 14 to theMMU 12 instep 350. After the logs have been uploaded to theMMU 12, thenetwork interface 122 may erase the logs in thepump 14 atstep 352, if desired, to save space in the memory of themedical device 14. - Similarly, as best understood in view of
FIGS. 2 and 4A , theMMU 12 includesrespective programs medical device 14 includesrespective programs pump software programs processing unit 36 of one or more medical devices. Thus, when the manufacturer releases a new version of operating system software with various enhancements for themedical device 14, the new code can efficiently be loaded onto machines in the field, as an alternative to being returned to the factory for upgrade. The managedrug map programs MMU 12 andmedical device 14 to recognize and cross-reference drug information from a variety of drug manufacturers, HIS vendors and other sources, for example, including but not limited to Abbott Laboratories, Hospira, Inc., Cerner Multum, First Data Bank and other similar sources. - One skilled in the art will appreciate that drug library, pump software, or drug map downloads as described above are “pushed” from the
MMU 12 to themedical device 14. Alternatively, theMMU 12 only manages the latest version of the information and any one of those downloads can be “pulled” or initiated by the user at the user interface on themedical device 14, using thenetwork interface 122 as a pass through device or as an intermediate cache device. Of course, themedical device 14 could also be programmed to automatically pull the most recent information from theMMU 12 at startup or under other predetermined conditions, including but not limited to a specific day, date, time of day, etc., without operator input. -
FIG. 28 shows a couple of possible ways theMMU 12 can receive uploads regarding the status of an infusion. In the upper half ofFIG. 28 , the information about the status of an infusion is pushed from theinfuser 14 to theMMU 12 through thenetwork interface 122 insteps FIG. 28 , thenetwork interface 122 pulls information by querying thepump 14 about the status of the infusion atstep 358. Thepump 14 responds to this call by providing instep 360 the status of the infusion, which is then sent to theMMU 12 instep 362. Although such steps are not shown in order to avoid overcomplicating the figures with alternative or optional steps, one skilled in the art will understand that either of the two status update processes shown inFIG. 28 and described above can be preceded by the step of theMMU 12 querying or polling thepump 14 throughnetwork interface 122 for its status. - Similarly,
FIG. 29 illustrates a couple of possible ways theMMU 12 can receive event logs with detailed information regarding the actions of thepump 14 and the interactions of thecaregiver 114 with it. The event log information can include, but is not limited to, pump status, pump activity, alerts, alarms, and caregiver activity such as keystrokes and alarm overrides. In the upper half ofFIG. 29 , the event log information is pushed from theinfuser 14 to theMMU 12 through thenetwork interface 122 insteps FIG. 28 , thenetwork interface 122 pulls event log information by querying thepump 14 atstep 366. Thepump 14 responds to this call by providing instep 368 the event log information, which is then sent to theMMU 12 instep 370. Although such steps are not shown in order to avoid overcomplicating the figures with alternative or optional steps, one skilled in the art will understand that either of the two event log upload processes shown inFIG. 29 and described above can be preceded by the step of theMMU 12 querying, requesting, or polling thepump 14 throughnetwork interface 122 for its event log. - Referring again to
FIG. 24 , the flow of information in the present invention is summarized. As mentioned earlier, the information can be transmitted wirelessly, by hard-wired connection of the components, or by some combination of hard-wired and wireless connections. As shown and discussed above relative toFIG. 4 , theHIS 18 andMMU 12 can be hard-wired and stationary, while it is preferable that the point-of-care (POC) input device or means 32 and themedical device 14 be mobile and equipped to transmit and receive communication wirelessly. The point ofcare input device 32 can be personal digital assistant (PDA), a notebook or laptop computer, a tabletop or cart-mounted personal computer, a bar code point-of-care (BPOC) scanning device, or other similar active or passive data input means. For example, in the embodiment disclosed inFIG. 24 , the POC input device is a PDA equipped with a bar code scanner. - The physician enters or inputs a medication (infusion) order into the HIS 18 through means of the physician order entry (POE)
computer 26. The medication order specifies or prescribes that a specific patient is to receive a particular dosage of a specific medication or drug at a particular time via a prescribed administration route. An authorizedcaregiver 114 uses thePOC device 32 to provide caregiver identification and to request or receive a list of tasks to be accomplished. The list may include medication orders for various patients under the caregiver's care. The caregiver enters or scans the machine-readable indicia 112 on apatient 110 with thePOC device 32 and is able to access a list of one or more medication orders for the specific patient scanned. Thecaregiver 114 enters or scans the machine-readable indicia 102 on thedrug container 100 and the machine-readable indicia infusion pump 14 to be used for the infusion. Thecaregiver 114 can then confirm withPOC device 32 and the HIS 18 that the information scanned matches the medication order. ThePOC device 32 transmits a medication delivery order including but not limited to some or all of the identification information discussed above and an infusion rate to theMMU 12. - The
MMU 12 translates the simple infusion rate of the delivery order into delivery programming code or information suitable for automatically programming the designatedpump 14 and further checks the delivery order and delivery programming code against a variety of drug library parameters (including but not limited to hard and/or soft limits for drug delivery rates), patient-specific safety factors, and clinical decision support rules. TheMMU 12 can be configured by the user at the MMU console to monitor the status of thepump 14 and the infusion (including alarms, event logs, and pump user interface inputs), generate reports, and control the distribution of drug library and operating code updates to one or more pumps 14. A drug library editor deployed as a part of theMMU 12, itsconsole 38, or on aseparate computer 38A, enables the user to import, export and edit whole drug libraries and individual drug library values to control and customize a drug library according to hospital preferences. - The
MMU 12 saves the caregiver time by automatically populating or programming data entry fields in thepump 14 that previously had to be entered manually. Themedication management system 10 of this invention enhances patient safety by minimizing manual entries. Thesystem 10 also enhances patient safety by screening drug delivery orders for conformance with established hospital practices, expert or clinical decision support rules and recommendations before (more preferably immediately before) thepump 14 begins to execute the order. Thesystem 10 can provide alerts in various locations, including but not limited to at thePOC device 32 or at themedical device 14, when the clinical decision rules are not met. The alerts can take many possible forms, including but not limited to visible or audible alarms. Thecaregiver 114 is provided with a least one and preferably several opportunities to catch a medication error before it happens. For example, thecaregiver 114 can confirm the order at thePOC device 32 and/or before pressing the start button on thepump 14. The system is flexible enough to permit human interventions and overrides, but tracks such events for documentation purposes. - Whereas the invention has been shown and described in connection with the embodiments thereof, it will be understood that many modifications, substitutions, and additions may be made which are within the intended broad scope of the following claims. From the foregoing, it can be seen that the present invention accomplishes at least all of the stated objectives.
Claims (7)
1. A medication administration system comprising:
a medication administration pump having a user interface and a CPU, said user interface configured to facilitate programming of said medication administration device, said CPU configured to operate as a web server, said user interface further configured to enable a user to access web-based information.
2. A medication administration system in accordance with claim 1 , wherein said user interface comprises a screen display, said screen display configured to display both a pump monitor screen portion and a web browser screen portion.
3. A medication administration system in accordance with claim 2 , wherein said screen display is configured to display both said pump monitor screen portion and said web browser screen portion simultaneously.
4. A medication administration system in accordance with claim 2 , wherein said screen display is configured to display said pump monitor screen portion separately from said web browser screen portion.
5. A medication administration system in accordance with claim 1 , said system further comprising a housing containing said medication administration pump, said CPU disposed within an interior of said housing, said user interface disposed on an exterior of said housing.
6. A medication administration system in accordance with claim 1 , wherein said CPU is configured to control operation of said medication administration pump, and wherein said user interface and said CPU are operatively connected such that user operating instructions can be programmed into said CPU through said user interface.
7. A medication administration system in accordance with claim 1 , wherein said user interface and said CPU are operatively connected such that user web requests can be entered into said CPU through said user interface.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/639,485 US20100130933A1 (en) | 2003-10-07 | 2009-12-16 | Medication managment system |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US50940403P | 2003-10-07 | 2003-10-07 | |
US52758303P | 2003-12-05 | 2003-12-05 | |
US10/783,641 US20060100907A1 (en) | 2003-10-07 | 2004-02-20 | Medication management system |
US10/930,358 US7895053B2 (en) | 2003-10-07 | 2004-08-31 | Medication management system |
US12/639,485 US20100130933A1 (en) | 2003-10-07 | 2009-12-16 | Medication managment system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/930,358 Continuation US7895053B2 (en) | 2003-10-07 | 2004-08-31 | Medication management system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100130933A1 true US20100130933A1 (en) | 2010-05-27 |
Family
ID=46302716
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/930,358 Active 2027-05-20 US7895053B2 (en) | 2003-10-07 | 2004-08-31 | Medication management system |
US12/639,485 Abandoned US20100130933A1 (en) | 2003-10-07 | 2009-12-16 | Medication managment system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/930,358 Active 2027-05-20 US7895053B2 (en) | 2003-10-07 | 2004-08-31 | Medication management system |
Country Status (1)
Country | Link |
---|---|
US (2) | US7895053B2 (en) |
Cited By (78)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080271010A1 (en) * | 2007-04-18 | 2008-10-30 | Bernd Scholler | Method and device for updating medical apparatus |
US20100249529A1 (en) * | 2008-11-13 | 2010-09-30 | National Taiwan University | Pain Monitoring Apparatus and Methods Thereof |
US20110313789A1 (en) * | 2010-01-22 | 2011-12-22 | Deka Products Limited Partnership | Electronic patient monitoring system |
US20110319813A1 (en) * | 2010-02-05 | 2011-12-29 | Deka Products Limited Partnership | Infusion pump apparatus, method and system |
US20120098668A1 (en) * | 2010-10-22 | 2012-04-26 | Peng Chen | Infusion monitoring alarm and method for monitoring and alarming for intravenous infusion |
US8287495B2 (en) | 2009-07-30 | 2012-10-16 | Tandem Diabetes Care, Inc. | Infusion pump system with disposable cartridge having pressure venting and pressure feedback |
US20130297330A1 (en) * | 2010-01-22 | 2013-11-07 | Deka Products Limited Partnership | System, Method, and Apparatus for Electroinic Patient Care |
WO2015047595A1 (en) * | 2013-09-27 | 2015-04-02 | Smiths Medical Asd, Inc. | Infusion pump with touchless user interface and related methods |
WO2016004088A1 (en) | 2014-06-30 | 2016-01-07 | Hospira, Inc. | Infusion pump error display |
US9242043B2 (en) | 2013-03-15 | 2016-01-26 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
US9486571B2 (en) | 2013-12-26 | 2016-11-08 | Tandem Diabetes Care, Inc. | Safety processor for wireless control of a drug delivery device |
US9594875B2 (en) | 2011-10-21 | 2017-03-14 | Hospira, Inc. | Medical device update system |
US9669160B2 (en) | 2014-07-30 | 2017-06-06 | Tandem Diabetes Care, Inc. | Temporary suspension for closed-loop medicament therapy |
US9737656B2 (en) | 2013-12-26 | 2017-08-22 | Tandem Diabetes Care, Inc. | Integration of infusion pump with remote electronic device |
US9814835B2 (en) | 2012-06-07 | 2017-11-14 | Tandem Diabetes Care, Inc. | Device and method for training users of ambulatory medical devices |
US9833177B2 (en) | 2007-05-30 | 2017-12-05 | Tandem Diabetes Care, Inc. | Insulin pump based expert system |
US9931276B2 (en) | 2009-07-29 | 2018-04-03 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US9962486B2 (en) | 2013-03-14 | 2018-05-08 | Tandem Diabetes Care, Inc. | System and method for detecting occlusions in an infusion pump |
US10016559B2 (en) | 2009-12-04 | 2018-07-10 | Smiths Medical Asd, Inc. | Advanced step therapy delivery for an ambulatory infusion pump and system |
US10016561B2 (en) | 2013-03-15 | 2018-07-10 | Tandem Diabetes Care, Inc. | Clinical variable determination |
US10022498B2 (en) | 2011-12-16 | 2018-07-17 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US10042986B2 (en) | 2013-11-19 | 2018-08-07 | Icu Medical, Inc. | Infusion pump automation system and method |
US10049768B2 (en) | 2002-02-28 | 2018-08-14 | Tandem Diabetes Care, Inc. | Programmable insulin pump |
US10052049B2 (en) | 2008-01-07 | 2018-08-21 | Tandem Diabetes Care, Inc. | Infusion pump with blood glucose alert delay |
US10166328B2 (en) | 2013-05-29 | 2019-01-01 | Icu Medical, Inc. | Infusion system which utilizes one or more sensors and additional information to make an air determination regarding the infusion system |
US10188849B2 (en) | 2015-12-04 | 2019-01-29 | Icu Medical, Inc. | Systems, methods, and components for transferring medical fluids |
US10242060B2 (en) | 2006-10-16 | 2019-03-26 | Icu Medical, Inc. | System and method for comparing and utilizing activity information and configuration information from multiple medical device management systems |
US10242159B2 (en) | 2010-01-22 | 2019-03-26 | Deka Products Limited Partnership | System and apparatus for electronic patient care |
US10238801B2 (en) | 2009-04-17 | 2019-03-26 | Icu Medical, Inc. | System and method for configuring a rule set for medical event management and responses |
US10238799B2 (en) | 2014-09-15 | 2019-03-26 | Icu Medical, Inc. | Matching delayed infusion auto-programs with manually entered infusion programs |
US10258736B2 (en) | 2012-05-17 | 2019-04-16 | Tandem Diabetes Care, Inc. | Systems including vial adapter for fluid transfer |
US10311972B2 (en) | 2013-11-11 | 2019-06-04 | Icu Medical, Inc. | Medical device system performance index |
US10314974B2 (en) | 2014-06-16 | 2019-06-11 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US10333843B2 (en) | 2013-03-06 | 2019-06-25 | Icu Medical, Inc. | Medical device communication method |
US10342917B2 (en) | 2014-02-28 | 2019-07-09 | Icu Medical, Inc. | Infusion system and method which utilizes dual wavelength optical air-in-line detection |
US10357606B2 (en) | 2013-03-13 | 2019-07-23 | Tandem Diabetes Care, Inc. | System and method for integration of insulin pumps and continuous glucose monitoring |
US10357607B2 (en) | 2007-05-24 | 2019-07-23 | Tandem Diabetes Care, Inc. | Correction factor testing using frequent blood glucose input |
US10430761B2 (en) | 2011-08-19 | 2019-10-01 | Icu Medical, Inc. | Systems and methods for a graphical interface including a graphical representation of medical data |
US10434246B2 (en) | 2003-10-07 | 2019-10-08 | Icu Medical, Inc. | Medication management system |
US10453157B2 (en) | 2010-01-22 | 2019-10-22 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US10463788B2 (en) | 2012-07-31 | 2019-11-05 | Icu Medical, Inc. | Patient care system for critical medications |
USD874644S1 (en) | 2016-07-19 | 2020-02-04 | Icu Medical, Inc. | Medical fluid transfer system |
US10569016B2 (en) | 2015-12-29 | 2020-02-25 | Tandem Diabetes Care, Inc. | System and method for switching between closed loop and open loop control of an ambulatory infusion pump |
US10578474B2 (en) | 2012-03-30 | 2020-03-03 | Icu Medical, Inc. | Air detection system and method for detecting air in a pump of an infusion system |
US10596316B2 (en) | 2013-05-29 | 2020-03-24 | Icu Medical, Inc. | Infusion system and method of use which prevents over-saturation of an analog-to-digital converter |
US10635784B2 (en) | 2007-12-18 | 2020-04-28 | Icu Medical, Inc. | User interface improvements for medical devices |
US10656894B2 (en) | 2017-12-27 | 2020-05-19 | Icu Medical, Inc. | Synchronized display of screen content on networked devices |
US10692595B2 (en) | 2018-07-26 | 2020-06-23 | Icu Medical, Inc. | Drug library dynamic version management |
US10741280B2 (en) | 2018-07-17 | 2020-08-11 | Icu Medical, Inc. | Tagging pump messages with identifiers that facilitate restructuring |
US10765799B2 (en) | 2013-09-20 | 2020-09-08 | Icu Medical, Inc. | Fail-safe drug infusion therapy system |
US10850024B2 (en) | 2015-03-02 | 2020-12-01 | Icu Medical, Inc. | Infusion system, device, and method having advanced infusion features |
US10861592B2 (en) | 2018-07-17 | 2020-12-08 | Icu Medical, Inc. | Reducing infusion pump network congestion by staggering updates |
US10874793B2 (en) | 2013-05-24 | 2020-12-29 | Icu Medical, Inc. | Multi-sensor infusion system for detecting air or an occlusion in the infusion system |
US10898641B2 (en) | 2014-04-30 | 2021-01-26 | Icu Medical, Inc. | Patient care system with conditional alarm forwarding |
US10911515B2 (en) | 2012-05-24 | 2021-02-02 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
WO2021050893A1 (en) * | 2019-09-11 | 2021-03-18 | Electronic Health Record Data, Inc. | Processing pharmaceutical prescriptions in real time using a clinical analytical message data file |
US11135360B1 (en) | 2020-12-07 | 2021-10-05 | Icu Medical, Inc. | Concurrent infusion with common line auto flush |
US11164672B2 (en) | 2010-01-22 | 2021-11-02 | Deka Products Limited Partnership | System and apparatus for electronic patient care |
US11210611B2 (en) | 2011-12-21 | 2021-12-28 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US11235100B2 (en) | 2003-11-13 | 2022-02-01 | Icu Medical, Inc. | System for maintaining drug information and communicating with medication delivery devices |
US11244745B2 (en) | 2010-01-22 | 2022-02-08 | Deka Products Limited Partnership | Computer-implemented method, system, and apparatus for electronic patient care |
US11246985B2 (en) | 2016-05-13 | 2022-02-15 | Icu Medical, Inc. | Infusion pump system and method with common line auto flush |
US11278671B2 (en) | 2019-12-04 | 2022-03-22 | Icu Medical, Inc. | Infusion pump with safety sequence keypad |
US11291763B2 (en) | 2007-03-13 | 2022-04-05 | Tandem Diabetes Care, Inc. | Basal rate testing using frequent blood glucose input |
US11309070B2 (en) | 2018-07-26 | 2022-04-19 | Icu Medical, Inc. | Drug library manager with customized worksheets |
US11328805B2 (en) | 2018-07-17 | 2022-05-10 | Icu Medical, Inc. | Reducing infusion pump network congestion by staggering updates |
US11324888B2 (en) | 2016-06-10 | 2022-05-10 | Icu Medical, Inc. | Acoustic flow sensor for continuous medication flow measurements and feedback control of infusion |
US11344668B2 (en) | 2014-12-19 | 2022-05-31 | Icu Medical, Inc. | Infusion system with concurrent TPN/insulin infusion |
US11344673B2 (en) | 2014-05-29 | 2022-05-31 | Icu Medical, Inc. | Infusion system and pump with configurable closed loop delivery rate catch-up |
US11439571B2 (en) | 2011-12-22 | 2022-09-13 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US11488549B2 (en) | 2008-05-02 | 2022-11-01 | Tandem Diabetes Care, Inc. | Display for pump |
US11574737B2 (en) | 2016-07-14 | 2023-02-07 | Icu Medical, Inc. | Multi-communication path selection and security system for a medical device |
US11571508B2 (en) | 2013-08-30 | 2023-02-07 | Icu Medical, Inc. | System and method of monitoring and managing a remote infusion regimen |
US11587669B2 (en) | 2018-07-17 | 2023-02-21 | Icu Medical, Inc. | Passing authentication token to authorize access to rest calls via web sockets |
US11605468B2 (en) | 2015-05-26 | 2023-03-14 | Icu Medical, Inc. | Infusion pump system and method with multiple drug library editor source capability |
US11660392B2 (en) | 2010-02-05 | 2023-05-30 | Deka Products Limited Partnership | Devices, methods and systems for wireless control of medical devices |
US11881307B2 (en) | 2012-05-24 | 2024-01-23 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US11883361B2 (en) | 2020-07-21 | 2024-01-30 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
Families Citing this family (85)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6322502B1 (en) * | 1996-12-30 | 2001-11-27 | Imd Soft Ltd. | Medical information system |
US10062457B2 (en) | 2012-07-26 | 2018-08-28 | Carefusion 303, Inc. | Predictive notifications for adverse patient events |
NZ522631A (en) | 2000-05-18 | 2004-07-30 | Alaris Medical Inc | Distributed remote asset and medication management drug delivery system |
US10353856B2 (en) | 2011-03-17 | 2019-07-16 | Carefusion 303, Inc. | Scalable communication system |
US7860583B2 (en) | 2004-08-25 | 2010-12-28 | Carefusion 303, Inc. | System and method for dynamically adjusting patient therapy |
US9069887B2 (en) | 2000-05-18 | 2015-06-30 | Carefusion 303, Inc. | Patient-specific medication management system |
US9427520B2 (en) | 2005-02-11 | 2016-08-30 | Carefusion 303, Inc. | Management of pending medication orders |
US9741001B2 (en) | 2000-05-18 | 2017-08-22 | Carefusion 303, Inc. | Predictive medication safety |
US11087873B2 (en) | 2000-05-18 | 2021-08-10 | Carefusion 303, Inc. | Context-aware healthcare notification system |
US7457804B2 (en) * | 2002-05-10 | 2008-11-25 | Medrad, Inc. | System and method for automated benchmarking for the recognition of best medical practices and products and for establishing standards for medical procedures |
US7848935B2 (en) * | 2003-01-31 | 2010-12-07 | I.M.D. Soft Ltd. | Medical information event manager |
US8620678B2 (en) | 2003-01-31 | 2013-12-31 | Imd Soft Ltd. | Medical information query system |
US7182738B2 (en) | 2003-04-23 | 2007-02-27 | Marctec, Llc | Patient monitoring apparatus and method for orthosis and other devices |
EP1751704A4 (en) * | 2004-01-09 | 2008-12-24 | Imd Soft Ltd | Clinical data database system and method for a critical care and/or hospital environment |
DE102004023634B4 (en) * | 2004-05-10 | 2007-09-27 | Siemens Ag | Method for checking the completeness and consistency of an information library |
US7927313B2 (en) | 2004-05-27 | 2011-04-19 | Baxter International Inc. | Medical device configuration based on recognition of identification information |
SG158906A1 (en) * | 2005-02-11 | 2010-02-26 | Cardinal Health 303 Inc | Identification system and method for medication management |
US20110010087A1 (en) * | 2005-10-24 | 2011-01-13 | CellTrak Technologies, Inc. | Home Health Point-of-Care and Administration System |
WO2007084807A1 (en) * | 2006-01-18 | 2007-07-26 | Koninklijke Philips Electronics, N.V. | Automatic and secure configuration of wireless medical networks |
US8560345B2 (en) * | 2006-03-28 | 2013-10-15 | Hospira, Inc. | Medication administration and management system and method |
US8369944B2 (en) | 2007-06-06 | 2013-02-05 | Zoll Medical Corporation | Wearable defibrillator with audio input/output |
US8660860B2 (en) * | 2007-11-09 | 2014-02-25 | Hospira, Inc. | System and method for synchronizing medication configuration information among systems containing medication configuration information |
US9393362B2 (en) * | 2007-12-18 | 2016-07-19 | Hospira, Inc. | Infusion pump with configurable screen settings |
JP4788927B2 (en) * | 2007-12-26 | 2011-10-05 | 日本光電工業株式会社 | Monitoring network system |
KR101587301B1 (en) * | 2008-04-01 | 2016-01-21 | 스미스 메디칼 에이에스디, 인크. | Security features for a medical infusion pump |
US10089443B2 (en) | 2012-05-15 | 2018-10-02 | Baxter International Inc. | Home medical device systems and methods for therapy prescription and tracking, servicing and inventory |
US8600777B2 (en) * | 2008-08-28 | 2013-12-03 | I.M.D. Soft Ltd. | Monitoring patient conditions |
US20110264043A1 (en) * | 2008-11-07 | 2011-10-27 | Curlin Medical Inc. | Method of loading a drug library into an infusion pump |
US8352290B2 (en) | 2008-11-07 | 2013-01-08 | Curlin Medical Inc. | Method of automatically programming an infusion pump |
US9687601B2 (en) * | 2008-11-10 | 2017-06-27 | Curlin Medical Inc. | Tool for interfacing with an infusion pump |
US8777895B2 (en) * | 2009-01-06 | 2014-07-15 | Hospira, Inc. | System and method for authorized medication delivery |
US20100268037A1 (en) * | 2009-01-15 | 2010-10-21 | 360Fresh, Inc. | Event-driven, dynamic patient scorecard |
US10441710B2 (en) * | 2009-02-09 | 2019-10-15 | Baxter International Inc. | Infusion pump and method to prevent titration errors in infusion therapies |
US8315885B2 (en) * | 2009-04-14 | 2012-11-20 | Baxter International Inc. | Therapy management development platform |
US20100268552A1 (en) * | 2009-04-21 | 2010-10-21 | Ido Schoenberg | Content Integration Service |
US20110137680A1 (en) * | 2009-12-01 | 2011-06-09 | Patientsafe Solutions, Inc. | Hospital administration system and method |
US20110153343A1 (en) * | 2009-12-22 | 2011-06-23 | Carefusion 303, Inc. | Adaptable medical workflow system |
US9677555B2 (en) | 2011-12-21 | 2017-06-13 | Deka Products Limited Partnership | System, method, and apparatus for infusing fluid |
US10380321B2 (en) * | 2010-01-22 | 2019-08-13 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US10493289B2 (en) | 2010-07-09 | 2019-12-03 | Zoll Medical Corporation | System and method for conserving power in a medical device |
US8904214B2 (en) | 2010-07-09 | 2014-12-02 | Zoll Medical Corporation | System and method for conserving power in a medical device |
US20120215560A1 (en) | 2010-07-21 | 2012-08-23 | dbMotion Ltd. | System and methods for facilitating computerized interactions with emrs |
US8600486B2 (en) | 2011-03-25 | 2013-12-03 | Zoll Medical Corporation | Method of detecting signal clipping in a wearable ambulatory medical device |
US8897860B2 (en) | 2011-03-25 | 2014-11-25 | Zoll Medical Corporation | Selection of optimal channel for rate determination |
EP2727071A4 (en) | 2011-07-01 | 2015-08-12 | Baxter Corp Englewood | Systems and methods for intelligent patient interface device |
US10726088B1 (en) | 2011-08-12 | 2020-07-28 | Allscripts Software, Llc | Computing system for presenting supplemental content in context |
US9675756B2 (en) | 2011-12-21 | 2017-06-13 | Deka Products Limited Partnership | Apparatus for infusing fluid |
US11295846B2 (en) | 2011-12-21 | 2022-04-05 | Deka Products Limited Partnership | System, method, and apparatus for infusing fluid |
US9878171B2 (en) | 2012-03-02 | 2018-01-30 | Zoll Medical Corporation | Systems and methods for configuring a wearable medical monitoring and/or treatment device |
US9675753B2 (en) * | 2012-04-16 | 2017-06-13 | Atlanta Biomedical Corp. | Safe drug delivery system |
WO2013181607A1 (en) | 2012-05-31 | 2013-12-05 | Zoll Medical Corporation | Systems and methods for detecting health disorders |
DE102012111480A1 (en) * | 2012-06-22 | 2013-12-24 | B. Braun Melsungen Ag | Method and device for testing at least one fluid |
US10650917B2 (en) * | 2012-07-02 | 2020-05-12 | Carefusion 303, Inc. | Patient-device association system |
EP2880573A2 (en) * | 2012-08-06 | 2015-06-10 | Koninklijke Philips N.V. | Graphical user interface for obtaining a record of a medical treatment event in real time |
EP2936360A2 (en) * | 2012-12-21 | 2015-10-28 | DEKA Products Limited Partnership | Computer-implemented method, system, and apparatus for electronic patient care |
JP6401183B2 (en) * | 2012-12-21 | 2018-10-03 | デカ・プロダクツ・リミテッド・パートナーシップ | System, method and apparatus for data communication |
EP2948204B1 (en) | 2013-01-28 | 2021-08-25 | Smiths Medical ASD, Inc. | Medication safety devices and methods |
US11182728B2 (en) | 2013-01-30 | 2021-11-23 | Carefusion 303, Inc. | Medication workflow management |
US10430554B2 (en) | 2013-05-23 | 2019-10-01 | Carefusion 303, Inc. | Medication preparation queue |
US9649431B2 (en) | 2013-02-05 | 2017-05-16 | Ivenix, Inc. | Automated programming of infusion therapy |
CN105308646B (en) | 2013-02-05 | 2019-08-13 | 艾韦尼克斯股份有限公司 | Utilize the system and method for associated medical device management |
KR102040695B1 (en) * | 2013-02-08 | 2019-11-06 | 백스터 코포레이션 잉글우드 | Code for patient care device configuration |
WO2014159280A1 (en) * | 2013-03-13 | 2014-10-02 | Carefusion 303, Inc. | Patient-specific medication management system |
WO2014164565A1 (en) | 2013-03-13 | 2014-10-09 | Carefusion 303, Inc. | Predictive medication safety |
US10456523B2 (en) | 2013-03-14 | 2019-10-29 | Carefusion 303, Inc. | Management of care area transitions of intravenous infusions |
CN105492070A (en) | 2013-06-28 | 2016-04-13 | 卓尔医疗公司 | Systems and methods of delivering therapy using an ambulatory medical device |
US20150133861A1 (en) | 2013-11-11 | 2015-05-14 | Kevin P. McLennan | Thermal management system and method for medical devices |
JP6360332B2 (en) * | 2014-03-20 | 2018-07-18 | テルモ株式会社 | Feed pump |
US10143795B2 (en) | 2014-08-18 | 2018-12-04 | Icu Medical, Inc. | Intravenous pole integrated power, control, and communication system and method for an infusion pump |
CN106794302B (en) | 2014-09-18 | 2020-03-20 | 德卡产品有限公司 | Device and method for infusing fluid through a tube by heating the tube appropriately |
AU2016267763B2 (en) | 2015-05-26 | 2021-07-08 | Icu Medical, Inc. | Disposable infusion fluid delivery device for programmable large volume drug delivery |
US10140423B2 (en) * | 2015-08-31 | 2018-11-27 | Cerner Innovation, Inc. | Modifying characteristics of a medical device utilizing a mobile device |
US11101805B2 (en) * | 2016-03-07 | 2021-08-24 | Experian Health, Inc. | Prescription adherence assistance |
US11617538B2 (en) | 2016-03-14 | 2023-04-04 | Zoll Medical Corporation | Proximity based processing systems and methods |
EP3422355B1 (en) * | 2017-06-28 | 2021-08-18 | Fenwal, Inc. | System and method of synchronizing medical device databases |
EP3646329A1 (en) | 2017-06-30 | 2020-05-06 | Fresenius Vial SAS | System for providing multiple infusions to a patient |
CA3075484A1 (en) | 2017-09-12 | 2019-03-21 | Smiths Medical Asd, Inc. | User experience for infusion pumps |
EP3794602A1 (en) * | 2018-05-14 | 2021-03-24 | Fresenius Vial SAS | Systems and methods for controlling a plurality of drug libraries |
KR20210042378A (en) | 2018-08-16 | 2021-04-19 | 데카 프로덕츠 리미티드 파트너쉽 | Medical pump |
US11568984B2 (en) | 2018-09-28 | 2023-01-31 | Zoll Medical Corporation | Systems and methods for device inventory management and tracking |
USD939079S1 (en) | 2019-08-22 | 2021-12-21 | Icu Medical, Inc. | Infusion pump |
US11115476B1 (en) * | 2020-04-22 | 2021-09-07 | Drb Systems, Llc | System for and method of controlling operations of a car wash |
EP4162497A1 (en) * | 2020-06-04 | 2023-04-12 | Becton, Dickinson and Company | System, method, and computer program product for medication administration |
CN112733060B (en) * | 2021-01-13 | 2023-12-01 | 中南大学 | Cache replacement method and device based on session cluster prediction and computer equipment |
CN113875626A (en) * | 2021-09-28 | 2022-01-04 | 河南牧原智能科技有限公司 | Breed drinking water medicine system |
Citations (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5897498A (en) * | 1996-09-25 | 1999-04-27 | Atl Ultrasound, Inc. | Ultrasonic diagnostic imaging system with electronic message communications capability |
US6115390A (en) * | 1997-10-14 | 2000-09-05 | Lucent Technologies, Inc. | Bandwidth reservation and collision resolution method for multiple access communication networks where remote hosts send reservation requests to a base station for randomly chosen minislots |
US6208974B1 (en) * | 1997-12-30 | 2001-03-27 | Medical Management International, Inc. | Method and system for managing wellness plans for a medical care practice |
US6226277B1 (en) * | 1997-10-14 | 2001-05-01 | Lucent Technologies Inc. | Method for admitting new connections based on usage priorities in a multiple access system for communications networks |
US6285665B1 (en) * | 1997-10-14 | 2001-09-04 | Lucent Technologies Inc. | Method for establishment of the power level for uplink data transmission in a multiple access system for communications networks |
US6327254B1 (en) * | 1997-10-14 | 2001-12-04 | Lucent Technologies Inc. | Method for bandwidth sharing in a multiple access system for communications networks |
US6346886B1 (en) * | 1996-12-20 | 2002-02-12 | Carlos De La Huerga | Electronic identification apparatus |
US20020040282A1 (en) * | 2000-03-22 | 2002-04-04 | Bailey Thomas C. | Drug monitoring and alerting system |
US6377548B1 (en) * | 1997-10-14 | 2002-04-23 | Lucent Technologies Inc. | Method for admitting new connections based on measured quantities in a multiple access system for communications networks |
US20020082728A1 (en) * | 2000-10-05 | 2002-06-27 | Friedrich Mueller | Extracorporeal blood treatment system |
US20020103675A1 (en) * | 1999-11-29 | 2002-08-01 | John Vanelli | Apparatus and method for providing consolidated medical information |
US6469991B1 (en) * | 1997-10-14 | 2002-10-22 | Lucent Technologies Inc. | Method for overload control in a multiple access system for communication networks |
US6567416B1 (en) * | 1997-10-14 | 2003-05-20 | Lucent Technologies Inc. | Method for access control in a multiple access system for communications networks |
US6587034B1 (en) * | 1998-01-05 | 2003-07-01 | Symbol Technologies, Inc. | Data communication device |
US20030140929A1 (en) * | 2002-01-29 | 2003-07-31 | Wilkes Gordon J. | Infusion therapy bar coding system and method |
US20030217962A1 (en) * | 2002-05-24 | 2003-11-27 | Robert Childers | Medical fluid pump |
US6659947B1 (en) * | 2000-07-13 | 2003-12-09 | Ge Medical Systems Information Technologies, Inc. | Wireless LAN architecture for integrated time-critical and non-time-critical services within medical facilities |
US6674403B2 (en) * | 2001-09-05 | 2004-01-06 | Newbury Networks, Inc. | Position detection and location tracking in a wireless network |
US6839753B2 (en) * | 2001-02-23 | 2005-01-04 | Cardiopulmonary Corporation | Network monitoring systems for medical devices |
US6958677B1 (en) * | 2000-03-31 | 2005-10-25 | Ge Medical Systems Information Technologies, Inc. | Object location monitoring system |
US6969352B2 (en) * | 1999-06-22 | 2005-11-29 | Teratech Corporation | Ultrasound probe with integrated electronics |
US7038584B2 (en) * | 2000-03-31 | 2006-05-02 | Ge Medical Systems Information Technologies, Inc. | Object location monitoring within buildings |
US20060106649A1 (en) * | 1995-03-13 | 2006-05-18 | Alaris Medical Systems, Inc. | Method for programming a patient care device |
US7092943B2 (en) * | 2002-03-01 | 2006-08-15 | Enterasys Networks, Inc. | Location based data |
US7117041B2 (en) * | 1995-05-15 | 2006-10-03 | Cardinal Health 303, Inc. | System and method for programming a clinical device |
US7136645B2 (en) * | 1998-10-09 | 2006-11-14 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US7154397B2 (en) * | 2001-08-03 | 2006-12-26 | Hill Rom Services, Inc. | Patient point-of-care computer system |
US7181493B2 (en) * | 2003-12-23 | 2007-02-20 | Unisys Corporation | Platform independent model-based framework for exchanging information in the justice system |
US7216802B1 (en) * | 1997-10-21 | 2007-05-15 | Carlos De La Huerga | Method and apparatus for verifying information |
US7224979B2 (en) * | 2001-05-03 | 2007-05-29 | Symantec Corporation | Location-aware service proxies in a short-range wireless environment |
US7236936B2 (en) * | 1999-12-01 | 2007-06-26 | B. Braun Medical, Inc. | Security infusion pump with bar code reader |
US7275156B2 (en) * | 2002-08-30 | 2007-09-25 | Xerox Corporation | Method and apparatus for establishing and using a secure credential infrastructure |
US7289815B2 (en) * | 2002-08-15 | 2007-10-30 | International Business Machines Corporation | Transponder subsystem for supporting location awareness in wireless networks |
US7293107B1 (en) * | 1998-10-09 | 2007-11-06 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US7295119B2 (en) * | 2003-01-22 | 2007-11-13 | Wireless Valley Communications, Inc. | System and method for indicating the presence or physical location of persons or devices in a site specific representation of a physical environment |
US7301451B2 (en) * | 2003-12-31 | 2007-11-27 | Ge Medical Systems Information Technologies, Inc. | Notification alarm transfer methods, system, and device |
US7327705B2 (en) * | 2002-07-03 | 2008-02-05 | Massachusetts Institute Of Technology | Hybrid wireless network for data collection and distribution |
US7343224B2 (en) * | 2001-12-31 | 2008-03-11 | B. Braun Medical Inc. | Pharmaceutical compounding systems and methods and information management system for same |
US7346025B2 (en) * | 2003-02-28 | 2008-03-18 | Lucent Technologies Inc. | Portable wireless gateway |
US7369897B2 (en) * | 2001-04-19 | 2008-05-06 | Neuro And Cardiac Technologies, Llc | Method and system of remotely controlling electrical pulses provided to nerve tissue(s) by an implanted stimulator system for neuromodulation therapies |
US7464040B2 (en) * | 1999-12-18 | 2008-12-09 | Raymond Anthony Joao | Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information |
US7490048B2 (en) * | 1999-12-18 | 2009-02-10 | Raymond Anthony Joao | Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information |
Family Cites Families (90)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5338157B1 (en) | 1992-09-09 | 1999-11-02 | Sims Deltec Inc | Systems and methods for communicating with ambulat |
US5669877A (en) | 1994-03-07 | 1997-09-23 | Sims Deltec, Inc. | Systems and methods for automated testing of medical equipment |
US6241704B1 (en) | 1901-11-22 | 2001-06-05 | Sims Deltec, Inc. | Drug pump systems and methods |
US5935099A (en) | 1992-09-09 | 1999-08-10 | Sims Deltec, Inc. | Drug pump systems and methods |
US4731051A (en) | 1979-04-27 | 1988-03-15 | The Johns Hopkins University | Programmable control means for providing safe and controlled medication infusion |
IL74236A (en) | 1984-02-08 | 1990-07-12 | Omni Flow Inc | Infusion system having plural fluid input ports and at least one patient output port |
US4885778A (en) | 1984-11-30 | 1989-12-05 | Weiss Kenneth P | Method and apparatus for synchronizing generation of separate, free running, time dependent equipment |
US5088981A (en) | 1985-01-18 | 1992-02-18 | Howson David C | Safety enhanced device and method for effecting application of a therapeutic agent |
US4908017A (en) | 1985-05-14 | 1990-03-13 | Ivion Corporation | Failsafe apparatus and method for effecting syringe drive |
US4785969A (en) | 1986-11-10 | 1988-11-22 | Pyxis Corporation | Medication dispensing system |
US5153827A (en) | 1989-01-30 | 1992-10-06 | Omni-Flow, Inc. | An infusion management and pumping system having an alarm handling system |
US4978335A (en) | 1989-09-29 | 1990-12-18 | Medex, Inc. | Infusion pump with bar code input to computer |
US5097505A (en) | 1989-10-31 | 1992-03-17 | Securities Dynamics Technologies, Inc. | Method and apparatus for secure identification and verification |
US5455851A (en) | 1993-07-02 | 1995-10-03 | Executone Information Systems, Inc. | System for identifying object locations |
US5594786A (en) | 1990-07-27 | 1997-01-14 | Executone Information Systems, Inc. | Patient care and communication system |
US5465082A (en) | 1990-07-27 | 1995-11-07 | Executone Information Systems, Inc. | Apparatus for automating routine communication in a facility |
US5161222A (en) | 1990-08-20 | 1992-11-03 | Human Microprocessing, Inc. | Software engine having an adaptable driver for interpreting variables produced by a plurality of sensors |
WO1992004806A1 (en) | 1990-08-31 | 1992-03-19 | The General Hospital Corporation | A network for portable patient monitoring devices |
AU3329793A (en) | 1991-12-20 | 1993-07-28 | Abbott Laboratories | Infusion pump security system |
JP3071929B2 (en) | 1992-02-21 | 2000-07-31 | 株式会社東芝 | Medical support system and medical support method |
US6283761B1 (en) | 1992-09-08 | 2001-09-04 | Raymond Anthony Joao | Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information |
US5788669A (en) | 1995-11-22 | 1998-08-04 | Sims Deltec, Inc. | Pump tracking system |
DE69329774T2 (en) | 1992-10-15 | 2001-06-21 | Gen Hospital Corp | INFUSION PUMP WITH ELECTRONICALLY LOADABLE MEDICINE LIBRARY |
US5997476A (en) | 1997-03-28 | 1999-12-07 | Health Hero Network, Inc. | Networked system for interactive communication and remote monitoring of individuals |
US5832448A (en) | 1996-10-16 | 1998-11-03 | Health Hero Network | Multiple patient monitoring system for proactive health management |
US5897493A (en) | 1997-03-28 | 1999-04-27 | Health Hero Network, Inc. | Monitoring system for remotely querying individuals |
US5378231A (en) | 1992-11-25 | 1995-01-03 | Abbott Laboratories | Automated drug infusion system |
NL9300143A (en) * | 1993-01-26 | 1994-08-16 | Lely Nv C Van Der | Milking machine. |
WO1994022242A1 (en) | 1993-03-24 | 1994-09-29 | Universal Electronics, Inc. | Infrared remote control device for a personal digital assistant |
WO1995002426A1 (en) | 1993-07-13 | 1995-01-26 | Sims Deltec, Inc. | Medical pump and method of programming |
US5417222A (en) | 1994-01-21 | 1995-05-23 | Hewlett-Packard Company | Patient monitoring system |
US5630710A (en) | 1994-03-09 | 1997-05-20 | Baxter International Inc. | Ambulatory infusion pump |
FR2717919B1 (en) | 1994-03-28 | 1996-06-21 | Ensyma Sa | Medical decision support system and device for administering at least one drug. |
DE4415896A1 (en) | 1994-05-05 | 1995-11-09 | Boehringer Mannheim Gmbh | Analysis system for monitoring the concentration of an analyte in the blood of a patient |
CA2125300C (en) | 1994-05-11 | 1999-10-12 | Douglas J. Ballantyne | Method and apparatus for the electronic distribution of medical information and patient services |
JPH07319971A (en) | 1994-05-19 | 1995-12-08 | At & T Global Inf Solutions Internatl Inc | Remotely accessible medical treatment network |
US6725200B1 (en) | 1994-09-13 | 2004-04-20 | Irmgard Rost | Personal data archive system |
US5522798A (en) | 1994-10-17 | 1996-06-04 | Abbott Laboratories | Control of a multi-channel drug infusion pump using a pharmacokinetic model |
US5573506A (en) | 1994-11-25 | 1996-11-12 | Block Medical, Inc. | Remotely programmable infusion system |
US5814015A (en) | 1995-02-24 | 1998-09-29 | Harvard Clinical Technology, Inc. | Infusion pump for at least one syringe |
US5836910A (en) | 1995-03-13 | 1998-11-17 | Alaris Medical Systems, Inc. | Method and apparatus for logical addressing in a modular patient care system |
US5781442A (en) | 1995-05-15 | 1998-07-14 | Alaris Medical Systems, Inc. | System and method for collecting data and managing patient care |
US5620608A (en) | 1995-06-07 | 1997-04-15 | Cobe Laboratories, Inc. | Information entry validation system and method for a dialysis machine |
US5850344A (en) | 1995-08-14 | 1998-12-15 | Profile Systems, Llc | Medication dispensing and timing system |
US5836312A (en) | 1996-01-02 | 1998-11-17 | Moore; Steven Jerome | Computer-assisted system and method for adjudging the effect of consumable intakes on physiological parameters |
US5975081A (en) | 1996-06-21 | 1999-11-02 | Northrop Grumman Corporation | Self-contained transportable life support system |
US6182667B1 (en) | 1996-06-21 | 2001-02-06 | Integrated Medical Systems, Inc. | Display for transportable life support system |
US6234176B1 (en) | 1996-06-21 | 2001-05-22 | Integrated Medical Systems, Inc. | Data logger for transportable life support system |
US5924074A (en) | 1996-09-27 | 1999-07-13 | Azron Incorporated | Electronic medical records system |
US6003006A (en) | 1996-12-09 | 1999-12-14 | Pyxis Corporation | System of drug distribution to health care providers |
US6021392A (en) | 1996-12-09 | 2000-02-01 | Pyxis Corporation | System and method for drug management |
US5827179A (en) | 1997-02-28 | 1998-10-27 | Qrs Diagnostic, Llc | Personal computer card for collection for real-time biological data |
US6159147A (en) | 1997-02-28 | 2000-12-12 | Qrs Diagnostics, Llc | Personal computer card for collection of real-time biological data |
US5960085A (en) | 1997-04-14 | 1999-09-28 | De La Huerga; Carlos | Security badge for automated access control and secure data gathering |
US6270455B1 (en) | 1997-03-28 | 2001-08-07 | Health Hero Network, Inc. | Networked system for interactive communications and remote monitoring of drug delivery |
TW357517B (en) | 1997-05-29 | 1999-05-01 | Koji Akai | Monitoring system |
US5915240A (en) | 1997-06-12 | 1999-06-22 | Karpf; Ronald S. | Computer system and method for accessing medical information over a network |
US6012034A (en) | 1997-08-18 | 2000-01-04 | Becton, Dickinson And Company | System and method for selecting an intravenous device |
US6189105B1 (en) | 1998-02-20 | 2001-02-13 | Lucent Technologies, Inc. | Proximity detection of valid computer user |
US6195589B1 (en) | 1998-03-09 | 2001-02-27 | 3Com Corporation | Personal data assistant with remote control capabilities |
US5971594A (en) | 1998-03-24 | 1999-10-26 | Innovative Medical Devices, Inc. | Medication dispensing system |
US5963136A (en) | 1998-07-15 | 1999-10-05 | O'brien; Charles Terrence | Interactive prescription compliance and life safety system |
US6104295A (en) | 1998-07-20 | 2000-08-15 | Versus Technology, Inc. | Electronic band tag and method of storing ID information therein |
US6248067B1 (en) | 1999-02-05 | 2001-06-19 | Minimed Inc. | Analyte sensor and holter-type monitor system and method of using the same |
US6558320B1 (en) | 2000-01-20 | 2003-05-06 | Medtronic Minimed, Inc. | Handheld personal data assistant (PDA) with a medical device and method of using the same |
WO2000019887A1 (en) | 1998-10-08 | 2000-04-13 | Minimed Inc. | Telemetered characteristic monitor system |
US6073106A (en) | 1998-10-30 | 2000-06-06 | Nehdc, Inc. | Method of managing and controlling access to personal information |
DE19904090C2 (en) | 1999-02-02 | 2003-06-05 | Wolf Gmbh Richard | Method and device for the automatic control and management of medical devices and systems |
US6312378B1 (en) | 1999-06-03 | 2001-11-06 | Cardiac Intelligence Corporation | System and method for automated collection and analysis of patient information retrieved from an implantable medical device for remote patient care |
US6752787B1 (en) | 1999-06-08 | 2004-06-22 | Medtronic Minimed, Inc., | Cost-sensitive application infusion device |
DE19932147A1 (en) | 1999-07-12 | 2001-01-25 | Insys Ges Fuer Microcontroller | Electronic system for detecting, monitoring patient data has transponders with stored identification codes, polling device for connection to central or non-central hospital computer |
US6221011B1 (en) | 1999-07-26 | 2001-04-24 | Cardiac Intelligence Corporation | System and method for determining a reference baseline of individual patient status for use in an automated collection and analysis patient care system |
WO2001013317A2 (en) | 1999-08-13 | 2001-02-22 | Kocher Jean Pierre | Method and apparatus for scanning of food and medicine to provide outputs relative to a user profile |
US6494831B1 (en) | 1999-09-03 | 2002-12-17 | Ge Medical Technology Services, Inc. | Medical diagnostic system service connectivity method and apparatus |
US6640246B1 (en) | 1999-09-17 | 2003-10-28 | Ge Medical Systems Global Technology Company, Llc | Integrated computerized materials management system |
US7933780B2 (en) | 1999-10-22 | 2011-04-26 | Telaric, Llc | Method and apparatus for controlling an infusion pump or the like |
US6790198B1 (en) | 1999-12-01 | 2004-09-14 | B-Braun Medical, Inc. | Patient medication IV delivery pump with wireless communication to a hospital information management system |
US6602191B2 (en) | 1999-12-17 | 2003-08-05 | Q-Tec Systems Llp | Method and apparatus for health and disease management combining patient data monitoring with wireless internet connectivity |
DE29922736U1 (en) | 1999-12-24 | 2001-05-03 | Braun Melsungen Ag | Infusion device with several infusion pumps |
US20010037060A1 (en) | 2000-02-08 | 2001-11-01 | Thompson Richard P. | Web site for glucose monitoring |
DE20003469U1 (en) | 2000-02-23 | 2000-08-17 | Medical Communications Soft Un | Hand-held computer |
JP2001258858A (en) | 2000-03-17 | 2001-09-25 | Pioneer Electronic Corp | Health monitoring system |
FR2807542B1 (en) | 2000-04-06 | 2006-09-29 | Capsule Technologie | METHOD AND SYSTEM FOR COLLECTING AND DISSEMINATING DATA FROM DEVICES, IN PARTICULAR MEDICAL DEVICES |
NZ522631A (en) | 2000-05-18 | 2004-07-30 | Alaris Medical Inc | Distributed remote asset and medication management drug delivery system |
US6482158B2 (en) | 2000-05-19 | 2002-11-19 | Healthetech, Inc. | System and method of ultrasonic mammography |
US6589229B1 (en) | 2000-07-31 | 2003-07-08 | Becton, Dickinson And Company | Wearable, self-contained drug infusion device |
DE60134706D1 (en) | 2000-10-12 | 2008-08-21 | Ge Med Sys Information Tech | Mobile Clinical Information System |
US20030140928A1 (en) | 2002-01-29 | 2003-07-31 | Tuan Bui | Medical treatment verification system and method |
US20040064435A1 (en) | 2002-07-26 | 2004-04-01 | Ahmad-Maher Moubayed | Clinical assessment and diagnostic tool for use with peristaltic pump |
EP2284743A3 (en) | 2003-03-28 | 2013-08-14 | CareFusion 303, Inc. | Infusion data communication system |
-
2004
- 2004-08-31 US US10/930,358 patent/US7895053B2/en active Active
-
2009
- 2009-12-16 US US12/639,485 patent/US20100130933A1/en not_active Abandoned
Patent Citations (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060106649A1 (en) * | 1995-03-13 | 2006-05-18 | Alaris Medical Systems, Inc. | Method for programming a patient care device |
US7384410B2 (en) * | 1995-03-13 | 2008-06-10 | Cardinal Health 303, Inc. | System and method for managing patient care |
US7117041B2 (en) * | 1995-05-15 | 2006-10-03 | Cardinal Health 303, Inc. | System and method for programming a clinical device |
US5897498A (en) * | 1996-09-25 | 1999-04-27 | Atl Ultrasound, Inc. | Ultrasonic diagnostic imaging system with electronic message communications capability |
US6346886B1 (en) * | 1996-12-20 | 2002-02-12 | Carlos De La Huerga | Electronic identification apparatus |
US6327254B1 (en) * | 1997-10-14 | 2001-12-04 | Lucent Technologies Inc. | Method for bandwidth sharing in a multiple access system for communications networks |
US6285665B1 (en) * | 1997-10-14 | 2001-09-04 | Lucent Technologies Inc. | Method for establishment of the power level for uplink data transmission in a multiple access system for communications networks |
US6226277B1 (en) * | 1997-10-14 | 2001-05-01 | Lucent Technologies Inc. | Method for admitting new connections based on usage priorities in a multiple access system for communications networks |
US6377548B1 (en) * | 1997-10-14 | 2002-04-23 | Lucent Technologies Inc. | Method for admitting new connections based on measured quantities in a multiple access system for communications networks |
US6115390A (en) * | 1997-10-14 | 2000-09-05 | Lucent Technologies, Inc. | Bandwidth reservation and collision resolution method for multiple access communication networks where remote hosts send reservation requests to a base station for randomly chosen minislots |
US7197025B2 (en) * | 1997-10-14 | 2007-03-27 | Lucent Technologies Inc. | Method for paging a device in a wireless network |
US6469991B1 (en) * | 1997-10-14 | 2002-10-22 | Lucent Technologies Inc. | Method for overload control in a multiple access system for communication networks |
US6567416B1 (en) * | 1997-10-14 | 2003-05-20 | Lucent Technologies Inc. | Method for access control in a multiple access system for communications networks |
US7216802B1 (en) * | 1997-10-21 | 2007-05-15 | Carlos De La Huerga | Method and apparatus for verifying information |
US6208974B1 (en) * | 1997-12-30 | 2001-03-27 | Medical Management International, Inc. | Method and system for managing wellness plans for a medical care practice |
US6587034B1 (en) * | 1998-01-05 | 2003-07-01 | Symbol Technologies, Inc. | Data communication device |
US6859134B1 (en) * | 1998-01-05 | 2005-02-22 | Symbol Technologies, Inc. | Data communication device |
US7136645B2 (en) * | 1998-10-09 | 2006-11-14 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US7293107B1 (en) * | 1998-10-09 | 2007-11-06 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US6969352B2 (en) * | 1999-06-22 | 2005-11-29 | Teratech Corporation | Ultrasound probe with integrated electronics |
US20020103675A1 (en) * | 1999-11-29 | 2002-08-01 | John Vanelli | Apparatus and method for providing consolidated medical information |
US7236936B2 (en) * | 1999-12-01 | 2007-06-26 | B. Braun Medical, Inc. | Security infusion pump with bar code reader |
US7490048B2 (en) * | 1999-12-18 | 2009-02-10 | Raymond Anthony Joao | Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information |
US7464040B2 (en) * | 1999-12-18 | 2008-12-09 | Raymond Anthony Joao | Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information |
US20020040282A1 (en) * | 2000-03-22 | 2002-04-04 | Bailey Thomas C. | Drug monitoring and alerting system |
US6958677B1 (en) * | 2000-03-31 | 2005-10-25 | Ge Medical Systems Information Technologies, Inc. | Object location monitoring system |
US7038584B2 (en) * | 2000-03-31 | 2006-05-02 | Ge Medical Systems Information Technologies, Inc. | Object location monitoring within buildings |
US6659947B1 (en) * | 2000-07-13 | 2003-12-09 | Ge Medical Systems Information Technologies, Inc. | Wireless LAN architecture for integrated time-critical and non-time-critical services within medical facilities |
US7156807B2 (en) * | 2000-07-13 | 2007-01-02 | Ge Medical Systems Information Technologies, Inc. | Wireless LAN architecture for integrated time-critical and non-time-critical services within medical facilities |
US20020082728A1 (en) * | 2000-10-05 | 2002-06-27 | Friedrich Mueller | Extracorporeal blood treatment system |
US6839753B2 (en) * | 2001-02-23 | 2005-01-04 | Cardiopulmonary Corporation | Network monitoring systems for medical devices |
US7369897B2 (en) * | 2001-04-19 | 2008-05-06 | Neuro And Cardiac Technologies, Llc | Method and system of remotely controlling electrical pulses provided to nerve tissue(s) by an implanted stimulator system for neuromodulation therapies |
US7224979B2 (en) * | 2001-05-03 | 2007-05-29 | Symantec Corporation | Location-aware service proxies in a short-range wireless environment |
US7154397B2 (en) * | 2001-08-03 | 2006-12-26 | Hill Rom Services, Inc. | Patient point-of-care computer system |
US6674403B2 (en) * | 2001-09-05 | 2004-01-06 | Newbury Networks, Inc. | Position detection and location tracking in a wireless network |
US7343224B2 (en) * | 2001-12-31 | 2008-03-11 | B. Braun Medical Inc. | Pharmaceutical compounding systems and methods and information management system for same |
US20030140929A1 (en) * | 2002-01-29 | 2003-07-31 | Wilkes Gordon J. | Infusion therapy bar coding system and method |
US7092943B2 (en) * | 2002-03-01 | 2006-08-15 | Enterasys Networks, Inc. | Location based data |
US7295556B2 (en) * | 2002-03-01 | 2007-11-13 | Enterasys Networks, Inc. | Location discovery in a data network |
US20030217962A1 (en) * | 2002-05-24 | 2003-11-27 | Robert Childers | Medical fluid pump |
US7327705B2 (en) * | 2002-07-03 | 2008-02-05 | Massachusetts Institute Of Technology | Hybrid wireless network for data collection and distribution |
US7289815B2 (en) * | 2002-08-15 | 2007-10-30 | International Business Machines Corporation | Transponder subsystem for supporting location awareness in wireless networks |
US7275156B2 (en) * | 2002-08-30 | 2007-09-25 | Xerox Corporation | Method and apparatus for establishing and using a secure credential infrastructure |
US7295119B2 (en) * | 2003-01-22 | 2007-11-13 | Wireless Valley Communications, Inc. | System and method for indicating the presence or physical location of persons or devices in a site specific representation of a physical environment |
US7346025B2 (en) * | 2003-02-28 | 2008-03-18 | Lucent Technologies Inc. | Portable wireless gateway |
US7181493B2 (en) * | 2003-12-23 | 2007-02-20 | Unisys Corporation | Platform independent model-based framework for exchanging information in the justice system |
US7301451B2 (en) * | 2003-12-31 | 2007-11-27 | Ge Medical Systems Information Technologies, Inc. | Notification alarm transfer methods, system, and device |
Cited By (171)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10049768B2 (en) | 2002-02-28 | 2018-08-14 | Tandem Diabetes Care, Inc. | Programmable insulin pump |
US10434246B2 (en) | 2003-10-07 | 2019-10-08 | Icu Medical, Inc. | Medication management system |
US11235100B2 (en) | 2003-11-13 | 2022-02-01 | Icu Medical, Inc. | System for maintaining drug information and communicating with medication delivery devices |
US10242060B2 (en) | 2006-10-16 | 2019-03-26 | Icu Medical, Inc. | System and method for comparing and utilizing activity information and configuration information from multiple medical device management systems |
US11194810B2 (en) | 2006-10-16 | 2021-12-07 | Icu Medical, Inc. | System and method for comparing and utilizing activity information and configuration information from multiple device management systems |
US11291763B2 (en) | 2007-03-13 | 2022-04-05 | Tandem Diabetes Care, Inc. | Basal rate testing using frequent blood glucose input |
US20150006196A1 (en) * | 2007-04-18 | 2015-01-01 | Weinmann Geraete Fuer Medizin Gmbh & Co. Kg | Method and device for updating medical apparatus |
US20080271010A1 (en) * | 2007-04-18 | 2008-10-30 | Bernd Scholler | Method and device for updating medical apparatus |
US10939818B2 (en) * | 2007-04-18 | 2021-03-09 | Loewenstein Medical Technology S.A. | Method and device for updating medical apparatus |
US8863106B2 (en) * | 2007-04-18 | 2014-10-14 | Weinmann Gerate Fur Medizin Gmbh & Co. Kg | Method and device for updating medical apparatus |
US11257580B2 (en) | 2007-05-24 | 2022-02-22 | Tandem Diabetes Care, Inc. | Expert system for insulin pump therapy |
US10357607B2 (en) | 2007-05-24 | 2019-07-23 | Tandem Diabetes Care, Inc. | Correction factor testing using frequent blood glucose input |
US11848089B2 (en) | 2007-05-24 | 2023-12-19 | Tandem Diabetes Care, Inc. | Expert system for insulin pump therapy |
US10943687B2 (en) | 2007-05-24 | 2021-03-09 | Tandem Diabetes Care, Inc. | Expert system for insulin pump therapy |
US9833177B2 (en) | 2007-05-30 | 2017-12-05 | Tandem Diabetes Care, Inc. | Insulin pump based expert system |
US11576594B2 (en) | 2007-05-30 | 2023-02-14 | Tandem Diabetes Care, Inc. | Insulin pump based expert system |
US11298053B2 (en) | 2007-05-30 | 2022-04-12 | Tandem Diabetes Care, Inc. | Insulin pump based expert system |
US10635784B2 (en) | 2007-12-18 | 2020-04-28 | Icu Medical, Inc. | User interface improvements for medical devices |
US10052049B2 (en) | 2008-01-07 | 2018-08-21 | Tandem Diabetes Care, Inc. | Infusion pump with blood glucose alert delay |
US11302433B2 (en) | 2008-01-07 | 2022-04-12 | Tandem Diabetes Care, Inc. | Diabetes therapy coaching |
US11488549B2 (en) | 2008-05-02 | 2022-11-01 | Tandem Diabetes Care, Inc. | Display for pump |
US11580918B2 (en) | 2008-05-02 | 2023-02-14 | Tandem Diabetes Care, Inc. | Display for pump |
US20100249529A1 (en) * | 2008-11-13 | 2010-09-30 | National Taiwan University | Pain Monitoring Apparatus and Methods Thereof |
US11654237B2 (en) | 2009-04-17 | 2023-05-23 | Icu Medical, Inc. | System and method for configuring a rule set for medical event management and responses |
US11013861B2 (en) | 2009-04-17 | 2021-05-25 | Icu Medical, Inc. | System and method for configuring a rule set for medical event management and responses |
US10238801B2 (en) | 2009-04-17 | 2019-03-26 | Icu Medical, Inc. | System and method for configuring a rule set for medical event management and responses |
US11806308B2 (en) | 2009-07-29 | 2023-11-07 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US9931276B2 (en) | 2009-07-29 | 2018-04-03 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US11007119B2 (en) | 2009-07-29 | 2021-05-18 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US10314765B2 (en) | 2009-07-29 | 2019-06-11 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US8287495B2 (en) | 2009-07-30 | 2012-10-16 | Tandem Diabetes Care, Inc. | Infusion pump system with disposable cartridge having pressure venting and pressure feedback |
US8298184B2 (en) | 2009-07-30 | 2012-10-30 | Tandem Diabetes Care, Inc. | Infusion pump system with disposable cartridge having pressure venting and pressure feedback |
US8758323B2 (en) | 2009-07-30 | 2014-06-24 | Tandem Diabetes Care, Inc. | Infusion pump system with disposable cartridge having pressure venting and pressure feedback |
US8926561B2 (en) | 2009-07-30 | 2015-01-06 | Tandem Diabetes Care, Inc. | Infusion pump system with disposable cartridge having pressure venting and pressure feedback |
US9211377B2 (en) | 2009-07-30 | 2015-12-15 | Tandem Diabetes Care, Inc. | Infusion pump system with disposable cartridge having pressure venting and pressure feedback |
US11135362B2 (en) | 2009-07-30 | 2021-10-05 | Tandem Diabetes Care, Inc. | Infusion pump systems and methods |
US11285263B2 (en) | 2009-07-30 | 2022-03-29 | Tandem Diabetes Care, Inc. | Infusion pump systems and methods |
US11090432B2 (en) | 2009-12-04 | 2021-08-17 | Smiths Medical Asd, Inc. | Advanced step therapy delivery for an ambulatory infusion pump and system |
US10016559B2 (en) | 2009-12-04 | 2018-07-10 | Smiths Medical Asd, Inc. | Advanced step therapy delivery for an ambulatory infusion pump and system |
US10872685B2 (en) | 2010-01-22 | 2020-12-22 | Deka Products Limited Partnership | Electronic patient monitoring system |
US11424029B2 (en) | 2010-01-22 | 2022-08-23 | Deka Products Limited Partnership | System, method and apparatus for electronic patient care |
US11164672B2 (en) | 2010-01-22 | 2021-11-02 | Deka Products Limited Partnership | System and apparatus for electronic patient care |
US11524107B2 (en) | 2010-01-22 | 2022-12-13 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US10108785B2 (en) * | 2010-01-22 | 2018-10-23 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US11776671B2 (en) | 2010-01-22 | 2023-10-03 | Deka Products Limited Partnership | Electronic patient monitoring system |
US20130297330A1 (en) * | 2010-01-22 | 2013-11-07 | Deka Products Limited Partnership | System, Method, and Apparatus for Electroinic Patient Care |
US11810653B2 (en) | 2010-01-22 | 2023-11-07 | Deka Products Limited Partnership | Computer-implemented method, system, and apparatus for electronic patient care |
US11244745B2 (en) | 2010-01-22 | 2022-02-08 | Deka Products Limited Partnership | Computer-implemented method, system, and apparatus for electronic patient care |
US10242159B2 (en) | 2010-01-22 | 2019-03-26 | Deka Products Limited Partnership | System and apparatus for electronic patient care |
US10453157B2 (en) | 2010-01-22 | 2019-10-22 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US20110313789A1 (en) * | 2010-01-22 | 2011-12-22 | Deka Products Limited Partnership | Electronic patient monitoring system |
US11660392B2 (en) | 2010-02-05 | 2023-05-30 | Deka Products Limited Partnership | Devices, methods and systems for wireless control of medical devices |
US9750896B2 (en) * | 2010-02-05 | 2017-09-05 | Deka Products Limited Partnership | Infusion pump apparatus, method and system |
US20110319813A1 (en) * | 2010-02-05 | 2011-12-29 | Deka Products Limited Partnership | Infusion pump apparatus, method and system |
US20120098668A1 (en) * | 2010-10-22 | 2012-04-26 | Peng Chen | Infusion monitoring alarm and method for monitoring and alarming for intravenous infusion |
US10430761B2 (en) | 2011-08-19 | 2019-10-01 | Icu Medical, Inc. | Systems and methods for a graphical interface including a graphical representation of medical data |
US11004035B2 (en) | 2011-08-19 | 2021-05-11 | Icu Medical, Inc. | Systems and methods for a graphical interface including a graphical representation of medical data |
US11599854B2 (en) | 2011-08-19 | 2023-03-07 | Icu Medical, Inc. | Systems and methods for a graphical interface including a graphical representation of medical data |
US11626205B2 (en) | 2011-10-21 | 2023-04-11 | Icu Medical, Inc. | Medical device update system |
US9971871B2 (en) | 2011-10-21 | 2018-05-15 | Icu Medical, Inc. | Medical device update system |
US9594875B2 (en) | 2011-10-21 | 2017-03-14 | Hospira, Inc. | Medical device update system |
US11376361B2 (en) | 2011-12-16 | 2022-07-05 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US10022498B2 (en) | 2011-12-16 | 2018-07-17 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US11210611B2 (en) | 2011-12-21 | 2021-12-28 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US11439571B2 (en) | 2011-12-22 | 2022-09-13 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US11439570B2 (en) | 2011-12-22 | 2022-09-13 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US11933650B2 (en) | 2012-03-30 | 2024-03-19 | Icu Medical, Inc. | Air detection system and method for detecting air in a pump of an infusion system |
US10578474B2 (en) | 2012-03-30 | 2020-03-03 | Icu Medical, Inc. | Air detection system and method for detecting air in a pump of an infusion system |
US10258736B2 (en) | 2012-05-17 | 2019-04-16 | Tandem Diabetes Care, Inc. | Systems including vial adapter for fluid transfer |
US10911515B2 (en) | 2012-05-24 | 2021-02-02 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US11881307B2 (en) | 2012-05-24 | 2024-01-23 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US10653834B2 (en) | 2012-06-07 | 2020-05-19 | Tandem Diabetes Care, Inc. | Device and method for training users of ambulatory medical devices |
US9814835B2 (en) | 2012-06-07 | 2017-11-14 | Tandem Diabetes Care, Inc. | Device and method for training users of ambulatory medical devices |
US11676694B2 (en) | 2012-06-07 | 2023-06-13 | Tandem Diabetes Care, Inc. | Device and method for training users of ambulatory medical devices |
US10463788B2 (en) | 2012-07-31 | 2019-11-05 | Icu Medical, Inc. | Patient care system for critical medications |
US11623042B2 (en) | 2012-07-31 | 2023-04-11 | Icu Medical, Inc. | Patient care system for critical medications |
US11470000B2 (en) | 2013-03-06 | 2022-10-11 | Icu Medical, Inc. | Medical device communication method |
US10333843B2 (en) | 2013-03-06 | 2019-06-25 | Icu Medical, Inc. | Medical device communication method |
US10357606B2 (en) | 2013-03-13 | 2019-07-23 | Tandem Diabetes Care, Inc. | System and method for integration of insulin pumps and continuous glucose monitoring |
US11607492B2 (en) | 2013-03-13 | 2023-03-21 | Tandem Diabetes Care, Inc. | System and method for integration and display of data of insulin pumps and continuous glucose monitoring |
US9962486B2 (en) | 2013-03-14 | 2018-05-08 | Tandem Diabetes Care, Inc. | System and method for detecting occlusions in an infusion pump |
US10016561B2 (en) | 2013-03-15 | 2018-07-10 | Tandem Diabetes Care, Inc. | Clinical variable determination |
US11776689B2 (en) | 2013-03-15 | 2023-10-03 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
US9895491B2 (en) | 2013-03-15 | 2018-02-20 | Tandem Diabeters Care, Inc. | Field update of an ambulatory infusion pump system |
US11152115B2 (en) | 2013-03-15 | 2021-10-19 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
US11049614B2 (en) | 2013-03-15 | 2021-06-29 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
US9242043B2 (en) | 2013-03-15 | 2016-01-26 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
US10456524B2 (en) | 2013-03-15 | 2019-10-29 | Tandem Diabetes Care, Inc. | Field update of an ambulatory infusion pump system |
US10874793B2 (en) | 2013-05-24 | 2020-12-29 | Icu Medical, Inc. | Multi-sensor infusion system for detecting air or an occlusion in the infusion system |
US11433177B2 (en) | 2013-05-29 | 2022-09-06 | Icu Medical, Inc. | Infusion system which utilizes one or more sensors and additional information to make an air determination regarding the infusion system |
US10166328B2 (en) | 2013-05-29 | 2019-01-01 | Icu Medical, Inc. | Infusion system which utilizes one or more sensors and additional information to make an air determination regarding the infusion system |
US11596737B2 (en) | 2013-05-29 | 2023-03-07 | Icu Medical, Inc. | Infusion system and method of use which prevents over-saturation of an analog-to-digital converter |
US10596316B2 (en) | 2013-05-29 | 2020-03-24 | Icu Medical, Inc. | Infusion system and method of use which prevents over-saturation of an analog-to-digital converter |
US11571508B2 (en) | 2013-08-30 | 2023-02-07 | Icu Medical, Inc. | System and method of monitoring and managing a remote infusion regimen |
US10765799B2 (en) | 2013-09-20 | 2020-09-08 | Icu Medical, Inc. | Fail-safe drug infusion therapy system |
WO2015047595A1 (en) * | 2013-09-27 | 2015-04-02 | Smiths Medical Asd, Inc. | Infusion pump with touchless user interface and related methods |
US10311972B2 (en) | 2013-11-11 | 2019-06-04 | Icu Medical, Inc. | Medical device system performance index |
US11501877B2 (en) | 2013-11-11 | 2022-11-15 | Icu Medical, Inc. | Medical device system performance index |
US10042986B2 (en) | 2013-11-19 | 2018-08-07 | Icu Medical, Inc. | Infusion pump automation system and method |
US11763927B2 (en) | 2013-11-19 | 2023-09-19 | Icu Medical, Inc. | Infusion pump automation system and method |
US11037668B2 (en) | 2013-11-19 | 2021-06-15 | Icu Medical, Inc. | Infusion pump automation system and method |
US10478551B2 (en) | 2013-12-26 | 2019-11-19 | Tandem Diabetes Care, Inc. | Integration of infusion pump with remote electronic device |
US10918785B2 (en) | 2013-12-26 | 2021-02-16 | Tandem Diabetes Care, Inc. | Integration of infusion pump with remote electronic device |
US10213547B2 (en) | 2013-12-26 | 2019-02-26 | Tandem Diabetes Care, Inc. | Safety processor for a drug delivery device |
US11383027B2 (en) | 2013-12-26 | 2022-07-12 | Tandem Diabetes Care, Inc. | Integration of infusion pump with remote electronic device |
US9486571B2 (en) | 2013-12-26 | 2016-11-08 | Tandem Diabetes Care, Inc. | Safety processor for wireless control of a drug delivery device |
US10806851B2 (en) | 2013-12-26 | 2020-10-20 | Tandem Diabetes Care, Inc. | Wireless control of a drug delivery device |
US9737656B2 (en) | 2013-12-26 | 2017-08-22 | Tandem Diabetes Care, Inc. | Integration of infusion pump with remote electronic device |
US11911590B2 (en) | 2013-12-26 | 2024-02-27 | Tandem Diabetes Care, Inc. | Integration of infusion pump with remote electronic device |
US10342917B2 (en) | 2014-02-28 | 2019-07-09 | Icu Medical, Inc. | Infusion system and method which utilizes dual wavelength optical air-in-line detection |
US10898641B2 (en) | 2014-04-30 | 2021-01-26 | Icu Medical, Inc. | Patient care system with conditional alarm forwarding |
US11628246B2 (en) | 2014-04-30 | 2023-04-18 | Icu Medical, Inc. | Patient care system with conditional alarm forwarding |
US11344673B2 (en) | 2014-05-29 | 2022-05-31 | Icu Medical, Inc. | Infusion system and pump with configurable closed loop delivery rate catch-up |
US11628254B2 (en) | 2014-06-16 | 2023-04-18 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US10314974B2 (en) | 2014-06-16 | 2019-06-11 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US10646651B2 (en) | 2014-06-16 | 2020-05-12 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
AU2020205342B2 (en) * | 2014-06-30 | 2022-03-03 | Icu Medical, Inc. | Infusion pump error display |
EP3160545A4 (en) * | 2014-06-30 | 2018-03-07 | ICU Medical, Inc. | Infusion pump error display |
AU2015284181B2 (en) * | 2014-06-30 | 2020-05-07 | Icu Medical, Inc. | Infusion pump error display |
WO2016004088A1 (en) | 2014-06-30 | 2016-01-07 | Hospira, Inc. | Infusion pump error display |
US9669160B2 (en) | 2014-07-30 | 2017-06-06 | Tandem Diabetes Care, Inc. | Temporary suspension for closed-loop medicament therapy |
US11289183B2 (en) | 2014-09-15 | 2022-03-29 | Icu Medical, Inc. | Matching delayed infusion auto-programs with manually entered infusion programs |
US11574721B2 (en) | 2014-09-15 | 2023-02-07 | Icu Medical, Inc. | Matching delayed infusion auto-programs with manually entered infusion programs |
US10238799B2 (en) | 2014-09-15 | 2019-03-26 | Icu Medical, Inc. | Matching delayed infusion auto-programs with manually entered infusion programs |
US10799632B2 (en) | 2014-09-15 | 2020-10-13 | Icu Medical, Inc. | Matching delayed infusion auto-programs with manually entered infusion programs |
US11344668B2 (en) | 2014-12-19 | 2022-05-31 | Icu Medical, Inc. | Infusion system with concurrent TPN/insulin infusion |
US10850024B2 (en) | 2015-03-02 | 2020-12-01 | Icu Medical, Inc. | Infusion system, device, and method having advanced infusion features |
US11605468B2 (en) | 2015-05-26 | 2023-03-14 | Icu Medical, Inc. | Infusion pump system and method with multiple drug library editor source capability |
USD1018849S1 (en) | 2015-12-04 | 2024-03-19 | Icu Medical, Inc. | Fluid transfer device |
US11865295B2 (en) | 2015-12-04 | 2024-01-09 | Icu Medical, Inc. | Systems, methods, and components for transferring medical fluids |
USD948044S1 (en) | 2015-12-04 | 2022-04-05 | Icu Medical, Inc. | Fluid transfer device |
US10420927B2 (en) | 2015-12-04 | 2019-09-24 | Icu Medical, Inc. | Systems, methods, and components for transferring medical fluids |
US11135416B2 (en) | 2015-12-04 | 2021-10-05 | Icu Medical, Inc. | Systems, methods, and components for transferring medical fluids |
US10188849B2 (en) | 2015-12-04 | 2019-01-29 | Icu Medical, Inc. | Systems, methods, and components for transferring medical fluids |
US10569016B2 (en) | 2015-12-29 | 2020-02-25 | Tandem Diabetes Care, Inc. | System and method for switching between closed loop and open loop control of an ambulatory infusion pump |
US11638781B2 (en) | 2015-12-29 | 2023-05-02 | Tandem Diabetes Care, Inc. | System and method for switching between closed loop and open loop control of an ambulatory infusion pump |
US11246985B2 (en) | 2016-05-13 | 2022-02-15 | Icu Medical, Inc. | Infusion pump system and method with common line auto flush |
US11324888B2 (en) | 2016-06-10 | 2022-05-10 | Icu Medical, Inc. | Acoustic flow sensor for continuous medication flow measurements and feedback control of infusion |
US11574737B2 (en) | 2016-07-14 | 2023-02-07 | Icu Medical, Inc. | Multi-communication path selection and security system for a medical device |
USD874644S1 (en) | 2016-07-19 | 2020-02-04 | Icu Medical, Inc. | Medical fluid transfer system |
USD905228S1 (en) | 2016-07-19 | 2020-12-15 | Icu Medical, Inc. | Medical fluid transfer system |
USD943732S1 (en) | 2016-07-19 | 2022-02-15 | Icu Medical, Inc. | Medical fluid transfer system |
US11868161B2 (en) | 2017-12-27 | 2024-01-09 | Icu Medical, Inc. | Synchronized display of screen content on networked devices |
US10656894B2 (en) | 2017-12-27 | 2020-05-19 | Icu Medical, Inc. | Synchronized display of screen content on networked devices |
US11029911B2 (en) | 2017-12-27 | 2021-06-08 | Icu Medical, Inc. | Synchronized display of screen content on networked devices |
US10861592B2 (en) | 2018-07-17 | 2020-12-08 | Icu Medical, Inc. | Reducing infusion pump network congestion by staggering updates |
US11783935B2 (en) | 2018-07-17 | 2023-10-10 | Icu Medical, Inc. | Health checks for infusion pump communications systems |
US11373753B2 (en) | 2018-07-17 | 2022-06-28 | Icu Medical, Inc. | Converting pump messages in new pump protocol to standardized dataset messages |
US11594326B2 (en) | 2018-07-17 | 2023-02-28 | Icu Medical, Inc. | Detecting missing messages from clinical environment |
US11587669B2 (en) | 2018-07-17 | 2023-02-21 | Icu Medical, Inc. | Passing authentication token to authorize access to rest calls via web sockets |
US11923076B2 (en) | 2018-07-17 | 2024-03-05 | Icu Medical, Inc. | Converting pump messages in new pump protocol to standardized dataset messages |
US11328805B2 (en) | 2018-07-17 | 2022-05-10 | Icu Medical, Inc. | Reducing infusion pump network congestion by staggering updates |
US11483403B2 (en) | 2018-07-17 | 2022-10-25 | Icu Medical, Inc. | Maintaining clinical messaging during network instability |
US11670416B2 (en) | 2018-07-17 | 2023-06-06 | Icu Medical, Inc. | Tagging pump messages with identifiers that facilitate restructuring |
US10950339B2 (en) | 2018-07-17 | 2021-03-16 | Icu Medical, Inc. | Converting pump messages in new pump protocol to standardized dataset messages |
US11139058B2 (en) | 2018-07-17 | 2021-10-05 | Icu Medical, Inc. | Reducing file transfer between cloud environment and infusion pumps |
US10964428B2 (en) | 2018-07-17 | 2021-03-30 | Icu Medical, Inc. | Merging messages into cache and generating user interface using the cache |
US11152108B2 (en) | 2018-07-17 | 2021-10-19 | Icu Medical, Inc. | Passing authentication token to authorize access to rest calls via web sockets |
US10741280B2 (en) | 2018-07-17 | 2020-08-11 | Icu Medical, Inc. | Tagging pump messages with identifiers that facilitate restructuring |
US11152110B2 (en) | 2018-07-17 | 2021-10-19 | Icu Medical, Inc. | Tagging pump messages with identifiers that facilitate restructuring |
US11152109B2 (en) | 2018-07-17 | 2021-10-19 | Icu Medical, Inc. | Detecting missing messages from clinical environment |
US11483402B2 (en) | 2018-07-17 | 2022-10-25 | Icu Medical, Inc. | Maintaining clinical messaging during an internet outage |
US11328804B2 (en) | 2018-07-17 | 2022-05-10 | Icu Medical, Inc. | Health checks for infusion pump communications systems |
US11881297B2 (en) | 2018-07-17 | 2024-01-23 | Icu Medical, Inc. | Reducing infusion pump network congestion by staggering updates |
US10692595B2 (en) | 2018-07-26 | 2020-06-23 | Icu Medical, Inc. | Drug library dynamic version management |
US11437132B2 (en) | 2018-07-26 | 2022-09-06 | Icu Medical, Inc. | Drug library dynamic version management |
US11309070B2 (en) | 2018-07-26 | 2022-04-19 | Icu Medical, Inc. | Drug library manager with customized worksheets |
WO2021050893A1 (en) * | 2019-09-11 | 2021-03-18 | Electronic Health Record Data, Inc. | Processing pharmaceutical prescriptions in real time using a clinical analytical message data file |
US11278671B2 (en) | 2019-12-04 | 2022-03-22 | Icu Medical, Inc. | Infusion pump with safety sequence keypad |
US11883361B2 (en) | 2020-07-21 | 2024-01-30 | Icu Medical, Inc. | Fluid transfer devices and methods of use |
US11135360B1 (en) | 2020-12-07 | 2021-10-05 | Icu Medical, Inc. | Concurrent infusion with common line auto flush |
Also Published As
Publication number | Publication date |
---|---|
US20050144043A1 (en) | 2005-06-30 |
US7895053B2 (en) | 2011-02-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7895053B2 (en) | Medication management system | |
US20200206413A1 (en) | Medication managment system | |
CA2554903C (en) | Medication management system | |
US7398183B2 (en) | Medication management system | |
US20060100907A1 (en) | Medication management system | |
US20050278194A1 (en) | Medication management system | |
US20070214003A1 (en) | Medication management system | |
US20060089855A1 (en) | Medication management system | |
US20060089854A1 (en) | Medication management system | |
US11049609B2 (en) | Medication order processing and reconciliation | |
CA2810924C (en) | Automatic association of medical elements | |
US20130110538A1 (en) | System and method for managing medical databases for patient care devices | |
JP2013017820A (en) | Medication administration and management system and method | |
EP1855221A2 (en) | Method and system for evaluating the performance of medical devices from a medication management unit | |
EP2273402A1 (en) | Medication management system providing location of medical devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: ICU MEDICAL, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HOSPIRA, INC.;REEL/FRAME:041672/0001 Effective date: 20170203 |