Alarm Communication Management IHE PCD ACM Alarm Communication Management Monroe Pattillo Product Manager, Philips Emergin Lead Author, IHE PCD ACM WG Emanuel Furst, PhD, CCE President, Improvement Technologies, LLC Technical Project Manager, IHE Patient Care Devices Domain

Contents What is Alarm Communication Management? Why Alarm Communication Management? Why IHE PCD? IHE PCD ACM My IHE PCD History IHE PCD ACM Status ACM Supplement ACM Trial Implementation Version ACM Statement ACM Use Cases IHE PCD ACM Actors What Actor Does What Use Case Discussion IHE Recruiting Q&A

What is Alarm Communication Management? In the broad sense: Facilitating the communication of alarm information Source of alarm Type of alarm Severity Escalation Documentation

Why Alarm Communication Management? For Patients Improve care Receive appropriate response Improve satisfaction, healing For Clinicians Respond appropriately Increase efficiency, decrease frustration Improve patient care, safety Reduce false alarms (ref. Y. David)

Why Alarm Communication Management? For Facilities Improve patient care, safety, satisfaction Improve efficiency, effectiveness, clinician morale Facilitate adoption of new technologies For manufacturers Increase acceptance, market Reduce design and implementation costs

Why IHE PCD? IHE provides the ability to design, implement and install interoperable systems PCD is devoted to interoperable patient care devices (e.g., monitors, pumps) Alarm communication is one of a small number of functions that really make a difference to clinicians and therefore, are a high priority.

IHE PCD ACM PCD – IHE Domain Patient Care Device IHE International – Integrating the Healthcare Enterprise Web – www.ihe.net Wiki – wiki.ihe.net FTP – ftp.ihe.net PCD – IHE Domain Patient Care Device wiki.ihe.net/index.php?title=Patient_Care_Devices DEC – IHE PCD Profile Device Enterprise Communication wiki.ihe.net/index.php?title=PCD_Profile_DEC_Overview ACM – IHE PCD Profile Alarm Communication Management wiki.ihe.net/index.php?title=PCD_Profile_Alarm_Communication_Management

My IHE PCD History Last year I attended AAMI in Boston and in particular an IHE panel discussion. I was working for a vendor with a presence in alarm management for healthcare. There seemed to be interest in creating an alarm related profile. I thought I would participate. A year later I’ve been the lead author for the ACM Profile Brief and the ACM Detailed Profile and am now working on the ACM Supplement to the Technical Framework. Nobody has enough time to provide all they’d like to, but what is provided is valued and assistance in getting up to speed or in creating uniform documents, and Wiki content, is available. I’m looking forward to the effort and camaraderie of my first Connectathon and Showcase. IHE needs motivated and communicative individuals as profile drivers.

IHE PCD ACM Status Stages for IHE PCD ACM Profile Brief  Detailed  Supplement (out for public review) Updated Technical Framework (working on it) A Brief Profile Proposal Presents a case for developing the technical documents Includes “use cases” which illustrate the application and benefits Attracts the interest of users who help determine needs, priorities, business case Attracts the interest of vendors who contribute to the definition and, if successful, implementation and demonstration

IHE PCD ACM Status Stages for IHE PCD ACM Profile Brief  Detailed  Supplement Updated Technical Framework A Detailed Profile Proposal Follows approval of the Planning Committee Provides more detail, is the product of more people and companies, and hopefully more users Attracts the interest of vendors who begin to think about the practical issues Is presented to the Technical Committee to consider feasibility, availability of existing standards (may request extensions of standards for future effort)

ACM Supplement Supplement This is the first technical document. It was developed by a Working Group that included some members of this committee The Supplement, approved by IHE PCD, will be out for public review. Comments will be addressed by the WG and the Technical Committee The resulting document will be issued as the Trial Implementation version

ACM Trial Implementation Version Vendors voluntarily “sign on” to implementing this version Vendors test their prototypes by sending/receiving communications from three unrelated vendors. Successful vendors can claim success and go on to demonstrate their systems in Showcases such as the Interoperability Showcase at HIMSS

ACM Statement Alarm Communication Management is meant to improve clinical efficiency by using technology to deliver the right alarms, with the right priority, to the right individuals via devices with the right content, escalating under configuration communication to other individuals via devices.

