1. 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

2. 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

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

4. 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)

5. 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

6. 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.

7. IHE PCD ACM PCD – IHE Domain Patient Care Device
IHE International – Integrating the Healthcare Enterprise
Web – 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

8. 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.

9. 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

10. 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)

11. 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

12. 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

13. 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.

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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 –

23. 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

24. 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

25. Q & A

26. Thank You

27. 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

28. 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

29. 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

30. 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)

31. 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)

32. 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

33. 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.

34. 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

35. 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

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