Page tree
Skip to end of metadata
Go to start of metadata

Clinicians and their patients are often bombarded with alert sounds emanating from a variety of medical devices including infusion pumps, ventilators, nurse call systems, cardiac monitors and other associated central monitoring systems. When these conditions occur, alarm fatigue is frequently the result, which has been shown to lead to patient frustration,  staff burnout and increased potential for medical errors.   

There have been individual technology offerings for a few years now helping to solve this problem, but deeper review of the problem shows that in order to truly address this important issue, multiple vendors must work together. Proprietary technologies can solve the problem in niche scenarios only, which can drive confusion among healthcare providers as to what features can be supported with the technologies they deploy. Recognizing this problem, the IHE Devices/PCD program created the “Quiet Hospital” initiative to bring together multiple device and software manufacturers to focus in this area. The primary goal is to solve this problem through easily implemented, vendor-neutral interoperability standards. 

The Quiet Hospital (QH) is an ongoing effort by these IHE members that focuses on audible alarms, the impacts they have and how technologies might be implemented to drive greater efficiency.  This effort includes leveraging SDPi profiles for “Alarm/Alert Delegation”, which allows one medical device to act as an alarm proxy for other medical devices and sensors. The initiative also takes advantage of the mature and broadly adopted HL7 v2 based PCD-ACM profile for alert delivery and audio pause based on real-time clinician responses.


Problem Statement:  Alert Fatigue

User Narrative: Typical Hospital (current situation)

Kelly, is a severely ill patient in University Hospital’s high acuity intensive care unit.  He is connected to a patient monitor, a variety of infusion devices and a ventilator.  Though his patient monitor is connected to a central station, which stops many of his alerts from sounding in his room, he can hear all the alerts sounded at the central station as well as alerts from his other devices and from devices in neighboring rooms.  This continuous high “noise” level increases his overall level of stress as well as interrupts his rest and healing.  In some cases, these noises can contribute to a deterioration of the patient’s mental state resulting in delirium.  These noises can also impact the clinical staff, such as Kelly’s nurse Sam, who are bombarded with alarm sounds, not only for the patients they are responsible for, but for other patients in the ICU.

<value proposition content>

<see John Rhoads slide deck>

What Lays Below ...

What is an "alert" anyway?

<add a brief discussion about alerts & events ... and alarms ... and SES RCM ...>

<include white paper content + diagrams from / related to the ACM profile>


Quiet Hospital / Silent Hospital

In the Quiet Hospital effort there are two modes of operation that have been defined including "Quiet" and "Silent" with a slight variance in the narrative for each.  These modes of operation are dependent upon multiple factors including but not limited to the following.

  • Healthcare organizational adoption of remote alarms as a safe practice
  • Care area solutions are being deployed in 
  • Level of adoption and conformance for all device and software solutions positioned in care areas where this mode would be enabled

The attached presentation provides specifics on the qualifying factors for each mode and the differences in practice for each.

User Narrative:  Quiet Hospital

Background

“Quiet Hospital” mode routes alert notifications from the patient care devices associated with a patient directly to the responsible nurse’s mobile communication device with the proper information for each event. In this mode, for non-life critical events (as determined by the clinical staff) the nurse can use the mobile device to temporarily pause the bedside alarm audio for a few minutes, allowing the caregiver time to go to the bedside to resolve it.  With quiet hospital engaged life critical events continue to generate alarm sounds at the bedside and central station (depending on how the ICU is configured).

Narrative

Early during Kelly’s stay in the ICU, the ICU staff decide to deploy a “Quiet Hospital” mode.   All of Kelly’s alerts (as well as from her other patients) are forwarded to Sam however she can now triage and acknowledge lower priority alerts from her mobile device, allowing her to prioritize more critical tasks with other patients and without forcing Kelly to listen to the constant noise from these events in his room or his vicinity.  Sam can also focus on just the notifications from her patients since they are now coming to devices carried by Sam and others specifically assigned to their care. The sound in Kelly’s room and surrounding environment has now been diminished with only critical alarms or alerts that have “timed out” sounding from the devices assigned for his care.  Sam has lower fatigue with higher patient satisfaction for her patients since she can better attend to their needs.