ACM Use Cases A Use Case illustrates needs through examples, providing realistic opportunities to improve data communication Use Cases provide an opportunity to define multiple applications of the same concepts Use Cases identify the “Actors” needed to make the process a reality

Wi-Fi Phone or Badge, etc.) IHE PCD ACM Actors PCD Inputs (PM, NC, Resp, Pump, etc.) Output Devices (Marquee Sign, Pager, Wi-Fi Phone or Badge, etc.) Alarm Reporter (AR) Alarm Management (AM) Alarm Communication (AC) Alarm Source Alarm Aggregator Alarm Receiver Alarm Coordinator Alarm Disseminator Alarm Communication Alarm Endpoint Alarm Reporter . . Alarm Cache Optional Alarm Query (AQ) Communication detailed in ACM profile HIS, EMR Communication not detailed in ACM profile

Use Case 1 (Nurse Call) ACM Use Cases Patient assigned to room, alarm to Alarm Mgmt System, alarm sent to Communication Endpoint. Improves patient satisfaction by communication of patient requests to assigned caregiver without delay to patient

Use Case 2 (Patient Monitoring) ACM Use Cases Use Case 2 (Patient Monitoring) Device assigned to patient, sends alarm to Alarm Mgmt System, sent to alarm to Communication Endpoint Improves patient safety by notifying assigned caregiver of patient monitoring events even when not within audible or visual range of alarm source 17

ACM Use Cases Escalation provides a safety mechanism should the notification destination be unavailable, occupied, or communications to them not be successful Once it has been accepted or handled the alarm must be cancelled to end escalation The remaining uses cases deal with escalation and cancellation of escalation

ACM Use Cases Use Case 3 Use Case 4 Same as use case 1 or 2 with escalation and with cancel at source Use Case 4 Same as use case 1 or 2 with escalation and with cancel at communication endpoint Use Case 5 Same as use case 1 or 2 with escalation and with cancel at Alarm Management System 19

Wi-Fi Phone or Badge, etc.) IHE PCD ACM Actors PCD Inputs (PM, NC, Resp, Pump, etc.) Output Devices (Marquee Sign, Pager, Wi-Fi Phone or Badge, etc.) Alarm Reporter (AR) Alarm Management (AM) Alarm Communication (AC) Alarm Source Alarm Aggregator Alarm Receiver Alarm Coordinator Alarm Disseminator Alarm Communication Alarm Endpoint Alarm Reporter . . Alarm Cache Optional Alarm Query (AQ) Communication detailed in ACM profile HIS, EMR Communication not detailed in ACM profile

What Actor Does What AR – knows originating alarm, ultimately responsible for clearing it, knows how to get the alarm to the AM AM – a giant offloading engine, dumb or intelligent, dispatching, escalation, filtering, assignments, content harmonization, knows how to communicate with multiple, potentially proprietary, AC actors, may know end device distinctions, may gather RTLS samples at alarm time AC – data communication gateway to the endpoint device, understands how to communicate to end devices across things like Wi-Fi and WANs, knows device specific characteristics, and concepts like presence, read, read receipt, accept, cancel, etc. and how to communicate those back to the AM, might also know how to bridge to telephony and web based systems for things like callbacks and hyperlinks AQ – standalone optional subscriber and query source for gathering ad-hoc or long term information

Use Case Discussion Let’s try to come up with a few more use cases 1 – Location Sourced (nurse call) 2 – Identified Patient Sourced (PMD, maybe RAD, LIS, etc.) 3 – Same as 1 or 2 with escalation, Cancel at AR Source 4 – Same as 1 or 2 with escalation, Cancel at AC Endpoint 5 – Same as 1 or 2 with escalation, Cancel at AC by operator 6 – 7 –

Select a use case – what are your thoughts about this use case? Use Case Discussion Select a use case – what are your thoughts about this use case? How would this improve patient care and/or hospital financials? If time permits – select another use case

IHE Recruiting The IHE PCD ACM effort, the IHE PCD Domain, and other IHE Domains, are looking for… Users with a desire to improve interoperability To provide a user perspective To assist in creating additional profiles Vendors that strive for interoperability To conform to or add to the Technical Framework To participate as actors in Connectathons To demonstrate products/prototypes in Showcases

Q & A

Thank You

IHE PCD ACM Enumerations Alarm data can provide dispatching assistance information through the use of enumerated values Priority – Low, Med, High, Critical Status – Test Alarm or Not

