JP2017521107A - Patient treatment system using conditional alarm forwarding - Google Patents

Abstract

A patient treatment system is disclosed that includes a medical device, such as an infusion pump. The medical device generates a data message that includes information, such as the status of treatment being administered, operational data, or both. The alarm generation system evaluates the data message from the pump and generates an alarm message if a specific condition defined by the first set of rules is met. The alert message is evaluated according to a second set of rules regarding whether to suppress the alert message. The data message contains the necessary inputs for both the first and second algorithms. The shipping system is configured to forward the alert message to the alert destination according to a third set of rules. The alert destination represents an alert when an alert message is received. [Selection] Figure 1

Description

  Modern medicine often involves the use of drug delivery and monitoring devices such as drug management systems that include drug delivery pumps or patient parameter monitors or both. A drug management system for configuring, controlling and monitoring a drug delivery device is disclosed. For example, shared U.S. Patent No. 7,895,053 (Title "MEDICATION MANAGEMENT SYSTEM", issued February 22, 2011) and US Patent Application No. 10 / 783,573 (Title "MEDICATION MANAGEMENT SYSTEM", 2005 Published as US Patent Application Publication No. 2005050278194 (A1) on Dec. 15, 2000) is a user-customizable drug library or medical device configuration information module of a drug library editor (DLE) program and drug management unit (MMU) Disclosed is a drug management system prepared using Hospira, Inc. of Lake Forest, Illinois, USA Hospira MedNet (TM) Meds (TM) software available from includes a DLE program of this type. The MMU, software with the Hospira MedNet ™ server, downloads a customizable drug library to the drug delivery pump and receives status or activity information from the pump. Shared US Pat. No. 8,065,161 (titled “SYSTEM FOR MAINTAING DRUG INFORMATION AND COMMUNICATION WITH MEDICATION DEVICES”, published November 22, 2011) Disclosed, edited, stored and communicated to a drug delivery device associated with the drug management system to deliver a substance, such as a fluid or fluid drug or both, to a patient.

  According to the above-mentioned shared and published patent application, a typical drug management system is a nursing computer location, eg, a nursing computer and / or pharmacy computer barcode location, and / or one or more drug delivery Includes an MMU that communicates with the device. The nursing computer point and / or MMU stores and shares or communicates various information, such as patient information, prescription information, customized drug libraries or other information, with associated memory to manage drug delivery to the patient For example, it performs five proper checks, configures the drug delivery device, receives and stores event, status or activity information received from the drug delivery device.

  Caregivers and clinicians make various patient care decisions using output from patient monitoring equipment and equipment monitoring equipment. The patient monitoring device and the patient care equipment monitoring device may be connected to a receiver that receives output signals from the patient monitoring device and the patient care equipment monitoring device. In some cases, the receiver may display and / or record information from the patient and patient care equipment monitoring device. In other cases, the device may include a monitoring and / or recording medium. The receiver or device may further have a preset or adjustable alarm that is triggered when one of the outputs from the patient or patient care device monitoring device deviates from a preset limit. Good.

  In hospitals that use infusion pumps and other medical devices, alarms are used to indicate device failures, treatment interruptions, treatment terminations, and other events that need to be handled by clinical staff. Typically, an alarm is displayed on the device screen and generates an audible sound. In some cases, there are too many devices that generate alarms in close proximity to each other. As a result, it is very difficult to tell which device is actually generating the alarm. The audible alarm may disturb or wake up the sleeping patient. A nurse typically manages multiple infusions operating on multiple patients in one or more predetermined clinical nursing areas. It is difficult for the nurse to always be in the same vicinity of the infusion device during the infusion, and therefore it is difficult to react immediately to infusion related or infusion device alarms. Furthermore, the clinical staff is not necessarily in the immediate vicinity of the alarm device and does not hear the alarm. In this type of situation, it is desirable for staff to be notified of device alerts as soon as possible, regardless of whether they are in the vicinity of the device, and to better respond to their patient's requirements.

  In addition, in the case of some patients, isolate the patient and expose the patient to unnecessary hospital conditions (eg, when a patient opens a room door, the burn patient is exposed to airflow or airborne contaminants). It is important to reduce. In addition, multiple nurses may utilize the same pump for the patient during device cleaning. This leads to the potential for increased contamination as the number of clinical workers in contact with the device increases. The pump can be contaminated by clinical personnel. This contamination may be caused to the patient by the clinician who originally contaminated the pump or by the next clinical worker who transferred the contamination to the patient during patient treatment after obtaining the contamination by contacting the pump. Can be moved. Further, contamination on the pump, after contacting the pump contamination, is transferred to other devices and patients by clinicians who carry it to other pumps and patients, where the contamination can accumulate and diffuse. This type of contamination and mutual interaction may occur if the clinician actually needs to come to the pump and contact the pump in order to evaluate, stop, or otherwise respond to the alarm. The potential for contamination increases.

  In a preferred embodiment, a patient treatment system is disclosed that includes at least one medical device, such as an infusion pump. Each pump can generate a data message that includes information about the pump, including the status of treatment being administered, operational data, or both. The patient treatment system includes an alarm generation system that receives the data message from the pump. The alarm generation system evaluates the data message from the pump and generates a trigger if certain conditions defined by the first set of rules, algorithms or instructions are met. The generation of the trigger generates an alarm message. This alert message is evaluated according to a second set of rules, algorithms or instructions regarding whether to suppress the alert message. For both the first and second algorithms, the information generated by each pump is a necessary input.

  The patient treatment system also includes a shipping system connected to the alarm generation system. The shipping system is configured to forward the alert message to the alert destination according to a third set of rules, algorithms or instructions. In addition, the patient treatment system includes an alarm destination connected to the shipping system, the alarm destination representing an alarm when the alarm destination receives the alarm.

  In an alternative embodiment of the patient treatment system, the medical device is not part of the patient treatment system. Instead, the disclosed patient treatment system interacts with a medical device. In another alternative embodiment of the patient treatment system, the alert destination is not part of the patient treatment system but instead interacts with the patient treatment system. In yet another alternative embodiment of the patient treatment system, both the medical device and the alarm destination are not part of the patient treatment system, but instead interact with the patient treatment system. In yet another embodiment of the patient treatment system, the alarm generation system and the dispatch system, whether or not including a medical device and / or alarm destination, are combined into a single system.

