PCD Profile ACM Proposal Detailed

IHE Profile Proposal (Detailed)

Proposed Profile: PCD ACM - Alarm Communication Management

Proposal Editor: Monroe Pattillo

Planning Committee: Susan Blyde, Yadin David, Tobey Clark, Bikram Day, Manny Furst, Jeff Heyman, John Leung, Monroe Pattillo, John Rhoads, Richard Roa, Ray Zambuto

Technical Committee: Susan Blyde, Bikram Day, Robert Flanders, Ken Fuchs, Joel Halle, Jeff Heyman, John Hotchkiss, Ken Marks, Mary Moewe, Monroe Pattillo, Paul Schluter

Interested Parties: Ted Cohen, Bill Hyman, Bruce Hyndman, Tom Judd, Nagesh Mallugari, Rautee Riina

Date (Initial): November 27, 2007 (kick-off TCon)

Date (Current): February 21, 2008 (update)

Version: 0.11

Domain: Patient Care Device

Summary

This profile defines the communication of alarms from alarm source systems to alarm management systems and from alarm management systems to alarm historical systems. This profile provides for alarm dissemination between alarm source devices and systems, from the connector to and within the communication services to the required abstract semantics, in a manner that, if complied with, enables multi-vendor multi-modality interoperation.

This profile relates to the following… Patient Care Devices (PCD) Domain

Technical Framework

Device Enterprise Communication (DEC) Profile Point-of-Care Real-Time Plug-and-Play Medical Device Integration Profile IT Infrastructure (ITI) Domain Patient Identifier Cross Referencing (PIX) Profile The Alarm Communication profile combined with the related profiles should provide, where practicable, a consistent way of uniquely identifying each alarm source, both the required and optional communicated information, and the patient with which it is associated. The identification of the source of the alarm communicated information and the identification of the associated patient are to be “globally unique” in that it must apply no matter where it is used in the world. Applications such as telemedicine, as well as global marketing and sales, necessitate this requirement.

Scope

The covering name of this profile and the scope of required, optional, and not covered areas of this profile accommodates the time period in which this profile was created for timely approval for demonstation in the IHE Interoperability Showcase at 2009 HIMSS. It also accommodates this time period by making use of exiting IHE profile defined communication and messaging as well as HL7 defined communication and messaging. Subsequent changes to related profiles, if any, may require revisions to one or more aspects of this profile.

In Scope

Within the scope of the profile there are required and optional components.

Required

This profile defines unsolicited communication of alarms from alarm source systems to alarm management systems and from alarm management systems to alarm historical systems. While Real-Time Location Services (RTLS) is considered out of scope, location identification via physical association means, Point of Care, Room, and Bed are utilized.

Optional

The profile also defines optional solicited alarm communication as well as optional alarm receipt communication. This profile also defines optional alarm communication to alarm historical management systems. Location information from an RTLS may optionally be included in the alarm. This information might serve to identify the location of the patient, the caregiver, or patient care devices.

Out of Scope

Aside from that which is directly affected by this profile, communication and functionality within alarm management systems and the communication protocols and messaging used between alarm management systems and alarm dissemination and alarm endpoint client systems is not within the scope of this profile. “Smart” alarming, or alarm correlation or reduction across alarm sources is outside the scope of this profile. Additionally query and reporting capabilities of the alarm historical and reporting system is outside the scope of this profile.

Actors Overview – Fig. 1

Actors

This profile consists of the following actors each of which is comprised of multiple functional units which are potential actors in more detailed profiles.

The Alarm Source (AS) actor sources the alarm to Alarm Management (AM).

The Alarm Management (AM) actor receives the alarm from the Alarm Source (AS), potentially analyzes the alarm, and dispatches the alarm to Alarm Communication (AC).

The Alarm Communication (AC) actor receives the alarm from Alarm Management (AM) and sends the alarm to the client application in the endpoint device.

Communication between these actors is covered in this profile. Communication between functional units within an actor is not covered in this profile.

Each actor is identified below. The identity can be explicitly provided in the alarm or can be inferred based upon connections to an adjoining actor.

The functional units comprising an actor may be provided by one or more vendors in one or more systems. Reducing the total number of systems is preferred, but is not required.

Data flow of individual use model messaging communication indicates the command response sequences and directions.

For this profile Alarm Query (AQ) is considered a standalone actor.

Alarm Source (AS)

This actor originates the alarm.

Actor should be IEC 60601-1-8 compliant.

A single source can produce multiple, possibly concurrent, alarms.

This profile specifies the required data and data types produced by this actor.