Alarm Information An alarm is essentially a Device Observation Report (DOR) sent to Alarm Management (AM) instead of, or in addition to, a Device Observation Consumer (DOC) Patient and location in an alarm may not be identified Small images in the form of image data points (for waveforms) Alarms are typically unsolicited Escalation may be indicated Callback – application pertinent telephony connection or hyperlink Output devices are often one-way devices, like pagers and LED signs Two-way output devices offer the potential for accept/reject/cancel

IHE PCD ACM Flows Inputs Outputs Historical Capture and Reporting Report Alarm [ACM-01] ® Disseminate Alarm [ACM-03] ® Inputs ¬ Alarm Status [ACM-02] ¬ Dissemination Status [ACM-04] Outputs Alarm Reporter (AR) Alarm Management (AM) Alarm Communication (AC) ¬ Subscribe to Alarm [ACM-05] Subscribe to Alarm Cache [ACM-06] ­ ¯ Report Alarm [ACM-01] Query for Alarm [ACM-07] ­ Optional Alarm Query (AQ) Historical Capture and Reporting

IHE PCD ACM Messages Required Messages HL7 2.5 Standards Based Messaging (AR – AM and AM – AQ) ACM-01 Report Alarm – ORU^R01 (AM receives alarm from AR) Contains one OBR per alarm and multiple OBX segments per alarm Use multi-level “dot-notation” to identify alarm detailed properties Partially Open Definition Messaging (AM – AC) Required and Optional Data Items Are Specified, Protocol and Presentation Are Not Specified (likely proprietary) ACM-03 Disseminate Alarm (AM sends alarm to AC) ACM-04 Dissemination Status (AM receives status from AC)

IHE PCD ACM Messages Optional Messages HL7 2.5 Standards Based Messaging ACM-02 Alarm Status – ORU^R01 (AM publishes alarm status) Sent by AM to AR in response to ACM-05 from AR Sent by AM to AQ in response to ACM-06 or ACM-07 from AQ ACM-05 Subscribe to Alarm – QSB^Z02 (AM sends to AR) ACM-06 Subscribe to Alarm Cache – QSB^Z03 (AQ sends to AM) ACM-07 Query for Alarm – QVR^Z04 (AQ sends to AM)

IHE PCD ACM Messages Alarm instance sent messages, whether initial, in response to a subscription, in response to a query, or subscribed status updates all utilize the ACM-01 message Status updated alarms utilize the same alarm ID as the original alarm Query response or published alarms key to the ID from the query or subscription request

IHE PCD ACM Evidentiary Data (e.g. Waveforms) Optional delivery of evidentiary data via OBX using array in OBX-5 The Alarm Reporter (AR) does not know the capabilities of all possible endpoint communication devices connected through the Alarm Management (AM) actor beyond the Alarm Communication (AC) actor. Of the possible endpoint communication devices the AR will not know which devices are to be used for any specific alarm type or alarm instance as the communication endpoint dispatching is resolved dynamically within the AM using its current information regarding users, devices, assignments, and current escalation status. Therefore it makes sense for the AR provide to the AM the data elements (and in the future annotations) and let the AM generate as needed waveform images per messaging communication endpoint use.

IHE External Pieces IHE Test Tools - use of some is required for Connectathon participation Messaging Workbench (HL7 message schema and generation) KUDU required for managing test results MESA test tools required for producing results NIST used for schema generation and documentation Gazelle for documenting and managing results Information for Connectathon participants www.ihe.net/Connectathon/ihena2008_connectathon_participants.cfm

When It’s Required IHE North America 2009 Connectathon IHE PCD ACM Profile Supplement goes to full IHE May-July, 2008 IHE 2009 Connectathon Registration ends September, 2008 Beta release of IHE PCD ACM conformant AM vendor offering for vendor internal IHE Connectathon testing Controlled release of IHE PCD ACM conformant AM vendor offering for IHE Virtual Connectathon remote testing November, 2008 GA release of IHE PCD ACM conformant AM vendor offering for on-site IHE Connectathon live testing December, 2008 IHE North America 2009 Connectathon January 2009 GA release of IHE PCD ACM conformant AM vendor offering for on-site HIMSS 2009 Showcase presentation February, 2009 HIMSS 2009 IHE Showcase April 4, 2009

HIMSS Showcase The Showcase is an opportunity for an active demonstration to the community of accomplished system interoperability Solutions shown are considered deployable