Some quick thoughts on medical device alarm research areas of need
2.02.2012 | Blog, Clinical Informatics, Engineering, Healthcare IT, Medical Device Alarms, Medical Device Connectivity, Portfolio, Regulatory, Systems, Technology, Workflow / Medical Devices
Months ago I wrote about the AAMI Summit on Clinical Alarms. This prompts some ideas for research to mitigate nuisance and general patient medical device alarm problems:
- improving signal to noise (specifically, sensitivity / specificity): reducing data overload / information underload would limit “nuisance” alarms;
- need for device intelligence: for example, the medical device alarm has context for which awareness and the ability to adapt to a specific situation would reduce the occurrence of artifact;
- human-machine interfaces: improved usability through refined/redesigned human / machine sensory interface;
- multisource data fusion: integration of data from multiple devices in a manner that provides for a fusion of knowledge and situational awareness that would not be available from these devices separately; and,
- historic and prospective trending: deterioration trending of patients over time using historic data as well as models of prospective evolution.
Historic information provides some notion of what is risky for patient: events and information from multiple sources can establish an a prior assessment of whether a patient is experiencing distress. These conditions are not unique and have been seen previously by multiple clinicians over time. Hence, the historical information can be a great filter for establishing what is real and what is not real in terms of alarms and medical device alarm management. Just as automatic feedback control systems provide a feedback to the plant model as to deviations from expected performance, such is analogous with medical device alarms.
Part of the challenge is how to combine the information from multiple sources. This combination of information is not simply co-displaying them in a common format or user interface. It is presenting the data intelligently to the end user, possibly in a processed manner that determines, based on their combination, whether the result is a bona fide alarm condition. This rather cerebral aspect of the processing is the dilemma. Leaving out even the regulatory aspects of the situation, understanding what the processing is actually doing–the “plant” part of the automatic feedback control system–must be represented accurately.
A medical device alarm from a single device provides an indicator with respect to the sensors that are being measured for that one device. For instance, a physiologic monitor that is only measuring pulse and ECG cannot report an alarm on End Tidal CO2 or respiratory rate. On the other hand, a mechanical ventilator cannot report an alarm on heart rate or on ST segment elevation. The two devices report medical device alarms according to their particular sensors and objectives. However, the combination of the two devices can provide corroborating evidence. For instance, an ASYS alarm could be caused bya lead disconnecting from the physiologic monitor or from the patient. But, an ASYS alarm occurring at the same time as an APNEA alarm would provide corroborating evidence. This is rather a tragic example, but one that demonstrates the correlation of two events.
The fusion of multi-source devices can also provide a mechanism for reducing data overload while at the same time increasing useful information is one that I find to be very interesting. There are many research efforts surrounding modeling. Yet, integrated system modeling (multi system integrated assessments) has really yet to be shown (publicly) as viable in medicine–and generally accepted in operational use, not to mention for medical device alarms.
I would like to leave this here for now and follow-up in more detail on these areas. The medical device alarm field is fertile ground for integrated systems engineering application.