ABSTRACT
Alarms are essential for medical systems in order to ensure patient safety during deteriorating clinical situations and inevitable device malfunction. As medical devices are connected together to become interoperable, alarms become crucial part in making them high-assurance, in nature. Traditional alarm systems for interoperable medical devices have been patientcentric. In this paper, we introduce the need for an alarm system that focuses on the correct functionality of the interoperability architecture itself, along with several considerations and design challenges in enabling them.
ICE ALARM SYSTEM (IAS)
Fig. 1. Interoperability architecture of MD PnP ICE standard, with the addition of an alarm subsystem and related data flows.
Figure 1 is design sketch of ICE incorporating such an alarm subsystem, including data flow between the components. The IAS interfaces directly with the Supervisor and gets cues from it to raise alarms, especially those related to patient well-being. In addition, the Network Controller component mirrors all ICE traffic to the IAS. This additional information allows alarm system logic to detect problems with ICE itself without relying exclusively on other entities, which might themselves be faulty.
IAS DESIGN CHALLENGES
Most stand-alone medical devices currently come with their own alarms which are raised if the device malfunctions or reads patient data outside of pre-defined thresholds. How does one reconcile the patient alarms and functional alarms raised by the device with IAS-generated alarms? One could take two approaches in this regard. (1) Allow the devices to alarm independently, and use the ICE alarm only for problems with other components, e.g., the Supervisor, logger, Network Controller, and apps. (2) Subsume all the alarms of the medical devices, and raise all alarms in the ICE architecture centrally.
This will require the interoperability data communication standards to send alarm triggers from the devices to the ICE alarm system. While centralization has its benefits, e.g., prioritization and/or suppression of false alarms, it also comes with new problems, such as situations where the centralized alarm malfunctions or alarm information is lost. A better choice may be for the alarm subsystem to observe all the entities based on traffic mirroring by the Network Controller, and independently identify alarm triggers in ICE.
CONCLUSIONS
In this paper we introduced the need for a functional alarm system for improving the assurance for ICE-based interoperable medical devices. We categorized the alarms in various ways based on level of built-in intelligence (passive vs. active) and operational focus (functional vs. watchdog).
We then provided a list of challenges for designing the functional alarms for interoperability architectures, including reconciling multiple alarm data sources, tradeoffs between alarm subsystem intelligence and complexity, the need for watchdog alarms, and designing alarms that are flexible enough to deal with degraded functionality within ICE. Our on-going work concentrates on an IAS design that would address these challenges.
Source: University of Pennsylvania
Authors: Krishna Venkatasubramanian | Eugene Vasserman | Oleg Sokolsky | Insup Lee