This profile specifies communication of the data produced by this actor.

This actor may optionally cancel an outstanding alarm condition.

This may optionally indicate cancellation of any related escalation.

An outstanding alarm condition may be optionally escalated via follow-on alarm.

This actor aggregates and adapts alarms from multiple sources as needed to make them interoperable with the the AM actor.

In large alarm source populations an aggregation system may be useful for concentration and possible alarm coordination (smart alarming).

Alarm Management (AM)

This actor receives alarms from the AS, manages them, and dispatches them to the AC actor.

This actor should be IEC 60601-1-8 compliant.

This profile specifies the required data and data types produced by this actor in communication to the AC actor.

If the following is performed, it is likely performed within the AM.

Alarm formating for dissemination

Alarm harmonization across multiple similar and dissimilar AS

Any additional alarm priority actioning following any performed by the AS

Alarm mapping to AC actor endpoints

Alarm dissemination escalation

Alarm dissemination sequencing to AC actor endpoints

Alarm dissemination escalation to AC actor endpoints

Patient to staff assignments

Staff to AC actor endpoint assignments

Alarm reporting

Alarm historian

To accomplish assignments the AM may receive HL7 ADT message feeds from one or more sourcing systems for the following purposes.

Identify patients

Assign resources to patients (staff, equipment, rooms)

This profile specifies the required data and data types produced by this actor.

This profile does not specify the protocol used in the communication of the data to the AC actor.

Alarm Communication (AC)

Th Alarm Communications (AC) actor receives alarms from the Alarm Management (AM) actor. Endpoint devices are connected either directly or indirectly to the Alarm Communications (AC) actor. The AC may utilize a locally controlled or public infrastructure.

Examples of locally controlled infrastrcutures

• One-way paging system (no ability to reply)

• Two-way paging system (varying abilities: read receipt, accept, cancel)

• Wired telephony communication (e.g. PBX) (e.g. text to speech/DTMF/IVR)

• Wireless telephony communication server (e.g. VoIP standard or proprietary)

• Local server based e-mail (SMTP-POP/IMAP)

• Local server based Instant Messaging (IM)

• Examples of public infrastructures

• One-way paging service (no ability to reply)

• Two-way paging service (varying abilities: read receipt, accept, cancel)

• Internet based e-mail (SMTP-POP/IMAP)

• Internet based Instant Messaging (IM)

• Internet based Multimedia Messaging (MMS)

• Wired telephony communication (PSTN) (text to speech/DTMF/IVR)

• Local wireless gateway to Internet for VoIP telephony

This profile specifies the required data and data types produced by this actor.

This profile does not specify the protocol used in the communication of the data to th AE actor.

This is the client application in the communication endpoint responsible for communicating the alarm to the final destination, be it a person or a system.

This profile specifies the required data and data types produced by the actor.

This profile does not specify the protocol used in the communication of the data to the final destination, be it a GUI or application interface.

This profile does not specify the presentation of the data.

Alarm Query (AQ)

This actor sends alarm queries to the AM actor and receives query responses from the AH actor. The AQ is considered a standalone actor.

This profile specifies communication with the AM actor.

This profile specifies the required data and data types communicated with the AM actor.

Interaction Models

An alarm is essentially a Device Observation Report (DOR) sent to an Alarm Management (AM) actor instead of or in addition to a Device Observation Consumer (DOC) actor. Refer to the Device Enterprise Communication profile for details on the DOR and the DOC actor.

The AM actor does not function as a DOC actor. It is merely a re-use of the DOR communication for alarm purposes.

Receipt of a DOR by an AM implies the DOR is being submitted for consideration as an alarm.

Based upon DOR content and/or configuration of the AM the DOR may or may not be processed as an alarm.

Patient Anonymous Alarms

The PID segment of a DOR submitted by the AS to the AM is considered optional in some interactions.

An example is a nurse call system which provides only room/location information to the AM. In such cases the PV1 segment is considered mandatory to identify alarm location. This is recognized as not in concert with current requirements of the Joint Commission. It is an adaptation in support of existing environments.

Another example is when a patient care device is connected to a patient and begins sending alarms to the AM prior to being configured with patient identification information. In such cases the alarm source equipment identification is the alarm source identification.

In all other cases a PID segment is considered mandatory for patient identification and should be used without regard to the presence or absence of a PV1 segment.

Equipment location can be determined from the PV1 segment if the equipment is fixed to a location, such as with current nurse call systems, or if the equipment is integrated with location identifying equipment.