1 is a schematic diagram of the structure of one embodiment of a patient treatment system. FIG. 2 is a data flowchart of one embodiment of a patient treatment system. FIG. 2 illustrates the flow of information between various personnel and components of the patient treatment system of FIG. 2 is a flowchart of one embodiment of the patient treatment system of FIG. 1 is a diagram of one embodiment of a patient treatment system illustrating the process of configuring a pump from a monitor / control system. FIG. 2 is a flowchart of one embodiment of a patient treatment system showing alarm forwarding and acknowledgment functions. 1 is a diagram of one embodiment of a patient treatment system illustrating a process for changing a pump infusion program by a monitor / control system. FIG. 1 is a diagram of one embodiment of a patient treatment system illustrating the process of transferring the supervision of one or more pumps from one monitor / controller system to another. 1 is a diagram of one embodiment of a patient treatment system illustrating a process of monitoring pump infusion by a monitor / control system. FIG. FIG. 6 is a plan view of one embodiment of a monitor / control system user interface design in various states during operation.

  Referring to the drawings, a patient treatment system is shown generally as 10 in the drawings. The patient treatment system 10 interacts with the medical device 12 and manages alarms generated by the medical device 12. Patient treatment system 10 includes a shipping system 14, an alarm forwarding system 16, and in a particular embodiment, a monitor / control system 18.

  The patient treatment system 10 is intended to be deployed in any hospital or other facility that utilizes the medical device 12, which is connected to the network via wiring or by wireless connection. Including but not limited to infusion pumps. This type of network may be dedicated to the connection of one or more pumps 12 to each other or to the connection of control or monitoring devices. A network may connect many medical devices and allow control or monitoring of various such devices, including control or monitoring from and to remote locations.

  The medical device 12 is preferably an infusion pump 12 that can receive programming data from a nurse or other practitioner. Furthermore, the pump 12 is preferably capable of being inspected and verified by a nurse or other practitioner, or both, for an infusion program of its operation. An example of the pump 12 is Hospira, Inc. of Lake Forest, Illinois. PLUM A + (TM) infusion system, LIFECARE PCA (TM) infusion system and SAPPHIRE (TM) infusion system sold by The medical device 12 is preferably an infusion pump 12, but the pump 12 applied to the patient treatment system 10 of the present invention is any medical pump, and in a broader sense, as described herein. Further, it is intended to be understood as any medical device that can generate data and can be connected to the shipping system 14. Each pump 12 or other medical device can generate a data message that includes information about the pump, including the status of treatment being administered, operational data, or both. Examples of data messages generated by the pump 12 include pump 12 status data, the status of the therapy administered by the pump 12, event data associated with the pump 12 (eg, expiration of a particular time period), and the pump 12 Including, but not limited to, alarms associated with or delivery of treatment by the pump 12. Further, in some embodiments, the pump 12 includes a local delay timer 50. The local delay timer may be a mechanical timer or a timer implemented in software. When an alarm status message is sent by the pump 12 to the shipping system 14, the local delay timer 50 is activated and begins counting. In other embodiments of the pump 12, the pump 12 includes individual logic 52 or logic 52 that can be implemented by software. The logic 52 allows the pump 12 to include rules, algorithms or instructions, and to evaluate or take action according to programming implemented in or associated with the logic 52, and in certain embodiments, local A delay timer 50 can also be provided.

  The shipping system 14 is preferably a network application that includes a shipping server 20 that manages alerts and is preferably capable of executing software. The primary function of the shipping system 14 is to facilitate alarm management from the pump 12 to one or more alarm destinations (eg, the monitor / control system 18) and vice versa. For example, in a preferred embodiment, the shipping system 14 is configured to forward alarm messages from the pump 12 to one or more monitoring / control systems 18 according to a set of rules, algorithms, or instructions. In a preferred embodiment of the patient treatment system 10, these rules, algorithms or instructions are executed in the alarm transfer system 16, which is substantially from the pump 12 to one or more monitoring / control systems. Organize the alarm flow to 18 and vice versa to perform safe and reliable alarm processing. In a variation of this embodiment, rules, algorithms or instructions may be implemented on the pump 12 itself. Rules, algorithms or instructions can be configured by a rule editor.

  In one embodiment, the shipping server 14 incorporates an alarm forwarding system 16 that decouples alarm communications from the actual communication means and forwards alarm information to the monitor / control system 18 according to rules, algorithms or instructions. The alarm transfer system 16 evaluates the data message generated by the pump 12 and passed by the dispatch system 14 from the pump 12 to the alarm transfer system 16, and certain conditions defined by a first set of rules, algorithms or instructions are met. If so, generate a trigger. The generation of the trigger generates an alert message that is evaluated according to a second set of rules, algorithms or instructions regarding whether to suppress the alert message. An example of a shipping server 14 is Hospira, Inc. of Lake Forest, Illinois. Server with Hospira MedNet ™ drug management software manufactured and sold by The shipping server can be used in combination with a hospital's existing alarm forwarding system or in combination with a hospital alarm forwarding system that has been modified to interface with alarm messages received from the shipping server 14. is there. In a preferred embodiment of the patient treatment system 10, the shipping system 14 and the alert forwarding system 16 are either wired or connected by radio or optical fiber, for example, by a local area network (LAN) or a wide area network (WAN). Or separate systems connected together by any other communication protocol or system. However, the shipping system 14 and the alarm transfer system 16 can be combined into a single system that performs the functions of the shipping system 14 and the alarm transfer system 16 as described herein.

  Patient treatment system 10 includes, in a preferred embodiment, one or more monitoring / control systems 18 connected to shipping system 14. The functions of the monitor / control system 18 include connecting to the shipping system 14, receiving alerts and data from the shipping system 14, communicating such alerts and data to clinical personnel, in some embodiments, To have the clinical practitioner generate a response to this type of alarm and data, and otherwise generate an acknowledgment or control response and have this type of response and acknowledgment communicate to the shipping system 14. The monitor / control system 18 preferably represents an alarm when the monitor / control system 18 receives an alarm notification. Alarms include, but are not limited to, audible alarms, visual alarms or vibration alarms and can take a variety of forms. A list of possible monitoring / control systems 18 includes, but is not limited to, mobile wireless devices, networked workstations, laptop computers, tablets, emails, text messages, pagers and even fax machines. Absent.

  In one embodiment of the patient treatment system 10, the medical device 12 forwards the data message to the shipping system 14, which accesses the data message, whether the alarm condition is met, and the higher level. Determine whether the alarm should be suppressed. For example, the local alarm of the medical device 12 can be temporarily suppressed while the alarm is transmitted to the remote monitor / control system 18. The content of the data message can be the necessary input for evaluating both whether an alarm condition is met and whether higher level alarms should be suppressed. As described above, the data message may include pump therapy status data, pump operating point data, or information regarding both pump therapy status data and pump operating point data. If the alarm condition is met, the shipping system 14 may cause the alarm transfer system 16 to transfer the alarm message to one or more monitoring / control systems 18. As a result, the monitor / control system 18 does not sound an alarm in the monitor / control system 18 except under certain predetermined conditions. Furthermore, the medical device 12 itself does not need to sound an alarm except when following a specific predetermined condition.

  FIG. 2 shows an alarm condition sent to the nurse and pharmacist to assist in their workflow (eg, the nurse gets the next package of drugs from the pharmacist and the pharmacist is approaching completion of the infusion That is a signal for the nurse to come and prepare to get the next package of infusion medication). As can be seen in the embodiment shown in FIG. 2, the pump 12 communicates with the shipping system 14, and the pump 12 sends status data regarding the pump 12 to the shipping system 14. This type of condition data includes, but is not limited to, patient biometrics, physiological or medical parameter information, pump 12 position, and the type and amount of drug administered by pump 12. Further, the pump 12 transmits event data to the shipping system 14. This type of event data includes information indicating that the injection is nearing completion, but is not limited thereto. Further, the pump 12 transmits alarm data to the shipping system 14. As used herein, alarm data refers to any notification that can benefit a physician, clinical staff or patient in handling the operation and safety of the pump 12.

  Although the patient treatment system 10 described herein interacts with one or more pumps 12, the pump 12 need not be part of the patient treatment system 10. However, as described below, various aspects of the function of the patient treatment system 10 may be shared with the pump 12, so that, in some embodiments, the pump 12 may be part of the patient treatment system 10. Good.

  In addition to receiving data from the pump 12, the shipping system 14 can also send programming data to the pump 12. This type of programming data reconfigures the parameters and operation of the pump 12 in terms of both the infusion of the drug by the pump 12 and the type, amount and frequency of the data collected by the pump 12 and transmitted to the shipping system 14. May be. In addition, the shipping system 14 may also send drug library data to the pump 12, which in turn configures the limits and injector settings used in injecting the drug into the patient. The pump 12 may be used. Further, the shipping system 14 may send software updates to the pump 12 so that the pump 12 has the latest software for its operation.

  The shipping system 14 interacts with the alert forwarding system 16 to forward alerts generated by the shipping system 14 to the appropriate recipients according to rules, algorithms or instructions. These rules, algorithms or instructions are based in part on or take into account clinical care area (CCA), patient identification, alarm priority, location of pump 12, the type of medication infused by pump 12. be able to. The rules, algorithms or instructions may be fixed and predetermined, or customized by the hospital or medical institution according to their preferred practices or according to other practices recommended by others. An example of a suitable recipient is a nurse who is nursing a patient receiving treatment from the pump 12. Further, if the alert is sent to the appropriate recipient, who the recipient is or the location where the alert was forwarded may also be shown or displayed on the pump 12 itself.

  The shipping system 14 may also communicate raw data or data processed by the shipping system 14 to the clinical system 24 via the interface 22. Interface 22 provides a connection between shipping system 14 and clinical system 24. The clinical system 24 may be another network (either individually or interconnected by a network of shipping systems 14), which network receives information from an appropriate recipient, eg, pump 12. A nurse who is responsible for supervising the nurse who is nursing the patient, a doctor who oversees the treatment of the patient, a pharmacist who prepares the drug for the patient, or the infusion applied to the patient by these people and the pump 12 Communicate information to any combination of other people who need to know the status of treatment. Examples of data that can be communicated between the shipping system 14 and the clinical system 24 via the interface 22 and data that can be communicated from the clinical system 24 to the appropriate recipients include raw data generated by the pump 12, Examples include, but are not limited to, pump status data, pump event data and alarms associated with pump 12, or rules, results and data processed by shipping system 14 or alarm forwarding system 16.

  In addition, the clinical system 24 allows appropriate personnel, eg, a physician supervising the treatment of a patient, to contact the pump 12 and ultimately control or change the operation of the pump 12. For example, the physician sends an infusion command to the clinical system 24, which passes the interface 22 and the shipping system 14 and finally to the pump 12 to pass the infusion parameters of the pump 12 through the clinical system 24. Can be corrected. In addition, new or modified programming data for the pump 12 may be input into the clinical system 24, passed through the shipping system 14 via the interface 22, and finally passed to the pump 12 where the pump 12 The twelve current programming is preferably modified or replaced automatically and / or remotely.

  Interface 22 also allows appropriate personnel to manage the rules used to control alarm forwarding in the system via the rules / editor 18 or the rules editor available to the clinical system 24. The management interface allows hospital staff to determine rules regarding what content of data messages from pump 12 will cause an alarm message to be generated. For example, an administrator can determine that an alert is generated whenever a particular type of drug is interrupted, even if only temporarily, while an interruption of a different type of drug is If the interruption is not a sufficient period, it can be determined not to generate an alarm. Through the management interface, hospital personnel determine rules regarding what content from data messages from pump 12 controls how and what particular alarm messages are suppressed. You can also. For example, an administrator may not be able to suppress alarm messages generated based on data messages about life-critical or otherwise dangerous drugs such as analgesics, sedatives or anticoagulants such as Heparin. Alarm messages generated based on data messages about less important drugs can be suppressed locally at the device, but cannot be remotely deleted, and alarm messages generated based on data messages about less important drugs are It can be determined that it can be suppressed locally at the device and can also be erased remotely.

  With reference to FIG. 3, an example of how information flows in the patient treatment system 10 can be described. The main communication nodes of FIG. 3 include pump 12, delivery system 14, alarm forwarding system 16, alarm destination or monitor / control system 18, patient, nurse, telemedicine staff and pharmacist. As can be seen, an exemplary alarm condition 23 “infusion is nearing completion” is communicated from the pump 12 to the shipping system 14. The dispatch system 14 operating in accordance with the algorithm 25 for this alarm condition sends an alarm 23 “infusion is nearing completion” to the alarm transfer system 16, which in accordance with the rules or algorithm 25. 2. Transmit to monitor / control system 18 and clinical system 24 via interface 22 (FIG. 2). Alternatively or additionally, the shipping system 14 can send an alarm 23 to the interface 22, which is then passed to the clinical system 24, where the alarm 23 is an appropriate person, For example, go to a nurse, pharmacist or doctor. In this way, multiple alert messages are sent in parallel to the appropriate personnel according to the operation of the algorithm 25 operating on the shipping system 14. Furthermore, in a variant of this embodiment, the first alert message may be transferred in a so-called “serial transfer” manner from the recipient of this type of alert message to another person who is not initially sent the alert message. . Furthermore, in order to avoid the same alarm being received by multiple devices at different times, this may give the false impression that more alarms actually exist, so the alarm message When dispatched to a recipient (eg, various monitor / control systems 18, such as mobile tablets and nurse stations), the alert message can be synchronized to arrive simultaneously.

  The management interface can also be used to control how specific alarm messages flow in the patient treatment system 10. For example, alert messages related to life critical medications are forwarded to the various monitoring / control systems 18 in parallel, while alert messages related to less important medications are forwarded to a single monitoring system 18 to alert The rules applied to the alert message by the alert forwarding system 16 may be configurable so that only if there is no acknowledgment of the alert, it is forwarded in series to another monitoring system 18.

  As can be further seen, the shipping system 14 can receive an acknowledgment message 27 from an appropriate person, in this case a nurse. Upon receiving the alert message, the nurse may send an acknowledgment message confirming receipt of the alert message. Again, the rules, algorithms or instructions 25 operating on the shipping system 14 for this alarm condition process the acknowledgment and determine whether additional action needs to be taken. For example, if an acknowledgment message is not received within a predetermined time, the algorithm will cause the pump 12 to generate a local alert to alert people caring for the patient in the vicinity of this alerted patient. Can be directed. Of course, if an alarm condition is acknowledged before the predetermined time expires 29, this type of local alarm may not be required, as defined by algorithm 25, so that the local The alarm will not sound.

  In an embodiment of the patient treatment system 10 in which an alarm condition has been transferred to the shipping system 14, it is desirable, but not required, to indicate to the pump 12 that an alarm has been generated and transferred. In addition, in situations where local alarms are suppressed, the remaining time before the alarm sounds or otherwise indicated on the pump 12 in the field is displayed, so that clinical personnel located near the pump 12 It is desirable, but not essential, to be able to see the information and to act appropriately according to this information.

  Furthermore, a desirable function of the patient treatment system 10 is to confirm that the alarm has been delivered successfully. As shown in FIGS. 3 and 4, after the alert message has been sent to the appropriate personnel by the shipping system 14 as described above, the algorithm 25 operating on the shipping system 14 is defined as such: A “transfer successful” message 31 can be returned to the pump 12. This “transfer successful” message 31 is processed by rules, algorithms or instructions 25 of the shipping system 14 or alarm transfer system 16, or by software and rules, algorithms or instructions of the pump 12, and these software and rules, algorithms or instructions Measures can be taken as defined by For example, in addition to delivering this type of “successful transfer” message 31 to the pump 12, the “successful transfer” message 31 may be used in an audible, visual, or tactile messaging system as described herein. It may be displayed including by activation and alert an appropriate caregiver of this type of receipt.

  Each combination of alarm forwarding, acknowledgment and a particular type of suppression can be referred to as a suppression protocol. For example, the combination of suppressing local auditory alerts until the set time has elapsed or until an alarm transfer confirmation or acknowledgment is received is the first suppression protocol, or until the set time has elapsed, or The combination of suppressing the remote alarm to the supervisor until the primary caregiver clears the alarm locally on the medical device is a second suppression protocol. Various suppression protocols can be formed by hospital personnel using the rules editor described above, which in one embodiment may be incorporated into Hospira MedNet ™ software. Various suppression protocols can be further selectively applied by the treatment system based on the content of medical device data messages, alarm messages and other information available to the system. Thus, particularly severe suppression protocols can be automatically applied to low priority alarms, and looser suppression protocols are applied to high priority alarms.

  In all of the above situations where the content of the data message from the pump 12 or the content of the alert message is used to control how the alert is generated, suppressed or forwarded, the clinical care area (CCA) of the pump or medical device 12 Can be used as an addition to, or as an alternative to, an input to a rule, or can be used to select which rule should be applied. This feature provides an important advantage in that an alert forwarding protocol or alert suppression protocol is appropriate for a given medical situation in one CCA and may not be appropriate elsewhere. For example, a temporary interruption of normal saline infusion may be a low priority alarm, to which a strict suppression protocol is applied in one CCA, while the same medical event is not scheduled. In a Level 4 NICU, where a few minor differences can be more problematic for patients, priority is high. When a CCA is first deployed or provided in a drug library that is downloaded to a medical device, it is then programmed into the medical device, and then selected by the clinician on the device, and the selected CCA information is Can be received as input to any of these decisions by being delivered as part of a data message generated by the medical device 12. Alternatively, the CCA may be determined indirectly from data messages and / or alert messages by performing a search operation on a database associated with a server that communicates with a plurality of medical devices at a medical institution. For example, the ID number associated with the pump is received in the data message and then applied to the database to look up the CCA region where the pump was last deployed, programmed, or queried over the network. be able to.

  FIG. 4 illustrates the operation of one possible function of the patient treatment system 10. In this function, the shipping system 14 and the alert forwarding system 16 are shown as separate systems. However, as described above, the shipping system 14 and the alarm transfer system 16 can be combined into a single system or perform the functions of the shipping system 14 and the alarm transfer system 16 as described herein. It is intended to be within the scope of the present invention to be combined into a software module. Furthermore, as can be seen in FIG. 4, the medical pump 12 itself may operate according to a specific algorithm, or may perform some of the functions of the shipping system 14 and the alarm forwarding system 16 itself.

  In this example, if an alarm condition occurs at 26, the pump 12 generates an alarm condition message at 28. This alarm status message is sent from the pump 12 to the shipping system 14 and at 30 the alarm status message is evaluated. The alarm status message preferably includes information related to the alarm, such as pump 12 ID, patient ID / name, pump 12 location and the type / concentration / name of drug used. The pump 12 receives an acknowledgment from the server of the shipping system 14 that it has received an alarm and an acknowledgment from the forwarding system 16 and / or an alarm destination or receiving entity.

  The evaluation at 30 occurs according to rules, algorithms or instructions established in the shipping system 14. In step 30, if the alarm condition received from pump 12 is passed to alarm transfer system 16 and it is determined that it should be managed, in step 32, the alarm condition is passed to alarm transfer system 16 and received. It is. The alarm transfer system 16 then forwards the alarm condition to the appropriate personnel via the monitor / control system 18 according to rules, algorithms or instructions defined in the alarm transfer system 16 for that particular alarm condition. Alerts have different priorities and repetition rates and require different responses. As a result, when one or more alarms are present at the same time and the proper routing, timing and display of alarm information in the alarms are inconsistent, the rules, algorithms or instructions defined in the alarm forwarding system 16 are Decide if the priority is high. Furthermore, the rules, algorithms or instructions established in the alarm forwarding system 16 determine how, when and by whom an alarm can be canceled or suppressed, especially in situations where the alarm is inconsistent.

  The monitor / control system 18 to which the alarm transfer system 16 transfers alarm conditions communicates with a number of devices, such as pagers, cell phones, wireless devices, tablets, workstations, e-mails, or the alarm transfer system 16 to provide information. Any other form of communication that can communicate to the appropriate personnel. In the illustrated embodiment, the shipping system 14 itself determines whether an alarm condition received from the pump 12 should be passed to the alarm transfer system 16 and managed according to rules, algorithms or instructions defined in the shipping system 14. evaluate. In an alternative embodiment, the shipping system 14 does not include this type of evaluation system, but instead passes the alert message directly to the alert forwarding system 16.

  At 32, when the alert forwarding system 16 receives an alert status message, in the illustrated embodiment, the program proceeds to step 34 and the alert forwarding system 16 is configured to send a “successful receipt” acknowledgment of the alert status message. It is determined whether or not to be performed. If the alarm transfer system 16 is so configured, the program proceeds from step 34 to step 36 where a “successful receipt” acknowledgment message is generated and transmitted from the alarm transfer system 16 to the shipping system 14.

  A “successful receipt” message sent from the alert forwarding system 16 is received by the shipping system 14 at step 38. Step 38 determines whether the alarm status message initially generated by the pump 12 and passed to the shipping system 14 has been successfully transferred to the alarm transfer system 16. If the alarm status message is not received by the alarm transfer system 16 according to the logic operation of step 38, the program proceeds to step 40 and the higher level scheme is started. Higher level schemes include the determination of an appropriate response by rules, algorithms or instructions when an alarm status message is not acknowledged. Examples of this type of appropriate response include resending the alarm status message, sending the alarm status message to another monitor / control system 18, activating a local indication of the alarm status on the pump 12, An indication of the warning condition may be generated on some other device, or any other programmed as a rule, algorithm or instruction as determined by people treating the patient and operating on the shipping system 14 Can be an appropriate response.

  If the alarm status message generated by the pump 12 is finally received by the alarm transfer system 16, in step 38, a confirmation message is automatically sent to both steps 42 and 44, and the logic 52 as described above. It is processed on the pump 12 by the operation of In step 42, it is evaluated whether the alarm status message has been successfully transferred to the alarm transfer system 16. If the alarm status message has not been successfully transferred to the alarm transfer system 16, the program proceeds to step 46 where the local alarm is visually displayed. However, if it is determined at step 42 that the alarm condition has been successfully received by the alarm transfer system 16, the program proceeds to step 48 and no local alarm is displayed by the pump 12.

  In this embodiment, the pump 12 includes a local delay timer 50 as described above. In step 28, this type of local delay timer 50 is started when an alarm status message is sent by the pump 12 to the shipping system 14. As described above, in step 38, shipping system 14 determines whether an alarm status message generated by pump 12 has been received by alarm transfer system 16. If the alarm status message is finally received by the alarm transfer system 16, the program also proceeds to step 44. Step 44 determines whether the local delay timer 50 should expire. This determination in step 44 occurs according to rules, algorithms or instructions. In particular, the determination is preferably that an acknowledgment 54 of receipt of the alert message is sent by the medical personnel at 58, passes through steps 60 and 62, and finally passed to step 54, where the acknowledgment message is Whether or not to be transmitted to step 44 is considered. If the local delay timer 50 (FIG. 1) exceeds its waiting time, and preferably under the rules, algorithms and rules governing step 44, an acknowledgment of the alarm status message is passed through step 54. If not received from the shipping system 14, the logic 52 (general arrow in FIG. 1 or FIG. 4) in the pump 12 is set to send a local alert message. However, upon receipt of an alert status message acknowledgment from the shipping system 14 at 54, the local delay timer 50 stops counting and no local alert message is generated. The length of the delay set in the local delay timer 50 can be set, for example, according to the priority of the type of alarm 28 generated or the type / concentration / name of the drug being infused by the pump 12. Further, if receipt of an acknowledgment of an alarm status message arrives from step 54 after a local delay timer 50 timeout, so that the local alarm has already started according to a rule, algorithm or instruction, the patient treatment system 10 The local alarm can be stopped, the local delay timer 50 can be restarted, or both.

  Upon receiving an alarm condition at the monitor / control system 18, the monitor / control system 18 displays the alarm condition at 56. This display can take the form of a visual, auditory or tactile display. For example, the display may sound an audible alert and indicate to the clinician that an alert status message has been received. Furthermore, the display may display information related to the alarm status message on the observation screen. Further, the display can include activation of a visual indicator of receipt of an alarm status message, such as a flash. Finally, the display may take the form of a tactile display, for example a vibrating device that indicates the clinician receives an alarm status message. This list of possible displays is intended to exemplify the displays or instructions that the monitor / control system 18 may use. However, it should be understood that this list is exemplary and not intended to be limiting. As a result, any type of display that attracts, displays, or otherwise communicates the contents of the alarm status message to the receipt of the alarm status message within the scope of the patient treatment system 10 of the present invention. Is intended.

  Upon receipt of the alert status message by the monitor / control system 18, the clinicians can return a “acknowledgement of receipt” message to the shipping system 14 if their destination device allows two-way communication. Generating and sending this type of acknowledgment message occurs at 58 at the monitor / control system 18. An acknowledgment receipt message is sent from the monitor / control system 18 to the alert forwarding system 16 at 60, and an acknowledgment of receipt of the alarm status message is passed to the shipping system 14 at 62. Step 62 determines whether the alert message 28 previously transmitted from the shipping system 14 has been acknowledged. If not acknowledged, the program proceeds to 40 where the higher level scheme is determined according to rules, algorithms or instructions.

  If it is determined at step 62 that an alarm condition acknowledgment message has been received, the program proceeds to step 54 where an acknowledgment message is transmitted from the shipping system 14 to the pump 12 at 44. At 64, this alarm condition 28 is evaluated to determine whether this alarm condition requires an indication of a local alarm on the pump 12, according to rules, algorithms or instructions. Whether this type of alarm condition 28 requires the display of an on-site alarm on the pump 12 is determined according to specific rules, algorithms or instructions programmed into the pump 12. If the alarm condition 28 requires an on-site alarm to be displayed on the pump 12, this type of alarm is displayed at 46. If the alarm condition 28 does not require a local alarm to be displayed, the program proceeds to 42 to determine whether the alarm condition has been successfully transferred to the appropriate personnel through the shipping system 14 and the alarm transfer system 16. Be evaluated.

  In addition to sending an alarm status message in step 28, the creation of an alarm condition in 26 moves the program running on pump 12 in accordance with logic 52 to step 66 so that pump 12 It is determined whether or not the audible alarm is suppressed. Determining whether the pump 12 is configured to represent an audible alarm that is a local alarm is performed according to rules, algorithms or instructions programmed into the pump 12.

  If, in step 66, it is determined that the pump 12 is configured to suppress the local audible alarm according to the rules, algorithm or instructions, the program proceeds to step 68 and the local audible alarm is transmitted to the rules, algorithms or instructions. Whether to delay or suppress based on the instruction is evaluated, including but not limited to referring to the current stage of the local delay timer 50. If at step 68 it is determined that the local audible alarm should be suppressed, the program proceeds to step 70. Step 70 determines whether the local delay timer 50 has run out of the predetermined delay time and whether the alarm condition still persists. If the local delay timer 50 runs out of its local delay time and the alarm condition still persists, the program proceeds to step 72 and the pump 12 will continue even if it was previously determined that the alarm was suppressed. Provide local audible alerts. In this embodiment, the reason that alarm suppression is disabled is that it fails to receive an acknowledgment of receipt of the alarm notification, as evidenced by the expiration of the local delay timer 50, according to a rule, algorithm or instruction. It has been determined that an alert needs to be generated. Also, according to rules, algorithms or instructions, alerts can be generated immediately or after further action is taken (eg to see if the acknowledgment or receipt of an alert message returns). Resend the alert message). If it is determined at step 66 that the pump 12 is not configured to suppress the local audible alarm display, the program proceeds to step 72 and the pump 12 provides a local audible alarm. One or both of local audible alerts or visual alerts can be generated at 46 and 72.

  Although the embodiment of the patient treatment system 10 described above has an alarm forwarding system 16 that sends a “successful receipt” acknowledgment of an alarm status message, this is not essential for the patient treatment system 10. Further, these embodiments of the patient treatment system 10 have a high-level scheme 40, which is also not essential for the patient treatment system 10. Similarly, various distinct actions, evaluations, messages that are transmitted or suppressed, alarms that are activated or suppressed, and similar aspects of the above-described embodiments and other illustrated embodiments may be eliminated. Or may be added in a wide variety of permutations and combinations and still exist within the scope of the present invention. The patient treatment system 10 allows for the management of all types of alarms with the term “management”. Various aspects of “managing” the alerts provided herein are intended to be illustrative and not restrictive.

  FIG. 5 illustrates the interrelationship between the pump 12 and an administrator, eg, an information technology (IT) professional, biomedical engineer or nurse or other clinical personnel responsible for treating the patient. And shows the interrelationships through the shipping system 14, the alarm forwarding system 16, and the monitor / control system 18. If the administrator wishes to configure the pump 12 at 74, the administrator sends a command via the monitor / controller system 18 at 76.

  If the administrator wishes to reconfigure the pump 12, at 78, the monitor / controller system 18 “sends a pin” to the alarm forwarding system 16 to determine which pump 12 is available for configuration. Next, at 80, the alert transfer system 16 "sends a pin" to the shipping system 14 to determine which pumps 12 are available for configuration. At 82, the pump 12 in communication with the shipping system 14 sends its identification information and data to the shipping system 14. This can be a near real-time push transfer of data from the pump 12 to the shipping system 14 or the data is pulled in response to a pump request or “pin” by the shipping system 14. sell. The shipping system 14 then sends information about the pump 12 that is available to the alarm transfer system 16, at 84 this type of information is sent to the monitor / controller system 18, and at 86 the monitor / controller 18 Display relevant information about this particular pump 12, including the current status of the pump and the range of options available for reconfiguration. The information is made available to the administrator by the monitor / control system 18 that displays this information.

  Once the administrator has determined which pumps 12 are available for configuration, at 88, the administrator selects that pump 12 to be configured. The administrator makes the desired selection in the monitor / controller system 18, and then at 90, the monitor / controller system 18 displays the newly configured settings for this particular pump 12. When the administrator enters specific parameters of the desired pump 12 configuration at the monitor / control system 18, the monitor / controller system 18 passes this information to the alarm transfer system 16, and at 92, the alarm transfer system 16 To the shipping system 14, and the parameter configuration is transmitted to the pump 12 selected by the shipping system 14 at 93, received by the pump 12 at 94, and executed at the pump 12 at 95.

  Similar methods are used by an administrator to configure the shipping system 14, the alert forwarding system 16 or the monitor / controller system 18 itself. If the monitor / controller system 18 itself needs to be configured, the configuration can be done directly by entering a new configuration into the monitor / control system 18. However, it may be desirable to warn others of this type of configuration change via the shipping system 14 or clinical system 24. In this case, the monitor / controller system 18 sends the configuration information to the alarm forwarding system 16, which sends this information to the shipping system 14, which then sends the information to the shipping system. Transmit to the appropriate location according to the rules, algorithms or instructions in FIG.

  If the alarm transfer system 16 needs to receive a new configuration, configurable aspects of the alarm transfer system 16 are displayed on the monitor / controller system 18. The desired configuration for the alarm transfer system 16 is input to the monitor / control system 18, which then transmits the new configuration to the alarm transfer system 16 to be implemented. It is also desirable to warn others of this type of configuration change via shipping system 14 or clinical system 24. In this case, the alert transfer system 16 sends the configuration information to the shipping system 14, which then sends the information to the appropriate location according to the rules, algorithms or instructions in the shipping system 14.

  If the shipping system 14 needs to receive a new configuration, configurable aspects of the shipping system 14 and the alarm forwarding system 16 are received from the shipping system 14, passed through the alarm forwarding system, and displayed on the monitor / controller system 18. Is done. The desired configuration for the shipping system 14 is input to the monitor / control system 18 which then transmits the new configuration to be implemented by the shipping system 14. It may also be desirable to warn others of this type of configuration change via the shipping system 14 or clinical system 24. In this case, the shipping system 14 sends the information to the appropriate location according to the rules, algorithms or instructions in the shipping system 14.

  In this embodiment, interface 22 and clinical system 24 are not explicitly shown. However, the interface 22 and clinical system 24 may be integrated into the monitor / controller system 18. However, the interface 22 and clinical system 24 may be separate and independent systems, or the functions of the interface 22 and clinical system 24 may, in whole or in part, be the shipping system 14, the alert transfer system 16 or the monitor / control system 18. It should be understood that may be performed by: In addition, any of these types of functions or elements, including that the functions, elements, or both of the shipping system 14, the alarm transfer system 16, the interface 22, the clinical system 14, and the monitor / control system 18 are incorporated into a single system. It is within the scope of the patient treatment system 10 to be incorporated into any permutation or combination.

  FIG. 6 shows the operation of the patient treatment system 10 regarding the alarm transfer function. When an alarm condition occurs at 26, the pump 12 determines at 96 whether the pump 12 is connected to the shipping system 14. If the pump 12 is not connected to the shipping system 14, the program proceeds to step 98 where the pump displays a visual alarm or an audible alarm or both on the pump 12 and the pump 12 is connected to the shipping system 14. Indicates no. If, at step 96, it is determined that the pump 12 is connected to the shipping system 14, the program proceeds to step 100. In step 100, the pump 12 sends an alarm status notification to the shipping system 14, and at 102, the shipping system 14 receives the alarm status notification. In addition to sending an alarm status notification to the shipping system 14, the program proceeds from step 100 to step 104 to pump the local alarm status indicating that the pump 12 is not connected to the shipping system 14. Whether 12 is configured is determined. If the pump 12 is configured to display this type of local alarm notification, the program proceeds to step 106, and this type of alarm condition is displayed or otherwise indicated. If the pump 12 is not configured to display this type of alarm notification, the program proceeds to step 108 and an operation as described below occurs.

  As described above, when an alarm condition is generated at 26 and the pump 12 is connected to the shipping system 14, an alarm status message is sent to the shipping system 14 at step 100 and received at step 102. In step 102, the alarm status message is evaluated according to rules, algorithms or instructions to determine whether the alarm status message should be forwarded to the alarm forwarding system 16, the monitor / controller system 18, or both. If at step 102 it is determined that the alarm status message should not be forwarded to one of the alarm transfer system 16 or the monitor / controller system 18, the program proceeds to step 98 and the pump 12 displays an alarm on the pump 12. Or generate.

  If at step 102 it is determined that the alarm status message should be forwarded to one of the alert forwarding system 16 or the monitor / controller system 18, the program proceeds to step 110 of the alert forwarding system 16. In step 110, the program determines, according to rules, algorithms or instructions, whether the alert condition should be routed to the recipient and to which recipient if it should be routed. If it is determined that an alarm status notification is to be forwarded to the recipient, the program proceeds from step 110 of the alarm transfer system 16 to step 112 of the monitor / controller system 18.

  In order for the program to reach step 110, an alarm status message must be received by the alarm transfer system 16. Accordingly, at step 110, the program proceeds to step 114 to determine whether the alert forwarding system 16 is configured to send an acknowledgment of successful receipt of the alert notification message. If the alert forwarding system 16 is not configured to send this type of acknowledgment, the program proceeds to 116 and no further action is taken. However, if the alert forwarding system 16 is configured to send such an acknowledgment, the program proceeds to step 118, where such an acknowledgment is generated by the alert forwarding system 16 and sent to the shipping system 14. And received in step 120. If it is determined at step 120 that the alarm status message has been successfully received by the alarm transfer system 16, the program proceeds to step 108 of the pump 12.

  If it is determined in step 108 that the alarm status message generated in step 100 has not been received by the alarm transfer system 16, the program proceeds to step 106 and the alarm status message has not been received by the alarm transfer system 16. Is displayed on the pump 12. However, if it is determined at step 108 that the alarm status message generated at step 100 has been successfully received by the alarm transfer system 16, the program proceeds to step 122 and no alarm is displayed on the pump 12 locally.

  If it is determined at step 120 that the alarm status message received from the pump 12 by the shipping system 14 at step 102 has not been successfully transferred to the alarm transfer system 16, the program proceeds to a higher level scheme 40 and Level escalation is determined according to rules, algorithms or instructions as described above. Also, if at step 120 it is determined that the alarm status message generated by the pump 12 and received by the shipping system 14 has been successfully received by the alarm transfer system 16, the program also proceeds to step 44 and the local The delay timer 50 is canceled and no alarm message is generated.

  If at step 112 of the monitor / controller system 18 an alarm status indication is shown to the monitor / control system 18, the program proceeds to step 124 where the recipient of the alarm status message acknowledges receipt of the alarm status message. An opportunity is given. If the recipient chooses to generate an acknowledgment of receipt of this type of message, the program proceeds to step 126 of the alert forwarding system 16 and the acknowledgment is passed to step 128 of the shipping system 14. Step 128 determines whether the recipient has acknowledged receipt of the alarm status message sent by the pump 12. If the answer is “yes”, the program proceeds to step 130, an acknowledgment is sent from the shipping system 14 to step 44, the local delay timer 50 is canceled, and therefore no alert message is generated.

  If an alarm status indication is sent to the monitor / control system 18 at step 112, the program proceeds to step 132 where it is determined whether the alarm status can be remotely cleared according to rules, algorithms or instructions. If the alarm condition cannot be cleared remotely, the program proceeds to step 134 and no further action is taken. However, if the alarm condition can be remotely cleared, the program proceeds to step 136 where the alarm can be cleared by a qualified clinician in the monitor / control system 18.

  The program then proceeds to step 138 of the alarm transfer system 16. Step 138 passes an alert clear message to step 140 of shipping system 14, which is passed to pump 12 at step 142. In step 142, the pump alarm is cleared at pump 12. If the pump alarm is cleared at pump 12 at step 142, the program proceeds to step 144 of shipping system 14. In step 144, shipping system 14 is notified that the alarm status message previously generated by pump 12 in step 100 has been remotely erased. The program then proceeds to step 146 of the alert transfer system 16 and the local alert notification is sent to the appropriate recipient as determined by the rules, algorithms or instructions operating on the alert transfer system 16. The Further, the program proceeds to step 148 of the monitor / controller system 18 where the local alarm condition is indicated in the appropriate monitor / control system 18 indicating that the alarm condition notification has been cleared.

  The program then proceeds to step 150 to determine whether the alarm condition has been resolved. If the alarm condition is cleared, the program proceeds to step 152 of the pump 12 and the pump 12 alarm is cleared. If, at step 150, the program determines that the alarm condition has not been cleared, the program proceeds to step 40, where a higher level scheme is initiated and appropriate action is taken according to previously determined rules, algorithms or instructions. Can be taken to clear the alarm condition. In step 144, the program also proceeds to step 72 and, as described above, if the pump 12 is not configured to suppress the local audible alarm, the pump 12 provides a local audible alarm.

  The “alarm clear message” received the original alert when the alert is cleared, either manually by the clinician or automatically according to rules, algorithms or instructions operating on the patient treatment system 10 It may be sent to all entities. This type of alert clearing message may indicate how, when, and by whom the alert was cleared, an indication of what the original alert was, its time stamp, and how the alert was cleared May be included. Further, although the alarm was shown as being cleared at a location, the alarm could be either a pump 12, a delivery system 14, an alarm forwarding system 16, a clinical system server 24, or a monitor / control system 18, a clinical worker. May be deleted from anywhere that has access to the patient treatment system 10. It may be desirable to clearly indicate or emphasize to the pump 12 itself that the erasure occurred remotely and alert personnel taking care near the origin of the erasure. Further, if the alert is cleared locally before being remotely cleared, the shipping system server 14 receives a notification of this occurrence and forwards this type of notification to the remote recipient.

  In addition, if the alarm is cleared remotely but is not cleared locally, the clinician can remotely clear the alarm but be prepared to check the pump 12 and forget to clear the pump alarm locally. After expiration of the predetermined time, it is desirable to restart the alarm sequence described herein using the local delay timer described above.

  FIG. 7 illustrates an embodiment of a patient treatment system 10 in which an infusion program operating on the pump 12 is modified or replaced by an operator. In this embodiment of the patient treatment system 10, the pump 12 must be connected to the shipping system 14 in order to be controlled by the monitor / controller system 18 as described below. In addition, the pump 12 must have a suitable drug library with settings selected or configured by the manufacturer or, more preferably, by the medical institution so that the infusion program can be used for alarm management purposes. It can be modified or replaced remotely from the monitor / control system. The drug library must be stored in the pump or otherwise accessible to the pump 12. In this embodiment, an appropriate person or an authorized person, such as a nurse providing treatment to a patient, selects some aspect of the operation of the pump 12 relative to the patient in their respective monitor / controller system 18. . For example, as shown in FIG. 7, in step 154, the clinician can select an infusion titration. As a result, at 156, the clinician accesses a programming screen on the monitor / controller 18. The clinician then enters the desired programming information at the programming screen of the monitor / control system 18 at step 158. Thereafter, the method proceeds to step 160 where the clinician confirms the program information. The method then proceeds to step 162 where the monitor / controller system 18 sends new program information to the alarm transfer system 16 and is received at step 164. In step 164, the alert forwarding system sends a programming command to shipping system 14 and is received in step 166. In step 166, shipping system 14 sends a program command to infusion pump 12, and in step 168, the program command is received and incorporated into pump 12. The pump 12 may operate immediately with new or modified program instructions, as shown in FIG. 7, or may proceed in a delayed manner after on-site or remote verification.

  As can be seen in the description of the patient treatment system 10, there are specific steps that are performed as part of the logic, whether software or individual logic on the various elements of the patient treatment system 10 and the pump 12. . However, there are also specific steps that are performed by clinicians who are not part of this type of logic and are not performed by this type of logic. If the process involving the patient treatment system 10 includes steps performed by the clinician but not performed by the patient treatment system 10, the clinician, regardless of whether the embodiment includes the pump 12 or the monitor / controller 18 The process steps performed by are not part of the patient treatment system 10.

  Also, as shown in FIG. 7, at 169, the pump 12 sends a confirmation to the shipping system 14 that infusion by the pump 12 has been initiated for the patient. Shipping system 14 receives confirmation at 170 that infusion by pump 12 has started and passes this information to alarm forwarding system 16 at 172. In step 172, the alarm transfer system 16 sends a confirmation to the monitor / controller 18 at 174 that the pump 12 has begun infusion. In step 174, monitor / controller system 18 displays a confirmation that infusion by pump 12 has started. In step 174, the monitor / controller system 18 displays that the infusion has been initiated by the pump 12. This confirmation is also sent from the monitor / controller 18 to the shipping system 14 (via the alert transfer system 16) at step 176. In step 176, shipping system 14 determines whether the infusion initiated by pump 12 is the desired infusion programmed by monitor / controller 18. If the injection is not correct, the shipping system 14 proceeds to step 40 where the higher level scheme is initiated and actions are taken according to the rules, algorithms or instructions set in the higher level scheme.

  FIG. 8 shows another management function of the patient treatment system 10. In this function, the clinician transfers authority for one or more pumps 12 to another clinician. To access this function, both the clinician performing the move and the clinician receiving the transfer of authority to the pump 12 have appropriate access to the shipping system 14 and the alert forwarding system 16, for example, each clinical Must be through each monitor / control system 18 with the appropriate interface of the worker. By accessing the monitor / controller system 18, at 178, the clinician selects a list of pumps 12 to be moved. The method proceeds to step 180 where the clinician selects the monitor / control system 18 to which authority for the pump 12 is transferred.

  The method proceeds to step 182, where the monitor / controller 18 for the person transferring authority for the pump 12 obtains a list of the selected pumps 12, the person monitoring / control system 18 that receives authority for the pump 12. And this information is received at 184. In step 184, alarm transfer system 16 forwards the list of selected pumps to selected monitor / controller 18, which receives authority for pump 12 at 186. At 186, each monitor / control system 18 displays a moved list of pumps 12 and asks for confirmation of movement. Next, at 188, the clinical personnel associated with the new authority for the pump 12 accepts a pump list move in their monitor / control system 18. Also, as a result of the clinician accepting the moving list of pumps 12, then at 190, the clinician's monitor / controller 18 displays the newly acquired list of pumps 12.

  In FIG. 9, the infusion monitoring function of the patient treatment system 10 is displayed. Pump 12 is configured to interact with shipping system 14. At 192, pump 12 sends non-alarm status information to shipping system 14 and is received at 194. Examples of this type of non-alarm status information include, but are not limited to, drug delivered, dose, rate, volume to be infused (VTBI) and duration of infusion. Step 194 transfers non-alarm status information from the pump 12 to the alarm transfer system 16, which is received at 196. Step 196 then routes the non-alarm status information of the pump 12 to one or more appropriate recipients as configured by rules, algorithms or instructions operating on the alarm transfer system 16. In step 198, each recipient of non-alarm status information for pump 12 receives this status information at a respective monitor / controller system 18. As a result, the monitor / controller system 18 displays non-alarm status information from the pump 12 so that the clinician can know this type of condition. When a particular clinician's monitor / control system 18 is monitoring multiple pumps 12, it can be configured to select and display individual information about each pump 12. In step 200, the clinician selects a pump 12 and sees details of the non-alarm status of that pump 12. As a result of selecting to monitor a particular pump 12, the monitor / controller system 18 displays non-alarm infusion status information for that pump 12 at 202.

  The patient treatment system 10 may also include features that affect the time period during which specific information is displayed on the monitor / controller system 18. FIG. 9 shows an example of this type of function. The program may proceed from step 202 to step 204, which is a timer that measures the amount of inactivity associated with the interaction between the clinician and the monitor / controller system 18. If the clinician does not interact with the monitor / controller system 18 and a sufficiently long time (eg, 10 seconds) has elapsed according to a rule, algorithm or instruction, the program proceeds to step 206 where the monitor / control system 18 Close the detailed view of the non-alarm status information provided by the particular pump 12. Of course, the time that must elapse before initiating closing the detail view in this manner can vary and may be selectable by the clinician to suit the clinician's preferences, or It may be preset according to a specific safety protocol. In addition, this feature includes determining what information is displayed in addition to the length of time that specific information is displayed, and for both, who is the clinical worker, You may consider what the condition is and the location of the clinician.

  As a result of transferring authority for one or more pumps 12 to another monitor / control system 18, the clinician can erase the moved pump 12 from his monitor / control system 18. Of course, the clinician must first transfer authority to the pump 12, as done in step 208, and the process described above is combined into a single step 208. The program then proceeds to 210 and the clinician erases the moved pump 12. The program then proceeds to step 212 where the monitor / control system 18 erases the pump 12 that was previously monitored but has now been transferred to another clinician.

  FIG. 10 shows an example of the monitor / control system 18. The monitor / control system 18 can interact with the mobile phone, laptop computer, tablet or alarm transfer system 16 and shipping system 14, can display information, and can enter information to alert Any other mobile device that can transmit to transfer system 16 and shipping system 14 may be used. As seen in part A of FIG. 10, the status of the monitored device at several different locations (eg, bed 2, bed 5 and bed 7) can be displayed on the main status screen 214. The information displayed on the screen is the name of the pump 12 and the injection state. Further, as shown in part B of FIG. 10, when a pump 12 is selected from the main status screen 214, details of the infusion generated by any particular pump 12 can be displayed. For example, as shown in the example of Part B of FIG. 10, when the pump 12 is shown as “injector 1” located in “bed 2”, the state “injecting” is indicated and similarly injected. The drug that is present (in this case “dopamine”) is also indicated. Furthermore, the concentration of dopamine (5 mg / 100 ml) is indicated as well as dose (5 ml / hour), rate (250 ml / hour) and VTBI (500 ml). The designation “patient” can of course be replaced with the designation “bed” without departing from the scope of the present invention.

  As shown in part C of FIG. 10, the alarm status can also be displayed on the monitor / controller system 18. In this case, the pump 12 shown as “injector 3” located in “bed 2” has reached the end of its injection program. As a result, an “injection end” alarm message is generated. One possible consequence of generating this type of alarm message may be that the monitor / control system 18 itself indicates an alarm. In addition to indicating the status of a particular pump 12 (here “infusion completed”), the monitor / control system 18 also activates a visual, audible or tactile alert and alerts the clinician receiving this alert message. May be.

  Furthermore, the display order of the pumps 12 being monitored can be changed to represent the priority of their respective states. For example, as shown in part C of FIG. 10, the pump 12 designated by “injector 3” of “bed 2” is more than the other pumps 12 due to the presence of an alarm message associated with this particular pump 12. High priority. As a result, this pump 12 is listed higher in the display of the monitor / control system 18 than the other pumps 12 in the lower priority state and draws attention to the enhanced state of this pump 12.

  Throughout this description, repeated descriptions have been made to “rules, algorithms or instructions”. These rules, algorithms or instructions are substantially determined to be useful, including but not limited to promoting safety or improving effectiveness, longevity or ease of use. Anything can be targeted. In addition, when a clinician is configuring or reconfiguring the pump 12, these rules, algorithms or instructions may be used by the clinician if the particular configuration is outside the permissible boundaries or at risk. A safety device may be included to warn and a clinician may be required to confirm this type of configuration before being received by the patient treatment system 10. Further, where, when, and to whom an alert message can be forwarded or communicated is substantially several, regardless of whether or not an upper level scheme 40 of alerts existed or existed. Some of the considerations that may be taken into account may include available staff, clinical care area (CCA), treatment being administered, type of medication, patient condition, time of day, and day of the week.

  The patient treatment system 10 described herein, in one or more of the disclosed embodiments, is a current system that has improved patient safety and improved ease of use for clinicians. It has an advantageous effect over it. With regard to improving patient safety, the patient treatment system 10, in one or more embodiments, when the alert transfer does not reach the clinical personnel or when they cannot respond or acknowledge the alarm in a timely manner, Improve patient safety by sounding an alarm. In this way, the absence of a clinician or the chance that the clinician will fail to respond to the alert is reduced. Absence of clinical personnel or clinical personnel by creating high-level procedures for alerts that help medical personnel back up each other in case the first alarm is overlooked or fails to respond Is less likely to fail to respond to the alarm, thus improving patient safety. In addition, patient safety is improved by one or more embodiments of the patient treatment system 10 because the response time by medical personnel to a reverse injection event or a pending reverse injection event is reduced. Even when the medical personnel are physically remote from the pump 12, this response time is reduced by alerting the medical personnel to this type of or current adverse event.

  Further, patient safety is improved in one or more embodiments of the patient treatment system 10 by creating a system for alarm evaluation and dispatch that operates according to rules, algorithms or instructions, resulting in alarm management logic. Are removed from the individual and various monitor / controller systems 18 and corresponding communication technologies, and instead are replaced with rules, algorithms and algorithms that operate on a smaller number of devices (possibly a single shipping system 14). Dominated and controlled by a reduced set of instructions (in some cases a single set).

  Further, patient safety can be achieved in one or more embodiments of the patient treatment system 10 without exposing the patient to unnecessary contact or without the pump 12 being programmed with the pump 12 itself. Improve by allowing the person to program or modify the injection. Since the clinician does not need to be physically present or in direct contact with the pump 12, the likelihood of contamination of the patient by the clinician is reduced. Further, since there is no need for the physical practitioner to be physically present or to be in direct contact with the pump 12, when multiple clinical practitioners utilize the same infusion pump 12, multiple clinical practitioners The possibility of cross-contamination is reduced. Thus, first, the pump 12 is not contaminated by the clinician, and even if the pump 12 is first contaminated, the next clinician changes or modifies the programming of the pump 12. Alternatively, cross-contamination is eliminated because it is not necessary to contact or be in the vicinity of the pump 12 to check the condition of the pump 12 or the infusion program running on the pump 12. If necessary, the confirmation or double check of the program value previously performed on the pump 12 may be performed by the clinical personnel of the monitor / control system 18.

  In yet another embodiment of the patient treatment system 10, patient safety is improved by reducing the likelihood of erroneous treatment being administered. Instead of having to be familiar with the interfaces of many devices that can be involved in delivering treatment, it is sufficient for the clinician to be familiar with a single interface (monitor / control system 18). The possibility of administering the treatment is reduced. Further, in one or more embodiments, there is a review incorporated into the rules, algorithms, or instructions implemented in the patient treatment system 10, thus reducing the likelihood of giving an incorrect treatment.

  The patient treatment system 10 also improves ease of use for clinicians. For ease of use, in one or more embodiments of the patient treatment system 10, the patient treatment system 10 causes the medical personnel to move to the pump 12 to clear the alarm. Alarms can be cleared remotely instead of requiring Further, in one or more embodiments of the patient treatment system 10, ease of use for medical personnel reduces the required time and difficulty associated with modifying or updating programming, and infusion programs. Improve by updating. In addition to creating a simplified process for modifying or updating this type of programming, ease of use allows a clinical practitioner to use a single interface (instead of an interface for each device that may be associated with administering therapy). For example, it is sufficient to be familiar with only the monitor / control system 18).

  Further, the patient treatment system 10, in one or more embodiments, provides an alarm message even when the medical personnel are not in the vicinity of the device (ie, the medical personnel are outside the visual and auditory range of the pump 12). Improve ease of use for medical personnel by sending to medical personnel. Further, in one or more embodiments, information regarding alarm messages useful or necessary for medical personnel, such as pump 12 ID, pump 12 location, patient information, pharmaceutical information, program information, etc. It is given in the alert message to help the parties evaluate the alert. As a result, medical personnel can have a greater range from their patients and can provide safe and effective treatment.

  In one or more embodiments of the patient treatment system 10, another aspect of the patient treatment system 10 that improves ease of use for medical personnel is that hospital alarm noise is reduced, This is especially useful at night. The reduction in alarm noise is due to the processing of alarms according to rules, algorithms or instructions for removing false or unnecessary alarms, thereby producing less audible or visual alarms. Reducing the number of unpleasant, distracting, false or unnecessary alarms is beneficial not only for medical personnel but also for patients and other nearby patients.

  Not all of these advantages are present in all embodiments of patient treatment system 10, some embodiments may have only one of these advantages, and other embodiments are Have several advantages, and some embodiments may have all the advantages. The present disclosure has been directed to specific embodiments, combinations, configurations and relative dimensions. However, it is to be understood that the description provided herein is provided to illustrate and illustrate the invention and is not intended to limit the scope of the invention. It should be further understood that changes and modifications to the description provided herein will be devised by those skilled in the art. Therefore, the scope of the present invention should be limited only by the claims.

