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.
Alarms vs. Alerts
An alarm is a calculated indication of a condition that needs attention. An alert tells people or other systems something is wrong and raises awareness of a condition. Alarms can come from many different originating sources in the healthcare environment and almost any system in the clinical environment can generate an alert based on those alarms. Alarms derived from medical devices often communicate an immediate life-threatening patient condition that must be addressed in a timely manner. To provide awareness of these conditions, systems are capable of creating alerts that assist in the direction of patient needs to responsible individuals caring for the patient. For example, a clinician’s mobile device that receives alerts or can process text messages can also present alerts created from patient alarms via audio-visual indicators that let them know when a new message has arrived along with the criticality of what is happening.
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.
Use Case Presentation
Some participating organizations have worked in partnership with the IHE and HIMSS to produce the video linked below. This presentation is intended to show how standards based methods and technologies can address the problems of noise and fatigue more completely. In this case, Josephine (Jo) is in the ICU due to extensive injuries from a motorcycle accident. ICU clinicians recognize that motorcycle trauma is both physical and psychological. Treatment for Jo’s physical injuries and mental state require the support of her husband and daughter. By keeping the medical devices in her room quiet, Jo can rest peacefully, and her family can focus on her without wondering why nurses only respond quickly to certain alarms. This demonstration shows distribution of alarms based on the Quiet ICU model, allowing clinicians to respond to critical alerts while quietly tracking noncritical alarms. By eliminating the stressors from these alerts, Jo can heal and begin her journey back home.
HIMSS Digital Interoperability Experience Video Presentation: Trauma Recovery in the Quiet ICU
HIMSS has links to other helpful information on this use case including a long description and resource contacts for the members of this effort that took part in the creation of the video.
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.
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:
| David Gregorczyk | John Rhoads | Paul Schluter | Javier Espina | ||||
| Jeff Rinda | Brian Witkowski | Priyanka Shah | Tom Kowalczyk | Koi Matsumoto | Al Engelbert |
NOTE: Must be a registered HL7 Confluence user to be added to the table above.
QH Team Discussion Notes
Note: Some QH meeting notes from 2020 are captured on the SDPi+FHIR Meeting Logs & Notes page, along with QH/SH related tasks.
Agenda
ACM CP work
Connectathon / Showcase QH focused updates
Participants
Discussion Notes
draft CP to ACM (PCD TF)
will allow the AR to optionally filter which PCD-05 messages would be sent by the AM to the AR on a per PCD-04 basis.
The nomenclature for the OBX instance would need to be reviewed and approved. We did first review last week in the ACM WG and we will be doing some of that in the ACM WG meeting later this week.
It was discussed that since ACM is at final text status (in PCD TF) processing of the indication in a PCD-04 by the AM actor is optional for those participating in the connectathon. This means AR actor implementations would need to continue to filter out what they don’t want to receive in most cases until greater adoption of these updates are achieved.
We also discussed that in the future, there could be agreement for this capability to be made required for AM actors and optional for AR actors.
It was discussed that we will continue review of this proposed CP during the Tuesday 9AM ET Quiet Hospital WG session on 12/17. After that, it will be sent up for PCD co-chair review and balloting. Given the holiday schedule the balloting may not occur until early in 2021.
Connectathon/Showcase registration (QH use cases)
Connectathon registration continues to be low. At the time of this meeting only 3 vendors had signed up for PCD testing and 10 vendors overall had signed up for connectathon. This is something to keep an eye on as it could make full testing of QH uses cases difficult.
Calendar updates
The Quiet Hospital working group will be cancelling the next two weekly sessions due to the holidays. the next planned meeting will be on 1/5/2021.
Action Items / Tasks
- Rob Wilder Monitor QH vendor registrations for connectathon and showcase
- Rob Wilder Confirm submission of ACM CP for balloting and assigned number
Agenda
Review any QH related change proposals
Connectathon / Showcase QH focused updates (Use cases with Quiet Hospital capabilities)
Participants
QH related change proposals
There are no currently active or identified CPs for QH scenarios and existing CPs have all now been approved.
Connectathon/Showcase registration (QH use cases)
With Connectathon registration final there are 16 vendors testing PCD profiles with 3 AM actors and 3 AC actors which is enough to qualify updates provided they have implemented the passed CPs approved in 2020.
At the Showcase there is a single dedicated QH use case with other use cases that have alerting scenarios that can fit QH components to a lesser degree.
Calendar updates:
The Quiet Hospital working group has shifted to a bi-weekly model starting on 2/1/2021
This meeting will remain on a bi-weekly schedule until after the Connectathon and at that time we will re-asses the meeting calendar based on testing results.
Actions/Tasks:
- Rob Wilder Check with registered AM actors at Connectathon to determine readiness to test recent CP changes at Connectathon in March.
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.
1 Comment
Paolo Burchietti
In my opinion in the problem statement section we should add a section for:
This is an important aspect of the Silent Room