If the equipment is not fixed in location and is not integrated with location identifying equipment the location of the alarm source can not be determined directly but may be correlated by the AM using alarm source equipment identification.

Unsolicited Alarms

This is the minimally required interaction model. Alarms are sourced at the AS actor and are delivered to the AM actor in an unsolicited manner. The alarm then travels from the AM actor to the AC actor for delivery to endpoint. The delivery manner, unsolicited or solicited, is defined by the operating environment and not by this profile.

Prior configuration of all involved actors is a means for allowing alarms to arrive and be processed in an unsolicited manner.

Mapping of alarm source to AC actor endpoints may be provided in the alarm or may be assigned during the passage of the alarm through the AM actor to the AC actor.

Alarm data

Alarm instance identification

Alarm source identification

Alarm latch state (latched or unlatched)

Alarm timestamp

Alarm type

physiological

technical

equipment maintenance

demonstration

Alarm priority (high, medium, low, informative)

Alarm text

Alarm recipients (optional)

Recipients indicated by any of…

Recipient name(s)

Individuals or groups

Communication endpoint identification(s)

Carrier and device identifier

Alarm delivery confirmation (optional)

Response to AS

Accept (not specified, correct)

Reject (not specified, nuisance but correct, false positive)

Via AC actions

Deliverable, had a mapped destination

Queued to communications

Accepted by communications

Delivered to endpoint

Read at endpoint

Accepted by endpoint

Rejected by endpoint

Canceled by endpoint

Canceled by other than endpoint

Callback start at endpoint

Callback end at endpoint

Solicited Alarms

This use case is optional in this profile.

This delivery method requires the AS actor to request the ability to deliver alarms to the AM actor and for the AM actor to request the ability to deliver alarms to the AC actor.

Alarm Query

The AQ actor posts queries to the AM actor and receives responses from the AM actor. The queries may includes one or more filters.

Filter keys

• Alarm origination date range

• Patient by name and ID

• Assigned Patient Location (PV1-3) components

• Alarm response time by start to status point

Reports

• Alarms by date

• Alarms by patient by name and ID

• Alarms by Assigneed Patient Location (PV1-3) components

• Alarms by type

• Alarms by source

• Alarms by interface

Alarm Communication

• Alarm Source Parameters

• Priority

Examples

• Alarm to one-way pager device

• Alarm to two-way communication device

• Alarm to two-way with callback

Use Cases

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.

Use Case 1 (location sourced): Patient Assigned to Room, Nurse Call Alarm (AS), Alarm to Alarm Mgmt System (AM), Alarm to Communication Endpoint (AC)

Use Case 2 (identified patient source): PCD Assigned to Patient, Patient Monitoring Alarm Occurs (AS), Sends Alarm to Alarm Mgmt System (AM), Alarm to Communication Endpoint (AC)

Use Case 3: (same as use case 1 or 2 with escalation with cancel at source) if the communication destination is inaccessible or the target individual is indicated as unavailable then the alarm is rerouted to one or more alternatives with escalation to higher levels of responsibility until the alarm is canceled at its source and the alarm system notified of the cancel.

Use Case 4: (same as use case 1 or 2 with escalation with cancel at communication endpoint) if the communication destination is inaccessible or the target individual is indicated as unavailable then the alarm is rerouted to one or more alternatives with escalation to higher levels of responsibility until the alarm is canceled by a recipient at a communication endpoint.

Use Case 5: (same as use case 1 or 2 with escalation with cancel at alarm mgmt system) if the communication destination is inaccessible or the target individual is indicated as unavailable then the alarm is rerouted to one or more alternatives with escalation to higher levels of responsibility until the alarm is canceled by a user on the alarm management system, however not automatically via algorithms in the alarm management system.

Standards

1. HL7 version 2.5
2. IEC 60601-1-8 Alarm Management
3. ISO/IEEE 11073-10201 Domain Information Model
4. ISO/IEEE 11073-10101 Nomenclature
5. ISO/IEEE 11073-20101 Application Profile – Base Standard
6. CEN env13735 (and in process equivalents – 11073-202xx)
7. ISO/IEEE 11073-30200 Transport Profile – Cable Connected
8. ISO/IEEE 11073-30300 Transport Profile – Infrared (incl. TCP/IP & UDP/IP Access Point specification)

References

1. ACCE Healthcare Technology Foundation “Impact of Clinical Alarms on Patient Safety” [1]
2. ECRI Institute “The Hazards of Alarm Overload” [2]

Technical Approach

Refer to IHE PCD Technical Framework for a detailed description.

See Also

PCD Home | PCD Recent Meetings Page | PCD Meeting Archive