User Narrative:  Silent Hospital

Background

“Silent Hospital” mode also routes alert notifications from the patient care devices associated with a patient directly to the responsible nurse’s mobile communication device with the proper information for each event. In this mode, the nurse can use the mobile device to completely manage any alert so that there will be no alert sounds at the bedside (or central station).  In addition, the nurse can also adjust alarm limits and other device settings using the mobile device (depending on how the ICU is configured).

Narrative

Given the success with the “Quiet Hospital” mode the staff decide to go one step further and enable “Silent Hospital” mode.  The impact on Kelly is still meaningful since while Sam and other responsible caregivers were quite diligent about getting to the bedside to reset alerts at the device the occasional alarm sound was still annoying to him.  The impact on Sam is more profound since she is less distracted and can stay at a patient’s bedside and manage Kelly’s devices as needed if in the middle of taking care of another patient.  In this case she decides to adjust the heart rate alarm limits since Kelly is getting better and is moving around a little more creating the occasional false alarm.

From Quiet Hospital to Silent Hospital

<Add Paolo's / Rob's presentation slides here ... Use current then update w/ "IHE-ized" version >


Use Case Analyses 

<from above to Gherkin / Cucumber & ReqIF ...> scenarios

<include links to use case pages>

<include link to QH: Systems Network Scenarios - initial home of alternative for the QH/SH narrative>


Alerting using SDC-SDPi+FHIR Technologies

Technical Overview

The Quiet Hospital (QH) and  Silent Hospital (SH) alerting modes assume that alert information can be sent to a caregiver mobile device and introduce the concept of “Alarm/Alert Delegation” which allows one medical device (usually Software as a Medical Device (SaMD)) to act as an alarm proxy for other medical devices/sensors. For example, an SpO2 monitor, blood pressure monitor or infusion device on an SDC network can delegate its alarm signaling to a local patient monitor (on the same network). In turn, a ventilator and the patient monitor can delegate their alarm signaling to a central station.

The central station (acting as a PCD AR or via an independent SDC device gateway acting as an AR) can, in turn, delegate the function of alert signaling to an alert communications manager which sends alert notifications directly to a Central Station and/or nurse mobile device. The app on the nurse mobile device supports temporary alert acknowledgement (Quiet Hospital) back to the central station or end-device using a combination of IHE ACM and IEEE SDC messaging.  More advanced implementations (Silent Hospital) support permanent alert acknowledgement and remote device control (alarm limit setting, device settings, etc.) as per ICU protocol.

Given the possibility of communication errors or system failures which could affect patient safety, appropriate feedback loops must be in place to mitigate any hazards that may result in dropped Alerts or other malfunctions.

Finally, in order to support longer term alert logging and analysis of alert patterns a separate SDC to FHIR gateway can be installed to capture the alert traffic and “serve” results to interested applications.


<link to the specs section>

<Include sequence diagrams using Plant UML from David G. & Team>

Roadmap & Team Collaboration

<intro plan for QH development in SDPi+FHIR + capture / link to JIRA / Topics / Web meeting notes etc.>

QH Roadmap (2020-2021)

<add high-level milestones and schedule for moving this work from concept to profile specifications to CAT to showcase to product certification>

<include correlation w/ SDPi & FHIR profile specifications ... e.g., SDPi-Alerting>

<include IHE SDPi publication ... EU / NA CAT ... HIMSS21 Showcase ... etc.>

<strart with either white paper OR 2020 mindmap or ...>


QH Team Participants

The following individuals have requested to be included in the Quiet Hospital Team:

NOTE:  Must be a registered HL7 Confluence user to be added to the table above.

QH Team Discussion Notes

General weekly web meeting discussion notes are captured on the SDPi+FHIR Meeting Logs & Notes page, along with QH/SH related tasks.


QH Parking Lot

The QH Parking Lot page captures various discussion topics that though important were beyond the capacity or expertise of the team to address presently.