Design and Implementation of a Real-Time Clinical Alerting System for
Intensive Care Unit
Hsiao-Ting Chen
1, Wan-Chun Ma
2,
Der-Ming Liou
11
Telemedicine Lab, Institute of Health Informatics and Decision Making, National
Yang-Ming University, Taipei, Taiwan
2
Communication and Multimedia Lab, Dept. of Computer Science and Information
Engineering, National Taiwan University, Taipei, Taiwan
ABSTRACT
Nowadays many hospitals use clinical information systems (CIS) to improve patient health care and information management. CIS retrieves and manages patient information such as patient administration, laboratory data and medications. Specialized CIS, especially Intensive Care Unit (ICU) CIS, needs to handle more additional information. How to process and make use of this enormous amount of physiologic data generated by ICU is a significant topic in CIS design.
We have designed and implemented a real-time clinical alerting system for ICU, which executes alert algorithms on the database records of 63 ICU physiologic parameters. The user can create various alert rules with our rule editor to supervise the values or trends of these parameters. When an alert condition on a specific patient is detected, the system notices the clinicians in charge with mobile phones or pagers. With this functionality, up-to-date patient information is provided for clinicians’ use in judging the patient’s condition and making treatment decisions.
Figure 1: Infrastructure of the proposed clinical alerting system.
INTRODUCTION
ICU takes care of the patients who are seriously ill or who have undergone major surgical operations. The vital signs of these patients are very unstable, so their physiologic parameters need to be continuously monitored and analyzed in order to ensure their safety. ICU generates data incessantly, and all the accumulated data contributes to a huge database. How to analyze and utilize the database to help more and more ICU patients is a critical issue.
Most of the electronic monitors or devices in ICU only set off an alarm when their reading exceeds a predefined threshold. Schoenberg et al. found that most of the alarms generated by ICU equipments are clinically insignificant readings [1]. The alerting system we have designed provides an interface for defining alerting rule logics, so the user can retrieve more meaningful information from the original electronic equipment without extending their functionalities.
It takes tremendous resources to build ICUs and keep them in operation. The study by Shea et al. has pointed out that a computer-generated informational message directed to physicians would shorten 3.2% the LOS (Length of Stay) [2]. Since the LOS decreases, medical costs can be saved for the other use. Evans et al. have used clinical alerting system for hospital infection detecting and antibiotic abuse alerting [3]. Their study indicates that the cost of the antibiotic could be reduced after using the related clinical alerting system. We have contrived to make use of an alerting system in ICU to achieve a similar purpose.
Clinical alerting system also improves the efficiency of ICU medicaltreatment. Kuperman et al. evaluated the effect of an automatic alerting system [4]. The result reveals that the clinical alerting system shortens by 38% the time between patients having abnormal status and their clinicians proposing a treatment plan. In another case, Rind et al. alerted physicians via e-mail about increases in serum creatinine in patients receiving nephrotoxic
medications or renally excreted drugs [5]. They found out that when e-mail alerts were delivered, medications were adjusted or discontinued an average of 21.6 hours earlier than when no e-mail alerts were delivered.
An alerting system requires devices with which to notify physicians. Currently, hospitals commonly use pager as the primary communication tool due to its low data transmission power. Many prior alerting systems have also indicated that the pager is the preferred alerting tool [4,6,7]. The study by Wagner et al. reveals that more users preferred delivery information by pager than the other options [8]. In the investigation by our research, clinicians prefer pager and mobile phone as their communication tool. Our system supports the data transmission to both pagers and mobile phones. The user thus has more freedom in choosing a preferred communication device.
The objective of our research is to design and implement a real-time ICU clinical alerting system. The system automatically detects the physiological status of the patient. If the status conforms to the alert rule definitions, the system sends related messages to the clinicians via pagers or mobile phones. We hope that the medical quality of ICU can be improved with this system. Figure 1 shows the infrastructure of the system execution environment. The ICU database server, alerting system server and short message server are all connected together with appropriate networking. The short message server has the ability to send messages to clients with different protocols, such as FLEX for pagers and GSM for mobile phones.
METHODOLOGY 1. Data Source
The data source invoked in this system is from the CareMasterTM CIS used in a 14-bed Surgical ICU at
Taipei Veterans General Hospital [11]. The CareMasterTM CIS records several physiological
parameters such as heart rate, systolic and diastolic blood pressure, respiratory rate, temperature, and SpO2. Nurses take down the remaining parameters by
using personal digital assistants (PDA), webpads or tablet PCs. All the information is finally stored in a database driven by Oracle 8.0.5. Table 1 in the Appendix lists all the parameter names and their value collection methods that we used in the alerting system.
2. System Design
We used Microsoft Visual C++ 6.0 as the main
software development tool and Oracle PL/SQL for database stored procedure development. The alerting system consists of four modules: rule editor, notification editor, detecting engine, and alerting engine. Figure 2 shows the design of our alerting system.
Main User Interface: The interface design of the
system is depicted in Figure 3. We try to not only simplify the user interface, but also keep the important information easily visible. The upper frame shows the current alert rules. The lower frame shows the SICU information, which includes the patients’ names, bed numbers, and corresponding messaging clinicians. The lower frame shows the SICU information, which includes the patients’ names, bed numbers, and corresponding messaging clinicians. If the user click on a specific rule or patient information item, a correspondent dialog box will pop up for further editing operations.
Figure 2: System software design of the clinical alerting system.
Rule Editor: The user can use the rule editor (Figure
4(A)) to create alert rules. The rule editor lists all the physiological parameters stored in the CIS. The user can create alert rules according to the defined rule grammar. The rule editor first examines the validity of the created rule using the rule grammar. If the rule does not follow the definition, the rule editor will automatically notify the user for further correction. Valid rules will be parsed and saved in the database. By following the formatted rule information, the rule editor calls the database store procedures to create corresponding data views through Open Database Connectivity (ODBC). The system can query and retrieve data from the CIS database via these data views for efficiency.
We created the rule grammar by referencing some previous works [1,6,9,10] and taking clinicians’ opinions into consideration. The rule grammar itself is simple, intuitive, and easy to use. It can be separated into two parts: basic rules and advanced rules. The following section shows and explains the grammar:
1. Basic rules:
A. parameter > value (for example, Sys BP >
60)
B. parameter < value C. parameter = value
D. parameter not between value1 and value2 2. Advanced rules:
A. [Basic rules] for a time bound (for
example, Sys BP < 70 for 1 hour)
B. parameter increases (or decreases) for a
time bound (continuously)
C. parameter changes > (or <) value (per
sampling). (This rule compares the difference between current sampling value and the previous one of a specific parameter. If the difference is larger (smaller) than a given value, then the alert is activated. For example, heart rate changes > 15 per sampling)
For flexibility of alert rule creation, the user may add the keyword “&” (AND) to combine several different rules into a single alert rule (e.g. Heart Rate > 54 & Art Sys < 60 & FiO2 > 60 for 4 hour). Also, since we store the alert rules in the database, there is no limitation on rule number in this system.
Notification Editor: The notification editor (Figure
4(C)) provides a user interface for the user to set the alert messaging relationship between the ICU patient and the clinician.
Detecting Engine: The detecting engine invokes all
of the views at each predefined time interval for extracting matched data, then sends the data, which includes the event time, patient information, bed number, and abnormal biological status, to the alerting engine. Due to the isolated design of each system module, the user may add more rules without shutting down and restarting the detecting engine. The new rules will be handled during the next processing time.
Alerting Engine: The alerting engine combines the
data from the detecting engine and the related clinician information (including pager and mobile phone numbers) from the notification editor’s records
(A) (B) (C)
Figure 4: (A) Rule editor user interface. The user can click on the buttons to add parameter names or logical symbol for rule creation. (B) Instant messaging interface. (C) Notification editor user interface.
in order to construct proper message packages. These packages are transmitted to the short message service (SMS) server through TCP/IP network protocol. SMS is a delivery mechanism for short messages over the mobile network. It involves a store and forward way of transmitting messages to and from mobiles. The message (text only) from the sending mobile is stored in a central short message center, which then forwards it to the destination mobile. This means that in the case that the recipient is unavailable, the short message is stored and can be sent later. With this mechanism, message packages are delivered to the designated doctors’ pagers or mobile phones. The maximum size of the message is 60 characters for the pager and 159 for the mobile phone. If the message length exceeds the limitation, the system divides the message into several smaller messages before sending them out. All of the transmission transaction will be saved for further manipulation. In addition, an instant messaging interface has been implemented. The user can use it for direct contact with the medical staff (Figure 4(B)).
RESULTS
Our system is currently being tested and examined in the SICU. The nurses in this SICU send an average of 3 messages to the clinicians on 8-hour duty. In a questionnaire taken by the medical staff (30 people) of this SICU, 95% of the staff agreed that using mobile communication tools to inform them is a great help when the patient is in critical condition. Figure 5 shows pictures of the messaging results on the pager and mobile phone. From evaluating the messaging time, we have found that it takes the pager an average of 15 seconds and the mobile phone an average of 10 seconds to receive a message from the clinical alerting system.
DISCUSSION
There are many medical staff members on duty 24 hours a day in ICU to care for patients and collect their physiological data. Unfortunately, so much data that are created by ICU needs to be watched and recorded, and sometimes mistakes happen. It is difficult for humans to keep track of several parameters for a long time or to combine different parameter values for judgment.
The main purpose of our design is to create a system that can handle such repeated data collection and alert routines. With this system, medical human resources can instead be applied toward more meticulous care of the ICU patients. Furthermore, clinicians may make treatment decisions with the assistant of
real-time patient status messages in order to save precious time. The system currently processes 63 physiological parameters, but does not handle medication information. We think the alert of medication dosages and ADEs (Adverse Drug Events) should be taken care of when doctors propose the medication. The next step we are considering is to take both medication information and patient status into consideration in the rule grammar. In addition, we have decided to develop an individual patient rule set. At the moment, all patients are monitored with the same rules. In the design of the individual patient rule set, each patient is monitored with different alert rules according to his or her specific condition. Presently, we are still evaluating the necessity of these functionalities with our cooperative SICU.
ACKNOWLEDGEMENT
We thank for the Dr. Huey-Wen Yien and all the medication staffs in the SICU, Taipei Veterans General Hospital who help us a lot. We also appreciate Dr. Ying-Zhe Huang and Yu-Qun Chen as the medical knowledge consultants in this project. Finally, we thank the staffs in the Chunghwa Telecom for the messaging system information they provided.
Figure 5: Messaging results on the mobile phone and pager. The message showed on the mobile phone (above two pictures) is “2/28 10:21 SICU 27 Dave Wang MRN=456789 Heart Rate < 54 & Sys BP < 60”. The message showed on the pager is “2/28 10:21 SICU 30 Lisa Ling MRN=256321 K+ not between 3.4 and 4.7”.
REFERENCES
1. Schoenberg R, Sands DZ, Safran C. Making ICU Alarms Meaningful: A Comparison of Traditional vs. Trend-based Algorithms. Proc AMIA Symp 1999; 379-383.
2. Shea S, Sideli RV, DuMouchell W et al. Computer-generated Informational Messages Directed to Physicians: Effect on Length of Hospital Stay. JAMIA 1995; 2: 58-64.
3. Evans RS, Larsen RA, Burke JP et al. Computer Surveillance of Hospital-acquired Infections and Antibiotic Use. JAMA 1986; 256(8): 1007-1011.
4. Kuperman GJ, Teich JM, Tanasijevic MJ et al. Improving Response to Critical Laboratory Results with Automation. JAMIA 1999; 6: 512-522.
5. Rind DM, Safran C, Phillips RS et al. Effect of Computer-based Alerts on the Treatment and Outcomes of Hospitalized Patients. Arch Intern Med 1994; 154(13): 1511-1517.
6. Shabot M, LoBue M, Chen J. Wireless Clinical Alerts for Critical Medication, Laboratory and Physiologic Data. Proceedings of the 33rd Hawaii International Conference on System Sciences (HICSS); Jan 4–7, 2000; Maui, Hawaii. Washington, DC: IEEE Computer Society, 2000.
7. Wagner MM, Pankaskie MC, Hogan WR et al. Clinical Event Monitoring at the University of Pittsburgh. Proc AMIA Symp 1997; 188-192. 8. Wagner MM, Eisenstadt SA, Hogan WR,
Pankaskie MC. Preferences of Interns and Residents for E-mail, Paging, or Traditional Methods for the Delivery of Different Types of Clinical Information. Proc AMIA Symp 1998; 140-144.
9. Kost GJ. Critical Limits for Urgent Clinician Notification at US Medical Centers. JAMA 1990; 263(5): 704-707.
10. Sorin DI, David O, Julian Z. A Comprehensive Computerized Critical Laboratory Results Alerting System for Ambulatory and Hospitalized Patients. Medinfo 2001. 469-473. 11. Taipei Veterans General Hospital.
http://www.vghtpe.gov.tw/
APPENDIX
Fluid Output SvO2 PaO2 BUN
Fluid Intake *SpO2 PaCO2 Cr
Fluid balance Bowel sound HCO3- Ca++
*Heart rate GCS(EVM) Sat Cl-
*Sys BP LR Lactate Mg++
*Dias BP Pupil size WBC CRP
*Resp rate Weight Seg CKP
*Temperature FiO2 Lym MB
Pulmonary art sys T.V Band Albumin
Pulmonary art mean Rate Hb Bilirubin T/D
Pulmonary art dias PEEP Hct Amylase
*CVP P.S. PLT Gastric pH
*PCWP P.C. PT
Cardiac output I-E ratio APTT
Cardiac index Na+ FDP
Peripheral perfusion K+ D-Dimer
Breathing sound PH B sugar
Table 1: The physiological parameters processed in our clinical alerting system. The parameters with * mark are acquired by CIS automatically.
