Monitoring of patients in clinical settings such as operating rooms and intensive care units is a vital component to reducing medical errors and improving patient safety.1 A large amount of patient and equipment information cannot be readily detected from visual displays alone2; therefore, audible alarms are used to convey much of this information, providing annunciation once the monitored variable passes a threshold. However, current audible alarms have been criticized on many counts, having been cited as being noisy, inopportune, or generally perceived as a nuisance,3–6 as quite often being false or artifactual,5,7–9 as not conveying urgency that is matched to alarm severity,10–13 and as not being easily learned and identifiable.14–17 These criticisms reflect the broad and heterogeneous scope of the current problem with audible alarms, which will be referred to as the alarm problem. The current international standard for audible alarms governed by the International Electrotechnical Commission (IEC), in IEC/ISO 60601-1-818 does not successfully address the alarm problem,12,14 and this is troubling considering that a majority of alarm-related adverse events result in brain injury or death, carrying a median claim of nearly $500,000.19
Several organizations have made audible alarms a research initiative, including the Anesthesia patient Safety Foundation under the auspices of the American Society of Anesthesiologists and the American Association of Nurse Anesthetists,19 and The Joint Commission (the hospital accreditation and certification organization).20 However, despite a strong concurrence in opinion of the need for a redesign of current alarm annunciation designs, no single new strategy has yet to be agreed upon. Because the alarm problem is heterogeneous and complex (Fig. 1), novel strategies will likely draw on multidisciplinary scientific research and technologies. Ideally, a new strategy should be validated or evaluated for intended functionality and efficacy. However, results from usability testing obtained in a controlled laboratory setting may not be reproducible or applicable in more realistic settings either simulated or real. It has been suggested that an iterative approach to design and evaluation that spans all test settings may be necessary.10 Though there are software tools that aid in the design of experimental alarm sounds (Table 1, Ref. 1), and methods have been described for evaluation,14,21 there is currently no single tool that (1) combines alarm design and annunciation functionalities and (2) can be implemented in a clinical test setting, including real operating rooms. The portability of an alarm annunciation tool from the laboratory to the clinical setting is of particular relevance because it would facilitate the rapid validation of newly developed alarm sets for evaluation.
;)
Figure 1: PT-SAFE and proposed alarm design evaluation. Solutions to the alarm problem (left) are tested first in a controlled laboratory testing environment and then in more realistic settings such as a simulator and ultimately a real operating room (middle). PT-SAFE is implemented in each of these testing environments. PT-SAFE can be used to develop new annunciators, or map existing annunciators to vital signs streaming from a patient monitor, and, therefore, be used as an interface at any stage of alarm evaluation (right).
Table 1: Website References
To address these gaps and help streamline a feedback-driven, iterative approach to alarm design and evaluation, we have written a software program, Patient-Tracking Software for Audible Alarm Formulation and Evaluation (PT-SAFE). The goal is to provide the investigator with a versatile and sophisticated method for the design and annunciation of audible alarms that is also portable to simulation and real-world environments and that can be interfaced with existing monitoring equipment. To demonstrate the feasibility and illustrate an application of PT-SAFE, we interfaced the software with a fully functional simulated operating room equipped with a human patient simulator (HPS), anesthesia machine, and associated alarm equipment and obtained software performance measures during simulations of scripted intraoperative events.
METHODS
Software Design Considerations: Data Collection
PT-SAFE was installed on a Latitude E6410 laptop. Information about patient vital signs is obtained by polling a patient monitor, in our case an AS/3 (Datex-Ohmeda, now GE Healthcare, Chalfont St. Giles, UK), through a data port. The transmitted serial data packets are first parsed to identify relevant vital sign information. All of the vital signs are then logged to a time-stamped file on disk. The heart rate and SpO2 are used to generate a variable pitch pulse-oximeter continuous auditory display. Finally, all remaining vital sign information is passed to the alarm modules to annunciate an audible alarm, when appropriate.
Software Architecture
PT-SAFE was written in C++ using the JUCE library (Table 1, Ref. 2) to create a highly specialized graphical user interface (as shown in Fig. 2). An object-oriented approach was used with a hierarchical structure consisting of a top-level controller that handled one or more alarm modules (Fig. 3). Each alarm module contains 4 primary constituents: the alarm annunciator, or the sound itself, the vital sign to which the annunciator was mapped, the threshold values for triggering limit alarms, and an effect strength value to control an acoustic property of the annunciator. Each alarm module is created on a dedicated processing thread, and while this results in an increase in central processing unit (CPU) resources, it gives better precision in timing operations and eliminates the potential for audio dropouts. Further information regarding the sequence of data communication is given in Figure 4.
Figure 2: PT-SAFE graphical user interface (GUI). Alarm annunciators are added using dropdown menus (left). Annunciators are assigned to vital signs or machine variables using dropdown menus (middle). Parametric threshold levels for each module assignment are adjusted using slide cursors (right). These threshold levels trigger the annunciator to play over the computer loudspeaker. For example, note that in the first alarm module the systolic blood pressure is in the upper medium-priority region (>150 mm Hg), resulting in the annunciation of the IEC cardiovascular medium-priority alarm.
Figure 3: Software block diagram. This is an example with 2 alarm modules enacted, an amplitude modulation alarm and a gated alarm (Graphical User Interface box). Physiological data from a human patient simulator were sent via RS-232 to a data acquisition module consisting of a serial receiver and a serial parser (top), which passed the patient data to PT-SAFE. Heart rate and SpO2 information was handled by the pulse-oximeter model, and other vital signs were handled by the individual alarm module monitors. The audio path commenced at the pulse-oximeter model and was processed by each audible alarm module. An alarm was applied at user-specified effect strength only if it met the threshold criteria.
Figure 4: Sequence diagram. The data acquisition and auditory display were divided into those components that exist outside the software (outside the dashed rectangle, including the patient monitor, the serial receiver and parser, the hard disk, and the audio interface) and those components within the software (inside the dashed rectangle). Entry points to the software are designated by a black dot, and come from either the user via the graphical user interface (GUI) (in the case of alarm settings) or from the patient simulator (in the case of the vital signs). During acquisition, data from the patient monitor are parsed by a custom program written in Processing (
Table 1, Ref.
5) and then saved to an XML file on the local hard disk. The incoming patient data update the auditory alarms and the GUI accordingly. Finally, the output audio stream is initiated, followed by processing performed by each annunciator before being sent to the audio interface for alarm playback through a loudspeaker.
File Format
In the development of PT-SAFE, two types of shared data were encountered: physiological data shared between the computer and the monitoring device, and alarm-related data shared between PT-SAFE and a file on disk used for saving and loading. Among medical information providers, the extensible markup language (XML) file format has become the de facto standard for the exchange and storage of medical data.22 The XML format is hierarchical and open, meaning XML files can be easily read and written without proprietary handshaking. For these reasons, XML file format was chosen for the exchange of physiological data and the storage of alarm settings. Furthermore, by logging all patient states to disk in XML format, PT-SAFE could be used to rerun a case, either real or simulated. In this mode, the vital sign data are recreated internally to the software, thus producing a pulse-oximeter display and audible alarm annunciation in a real-time simulation of those vital signs.
Work Flow: Alarm Modules
The core components to build an alarm are contained within the alarm modules, whereby annunciators are mapped to vital signs and their associated thresholds. The monitoring component of each module accommodates every physiological variable tracked by the AS/3 monitoring system (Table 2), which is the system used in our METI patient simulation laboratory and is common in actual surgical suites. A dropdown menu shows that vital signs are available from the monitoring equipment, and a separate dropdown menu displays the available annunciators. Each vital sign also contains 4 parametric thresholds, with typical default values, representing medium- and high-priority levels for both supra- and infranormal values. By providing two threshold levels, alarms with graded urgency could be used to properly alert the clinician to the priority of the alarm. The status of the annunciator was governed by a parametric effect strength knob. This general purpose knob modulates the acoustic properties of the annunciator, and consists of 3 main states: normal (baseline), medium-priority, and high-priority, corresponding to the vital sign thresholds or limits. Once a vital sign value surpasses one of thresholds, the effect strength is applied to the annunciator accordingly.
Table 2: Physiological Monitors
Annunciators and Smart Alarms
To facilitate compatibility with existing sounds, PT-SAFE can load sounds from a hard disk for use as an annunciator. For example, the IEC alarms, which are available in a wave-file format (16-bit, 44.1 kHz, mono, see Table 1, Refs. 3 to 4), could be loaded for evaluation against newly designed alarms. In addition to IEC alarms, other alarm types, such as speech-based or rhythm-based alarms, song clips, recordings from a microphone, or any other sound that can be saved in a wave-format could be loaded in for playback. PT-SAFE supports up to 2 files for each module, representing medium- and high-priority alarms.
In addition, custom annunciators written in MATLAB (Mathworks, Natick, MA) can be imported; this allows for complex sounds or algorithms, such as trend-based monitoring, to be implemented by the user. Within the MATLAB framework, the user has access to information regarding the status of vital signs and could therefore create smart alarms that consider that state of multiple vital signs. Furthermore, a block of data is reserved within PT-SAFE that is accessible via the MATLAB interface. This memory block could be used to store any type of user data, but one use might be to save previous alarm states for the purpose of a using a slow-moving average to reduce noise and artifacts that can lead to false alarms. PT-SAFE then loads dynamic-link libraries (DLLs) created by the MATLAB Compiler using the freely available run-time libraries. This functionality provides the user with the ability to program alarm algorithms in MATLAB and rapidly stage them into a testing environment. A further description and an example program are provided in the Appendix.
Finally, several auditory filters were included that allow the user to implement alarm designs based on a train of pulsed tones.13 A description and visualization of these filters are given in Figure 5. When these general processing filters are applied to the train pulsed of tones, they change the perceived nature of the sound in distinct ways. For example, amplitude modulation is comparable to a tremolo effect and frequency modulation to a vibrato effect. By applying these filters in different combinations, alarm annunciators can be generated that are unusual compared to those found in existing medical equipment. Many of these auditory effects were chosen because of their known impact on human perception of urgency, which has been explored in several sonification studies.23–25
Figure 5: Current audible alarm design filters used in PT-SAFE. Starting at the top: Amplitude modulation adds a tremolo effect to a pulsed tone; frequency modulation produces a vibrato effect; distortion changes the timbre of the sound; pulse width modulation gates the duration of the pulse-oximeter beep; noise summation provides an intuitive link to respiratory etiologies; and combination of tones, such as harmonic intervals, can provide information about whether a vital sign is increasing or decreasing.
Evaluation
Computer performance tests were run with PT-SAFE to observe both the memory and CPU footprint with multiple audible alarm modules instantiated. The three criteria considered were the thread count, the percent CPU usage, and the number of bytes committed to memory. The average value of each of these criteria was recorded over a period of 100 seconds (Table 3). A baseline was obtained while the PT-SAFE was not running, and 7 conditions were tested with the software running. To determine audio quality, a fourth additional audio performance test was conducted to detect audio dropouts, which would be an undesirable artifact of an overloaded processor. The output audio was looped back to the computer and recorded to disk for a period of 100 seconds. A silence detection algorithm was used to find any gaps in the audio, indicating a dropout using Nuendo 5 “Detect Silence” feature (Steinberg, Hamburg, Germany).
Table 3: Performance Results
A METI HPS (Medical Education Technologies, Inc., Sarasota, FL) located at the University of Miami-Jackson Memorial Hospital Center for Patient Safety was monitored by an AS/3, connected to the laptop hosting PT-SAFE via a serial cable (Fig. 6). Vital sign variables were transmitted from the AS/3 via RS-232 at a baud of 9600 bits per second. The audible alarms were silenced on the AS/3 to prevent interference with the PT-SAFE alarms. The HPS was programmed to present stable vital signs for the first minute, followed by a spike in systolic blood pressure to 170 mm Hg at 100 seconds, a decrease in respiratory rate to 5 breaths per minute at 200 seconds, a decrease in oxygenation to 88% at 300 seconds, and a decrease in heart rate to 45 at 400 seconds after simulation onset. The time-to-annunciation was measured for the AS/3 and PT-SAFE to determine the precision of the delay to annunciation compared to the manufacturer's equipment. The number of trials was arbitrarily chosen to be 20, and average time-to-annunciation for each alarm event was calculated.
Figure 6: Simulation environment setup. A replica of an operating room was equipped with a METI–human patient simulator, anesthesia machine, and AS/3 monitor device. A laptop running the PT-SAFE software was connected to the AS/3 via a serial port. Audible alarm annunciation was presented via an external audio interface (PreSonus, Baton Rouge, LA) and loudspeaker (KRK, Deerfield Beach, FL).
On the software side, 4 audible alarm modules were instantiated on PT-SAFE to track systolic blood pressure, respiratory rate, O2 saturation, and heart rate. For each vital sign monitor, the default upper and lower threshold values were used. The 4 alarm modules were mapped to the following annunciators: IEC cardiovascular alarm for blood pressure, IEC ventilation alarm for respiratory rate, a MATLAB algorithm for the SpO2 alarm, and a pulsed tone with amplitude modulation for the heat rate alarm. The MATLAB algorithm was designed to simply provide a delay of 19 seconds to SpO2 alarm annunciation, as described by Görges et al.26 The custom alarm for heart rate was implemented using the alarm design tools in PT-SAFE, using a train of pulsed tones with amplitude modulation (modulation depth of 50% and modulation frequency of 10 Hz) applied.
RESULTS
Performance Testing
Computer performance tests revealed that with all 16 alarms modules enabled, PT-SAFE used 24 threads, 130 MB of memory, and 100% of the CPU. When 8 alarm modules were enabled, no audio dropouts were detected. Dropouts were not detected until 16 alarm modules were enabled, indicating an upper limit based on performance metrics for a comparably equipped computer.
Simulated Patient Testing
As described in the Methods, a simulation scenario was created in which an HPS was scripted to present changes in vital signs, such as an increase in blood pressure and a decrease in respiratory rate. The changes in HPS vital signs were scripted to occur at known intervals, and the time to annunciation postevent onset was measured for the AS/3 and PT-SAFE. These delays to annunciation were determined for the 4 events; with each one averaged over 5 trials. Over the grand average of 20 trials, it was found that the AS/3 had a mean time to annunciation of 21.7 seconds with a SD of 1.5 seconds, compared to PT-SAFE, which had a mean time to annunciation of 15.5 seconds with a SD of 1.8 seconds. Although the existence of the delays implemented by the AS/3 is known, the composition of the delays are a result of proprietary algorithms, and therefore not completely knowable.27 However, the time delay differences between the AS/3 and PT-SAFE become a nonissue if the researcher disables the AS/3 native alarm annunciation and allows the PT-SAFE software to handle annunciation of all audible alarms. As mentioned in the Methods section, this experimental setup is made possible by uploading wave-files of the native alarms into an alarm module.
Another key finding of the simulation testing was that the display of patient vital signs was limited by the transmission rate of the patient monitor. That is, the serial refresh rate of the AS/3 was 0.5 Hz, meaning vital sign information was sent to PT-SAFE every other second. For this reason, a lag was discovered between inducing an abnormal HPS state and the annunciation of the associated audible alarm. It should be noted that this lag is entirely dependent upon the patient monitor and will vary from manufacturer to manufacturer or model to model. However, as demonstrated by these results, the lag in transmitting vital sign information did not adversely affect the time-to-annunciation for PT-SAFE, as compared to the AS/3. In addition, the standard deviations in the times-to-annunciation were comparable, also indicating that the 2-second communication lag posed no significant barrier to timely and appropriate alarm annunciation. Moreover, as mentioned above, the researcher has the option of allowing PT-SAFE to handle alarm annunciation (standard and experimental), thus nullifying the effects of the equipment lag.
DISCUSSION
Our results demonstrate the viability of a software tool for the purposes of designing medical audible alarms and annunciating them in a simulation environment. Technical feasibility and procedures were assessed with an HPS and an anesthesia patient monitor. The results indicate that PT-SAFE can be successfully integrated into an existing anesthesia monitoring setup with only a communication cable (e.g., RS-232) needed between the patient monitor and the host computer. Performance analysis on a mid-grade laptop computer showed functionality with up to 15 alarm modules being monitored simultaneously. A high-performance machine with more memory would be capable of handling more alarms, and so a host machine should be selected to accommodate the needs of the alarm designer. A lag was discovered between the monitor and PT-SAFE, and although the refresh rate of patient monitors likely varies from one manufacturer to the next, the data are sent in packets rather than in a stream of continuous information. Therefore, auditory displays that use continuous sonification would be limited by the rate at which the patient monitoring equipment exports discrete data packets. This limitation can be mitigated by coding the sonfication algorithm in question into a MATLAB module. PT-SAFE could then receive patient data as an input to the sonification algorithm. This would give the investigator independent control over onsets of the annunciation of limit alarms relative to the sonified auditory stream.
The limitations of current audible alarm standards include low alarm identification rates and poor urgency matching. Current alarms rely on tempo-based melodic sequences to convey meaning and urgency; however, recent research suggests that other auditory dimensions should be considered as well.17 PT-SAFE addresses this need by providing alarm modules that map vital sign information from patient monitors to novel alarm annunciators. In addition, PT-SAFE addresses the need for a standalone tool that can be used in multiple stages of development from design to testing. The IEC stipulates that all new alarm designs should be subjected to clinical or simulated clinical usability testing. Instead of relying on different technologies to annunciate alarms in laboratory, simulator, and clinical settings, in principle PT-SAFE can be used in each of these environments, thus allowing for rapid evaluation.
PT-SAFE provides flexibility in alarm design, producing a plethora of possible experimental setups for evaluation. Importantly, PT-SAFE was designed to facilitate comparative studies between multiple alarm designs. The XML data logger allows cases to be saved to disk, which can then be rerun at a future time for a recreation of the case. The save and load functionality allows for these experimental alarm designs to be reused at a future date. Another important feature of PT-SAFE is alarm modularity. Modularity in the context of software development implies that there is functionality in self-contained units that can stand-alone or work in conjunction with other alarm modules. This approach allows the alarm designer to construct, modify, or change the order of the alarm modules within a shorter development cycle time and perhaps even in real-time. Finally, PT-SAFE can load in externally generated MATLAB-compiled DLLs. These can be used to create custom annunciators or smart alarm algorithms, such as trend-based monitoring or centralized alarm management.
In summary, PT-SAFE has been shown in a simulated clinical environment to be a software tool that can be used to develop novel alarm annunciators, map vital signs to these annunciators to form audible alarm modules, and annunciate the alarms. With PT-SAFE, researchers may bring new audible alarm designs from the laboratory to the simulation environment. Alarms can be generated within PT-SAFE using internal tools, or they can be loaded from an external source such as wave-files, or smart alarms can be generated in MATLAB and imported as a DLL. PT-SAFE is well-suited for integration into existing AS/3 monitor setups, because its implementation requires no hardware modifications. Implementation of PT-SAFE with other monitoring systems could be readily obtained with modest programming expertise. Previous studies, in concurrence with policy initiatives of The Joint Commission and Anesthesia Patient Safety Foundation, have shown that current audible alarm strategies possess many deficiencies that limit their effectiveness. PT-SAFE can be used by a broad range of researchers to address these deficiencies by providing tools for the development of alarm annunciators, and the rapid staging into a simulator setting for the evaluation of novel alarm designs.
CONCLUSION
The results presented here suggest that this software tool provides a foundation for rapidly staging multiple audible alarm sets from the laboratory to a simulation environment for the purpose of evaluating novel alarm designs, thus producing valuable findings for medical audible alarm standardization.
DISCLOSURES
Name: Christopher L. Bennett, PhD.
Contribution: This author helped design the study, conduct the study, analyze the data, and write the manuscript.
Attestation: Christopher L. Bennett has seen the original study data, reviewed the analysis of the data, approved the final manuscript.
Name: Richard R. McNeer, MD, PhD.
Contribution: This author helped design the study, analyze the data, and write the manuscript.
Attestation: Richard R. McNeer has seen the original study data, reviewed the analysis of the data, and approved the final manuscript, and is the author responsible for archiving the study files.
This manuscript was handled by: Dwayne Westenskow, PhD.
ACKNOWLEDGMENTS
The authors wish to acknowledge the Department of Anesthesiology for funding Dr. Bennett's postdoctoral position and this research. David Birnbach is to be acknowledged for offering access to the METI HPS and for supplying Dr. Bennett with office space and secretarial resources at the Center for Patient Safety. We also thank Ilya Shekhter for sharing his technical expertise with matters concerning the simulation laboratory.
REFERENCES
1. Kohn LT, Corrigan J, Donaldson MS To Err Is Human: Building a Safer Health System. Washington, DC: National Academy Press, 2000
2. Sanderson PM, Watson MO, Russell WJ, Jenkins S, Liu D, Green N, Llewelyn K, Cole P, Shek V, Krupenia SS. Advanced auditory displays and head-mounted displays: advantages and disadvantages for monitoring by the distracted anesthesiologist. Anesth Analg 2008; 106: 1787–97
3. Seagull FJ, Sanderson PM. Anesthesia alarms in context: An observational study. Hum Factors 2001; 43: 66–78
4. Beatty P, Beatty S. Anaesthetists' intentions to violate safety guidelines. Anaesthesia 2004; 59: 528–40
5. Kestin I, Miller BR, Lockhart CH. Auditory alarms during anesthesia monitoring. Anesthesiology 1988; 69: 106–540
6. Block FE, Nuutinen L, Ballast B. Optimization of alarms: a study on alarm limits, alarm sounds, and false alarms, intended to reduce annoyance. J Clin Monit Comput 1999; 15: 75–83
7. Xiao Y, Mackenzie C, Jaberi M, Harper B. Alarms: Silenced, Ignored and Missed. Anesthesiology 1996; 85: 422
8. Meredith C, Edworthy J. Are there too many alarms in the intensive care unit? An overview of the problems. J Adv Nurs 1995; 21: 15–20
9. Watson M, Sanderson P, John Russell W. Tailoring reveals information requirements: the case of anaesthesia alarms. Interact Comput 2004; 16: 271–93
10. McNeer RR, Bohórquez J, Özdamar Ö, Varon AJ, Barach P. A new paradigm for the design of audible alarms that convey urgency information. J Clin Monit Comput 2007; 21: 353–63
11. Mondor TA, Finley GA. The perceived urgency of auditory warning alarms used in the hospital operating room is inappropriate. Can J Anaesth 2003; 50: 221–8
12. Williams S, Beatty PCW. Measuring the performance of audible alarms for anaesthesia. Physiol Meas 2005; 26: 571–81
13. Edworthy J, Loxley S, Dennis I. Improving auditory warning design: Relationship between warning sound parameters and perceived urgency. Hum Factors 1991; 33 (2): 205–31
14. Sanderson P, Wee A, Lacherez P. Learnability and discriminability of melodic medical equipment alarms. Anaesthesia 2006; 61: 142–7
15. Wee AN, Sanderson PM. Are melodic medical equipment alarms easily learned? Anesth Analg 2008; 106: 501–8
16. Block FE. Evaluation of users' abilities to recognize musical alarm tones. J Clin Monit Comput 1992; 8: 285–90
17. Edworthy J, Hellier E, Titchener K, Naweed A, Roels R. Heterogeneity in auditory alarm sets makes them easier to learn. Int J Ind Ergonomics 2011; 41: 136–46
18. IEC/ISO. Audible alarms in medical equipment. Geneva, Switzerland: International Electro-technical Commission 2006. Report No: 60601-1-8
19. Olympio M. APSF workshop recommends new standards. Anesthesia patient Safety Foundation Newsletter 2004; 19: 41,52–3
20. . Critical alarms and patient safety: ECRI's guide to developing effective alarm strategies and responding to JCAHO's alarm-safety goal. Health Devices 2002; 31: 397–417
21. Edworthy J, Hards R. Learning auditory warnings: The effects of sound type, verbal labelling and imagery on the identification of alarm sounds. Int J Ind Ergonomics 1999; 24: 603–18
22. Guo J, Araki K, Tanaka K, Sato J, Suzuki M, Takada A, Suzuki T, Nakashima Y, Yoshihara H. The latest MML (Medical Markup Language) version 2.3—XML-based standard for medical data exchange/storage. J Med Syst 2003; 27: 357–66
23. Loeb RG, Fitch W. A laboratory evaluation of an auditory display designed to enhance intraoperative monitoring. Anesth Analg 2002; 94: 362–8
24. Watson M, Sanderson P. Sonification supports eyes-free respiratory monitoring and task time-sharing. Hum Factors 2004; 46: 597–17
25. Anderson J, Sanderson P. Designing sonification for effective attentional control in complex work domains. Human Factors and Ergonomics Society Annual Meeting Proceedings, New Orleans, LA: Human Factors and Ergonomics Society 2004: 1818–22
26. Görges M, Markewitz BA, Westenskow DR. Improving alarm performance in the medical intensive care unit using delays and clinical context. Anesth Analg 2009; 108: 1546–52
27. Block FE. What is heart rate, anyway?. J Clin Monit Comput 1994; 10: 366–70
This appendix describes a “smart alarm”, or trend-based algorithm, using the notation of MATLAB. The function template uses four inputs and two outputs. The inputs correspond to the incoming audio buffer (normally 20 – 100 ms) represented by pAudioIn, the parametric effect strength represented by the scalar Fx, a general purpose user-defined block of memory, pUser, and a vital sign identifier, Id. The value of Fx is representative of the vital sign status, with values near zero indicating a normal state and values near one representing an off-normal state. The variable pUser is a pointer to a megabyte of memory held by PT-SAFE. This can be used to log previous states, hold additional values or variables, define a look-up table, or for any other desired purpose. The outputs are pAudioOut and pUserRet. The variable pAudioOut is the output audio buffer. In the case that no alarm is present, pAudioIn would simply be assigned to pAudioOut, however some modification would be applied during the assignment when an alarm is present. In the example below, a noise burst used as the annunciator for when the SpO2 drops below the threshold. The variable pUserRet is the block of memory that the user wishes to pass back to PT-SAFE for storage. This is the memory that will be passed back to the function as pUser the next time that it is called.
Appendix: Loading in a Compiled Matlab Function MATLAB code
function [pAudioOut, pUserRet] = PtsafeAlarm(pAudioIn, Fx, pUser, Id)
% pAudioOut: audio output buffer
% pUser: state machine with 1024 elements of doubles
% pAudioIn: input audio buffer
% Fx: value [0,1] of the effect strength knob
% Id: reference to the vital sign being monitored
% HR=1; SPO2=2; RR=3; SYSBP=4; DIABP=5; MNBP=6; TEMP=7; ST=8; ETCO2=9;
% FIO2=10; FIAA=11; PPEAK=12; PEEP=13; MVE=14; PCWP=15;
% shift previous states by 1 element
pUserRet = circshift(pUser,1);
% add newest effect strength value to the beginning
pUserRet (1) = Fx;
% if average over 327 frames [327(frames)*2560(samples per frame)/44100 (samples per second) = ∼19 sec] is within 10% of the current nominal value
if (mean(pUserRet(1:327)) > 0.9*Fx)
% then apply an alarm
pAudioOut = pAudioIn +rand(size(pAudioIn))-0.5;
else
% otherwise just pass-thru the input
pAudioOut = pAudioIn;
end
return;
This function was compiled to a DLL using the following command:
mcc -B csharedlib:ptsafelib PtsafeAlarm.m –C
Using the MATLAB run-time libraries, PT-SAFE reads in the DLL and annunciates alarms according to this user-defined function. This is but a simple example of trend-based monitoring, however there is a great potential for improved utility if the algorithm is developed with guidance from an expert alarm designer. For example, algorithms implementing information from multiple vital signs using the id variable could be developed to create special alarms that look for combinations of adverse events.