Claims (19)

A patient treatment system comprising at least one medical pump, an alarm generation system, a dispatch system, and an alarm destination,
Each medical pump generates a data message that includes a unit of information regarding pump therapy status data, pump operating point data, or both pump therapy status data and pump operating point data;
The alarm generation system receives the data message from the medical pump;
If the condition is met, evaluate the data message according to a first algorithm to generate a trigger;
If the trigger generates, generate an alarm message,
If the trigger generates, evaluate the data message according to a second algorithm to suppress higher level alerts;
Configured as
The dispatch system is connected to the alert generation system and configured to forward the alert message to the alert destination according to a third algorithm;
The alarm destination is connected to the shipping system and represents an alarm when an alarm is received by the alarm destination;
The unit of information is a necessary input for both the first and second algorithms;
Patient treatment system. A management interface providing access to a rules editor to an administrator of the patient care system;
The rule editor modifies at least one of the first and third algorithms so that a clinical care area (CCA) of the medical pump is a critical input;
The system of claim 1.   The system of claim 2, wherein the data message from the medical pump includes a second unit of information that includes the clinical care area (CCA) of the medical pump. A database accessible to the alarm generation system;
The data message from the medical pump includes an ID associated with the medical pump;
The clinical care area (CCA) of the medical pump is derived from the database using the ID associated with the medical pump;
The system according to claim 2. A management interface providing access to a rules editor to an administrator of the patient care system;
The unit of information regarding pump treatment information includes information regarding the type of drug being infused by the medical pump;
The rule editor modifies at least one of the first or third algorithms so that the type of drug being infused by the medical pump is a critical input;
The system of claim 1. A management interface providing access to a rules editor to an administrator of the patient care system;
The rule editor modifies a protocol in which the higher level alert is suppressed;
The system of claim 1. The upper level alarm is an audible alarm in the medical pump;
The protocol (i) suppresses the higher level alert for a period of time, and (ii) clears the higher level alert if an alert clear message is received from the alert destination by the alert generation system.
The system according to claim 6. The rules editor allows the administrator to specify a second protocol in which the higher level alert is suppressed,
The first or second protocol is applied by the alarm generation system based on the type of drug being infused by the medical pump.
The system according to claim 6. The rules editor allows the administrator to specify a second protocol in which the higher level alert is suppressed,
The first or second protocol is selected and applied by the alert generation system based on a clinical nursing area (CCA) where the medical pump is located.
The system according to claim 6. A method for monitoring and controlling alarms in a patient treatment system, wherein the patient treatment system includes at least one medical pump that generates a data message, an alarm generation system that receives the data message from the medical pump, and the alarm generation A dispatch system connected to the system; and an alert destination connected to the dispatch system, wherein the alert destination represents an alert when an alert message is received by the alert destination, the method comprising:
If the condition is met, evaluating the data message according to a first algorithm to generate a trigger;
If the trigger generates, generating an alarm message;
If the trigger generates, evaluating the data message according to a second algorithm to suppress higher level alerts;
Forwarding the alert message to the alert destination according to a third algorithm;
Including
The data message includes a unit of information regarding pump therapy status data, pump operating point data, or both pump therapy status data and pump operating point data;
The unit of information is a necessary input for both the first and second algorithms;
Method. The alert message is forwarded by the shipping system to a first alert destination;
The higher level alert includes a second alert forwarded by the shipping system to a second alert destination;
The system according to claim 10. The method for monitoring and controlling alarms comprises:
Receiving a response to the alert message from the alert destination;
Clearing the higher level alert after receiving the response; and
The system of claim 10, further comprising: The response is
An acknowledgment that an alarm status notification has been received at the alarm destination;
Confirmation that the alert message has been successfully transferred to the alert destination;
Local alarm clearing entered by the medical pump,
A configuration input by the medical pump;
A first change to the first algorithm in the shipping system; and
A second change to the second algorithm in the shipping system;
The system of claim 12, wherein the system is selected from the group consisting of: The third algorithm maps the alert message to a different set of alert destinations based on the unit of information;
The system according to claim 10. A non-transitory computer readable medium storing a program that causes a computer as part of a patient treatment system to monitor and control alarms of the patient treatment system, the patient treatment system generating at least one medical message A pump, an alarm generating system for receiving the data message from the medical pump, a shipping system connected to the alarm generating system, and an alarm destination connected to the shipping system, wherein the alarm destination is , Representing an alert when an alert message is received by the alert destination, and the method of monitoring and controlling comprises:
If the condition is met, evaluating the data message according to a first algorithm to generate a trigger;
If the trigger generates, generating an alarm message;
If the trigger generates, evaluating the data message according to a second algorithm to suppress higher level alerts;
Forwarding the alert message to the alert destination according to a third algorithm;
Including
The data message includes a unit of information regarding pump therapy status data, pump operating point data, or both pump therapy status data and pump operating point data;
The unit of information is a necessary input for both the first and second algorithms;
Non-transitory computer readable medium. The alert message is forwarded by the shipping system to a first alert destination;
The higher level alert includes a second alert forwarded by the shipping system to a second alert destination;
The non-transitory computer readable medium of claim 15. The method of monitoring and controlling comprises:
Receiving a response to the alert message from the alert destination;
Clearing the higher level alert after receiving the response; and
Further including
The non-transitory computer readable medium of claim 15. The response is
An acknowledgment that an alarm status notification has been received at the alarm destination;
Confirmation that the alert message has been successfully transferred to the alert destination;
Local alarm clearing entered by the medical pump,
A configuration input by the medical pump;
A first change to the first algorithm in the shipping system; and
A second change to the second algorithm in the shipping system;
The non-transitory computer readable medium of claim 17, selected from the group consisting of: The third algorithm maps the alert message to a different set of alert destinations based on the unit of information;
The non-transitory computer readable medium of claim 15.

Images