Difference between revisions of "PCD Profile Alarm Communication Management Overview"
Jump to navigation
Jump to search
m (start) |
|||
| (35 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | '''Alert Communication Management (ACM)''' allows a patient care device or system to send a notification of an alert to a person on their communication device, anything from one-way pagers, to PBX phones, to Wi-Fi devices, to mobile phones. ACM was previously known as Alarm Communication Management and was changed to Alert Communication Management to broaden the scope beyond medical device physiologic and technical alarms to include advisories, such as workflow events and notifications. | |
| − | '' | ||
__TOC__ | __TOC__ | ||
==Summary== | ==Summary== | ||
| − | |||
| + | The Alert Communication Management profile defines an HL7 V2 message for communicating detailed information about an alert (alarm - physiological or technical, or advisory) from a patient care device or system to an alert manager information system which then causes a message to be transmitted to an alert communication system which sends the message to an endpoint communication device (computer, one-way pager, PBX phone, Wi-Fi phone or tablet, or public wireless mobile device). If the endpoint communication device is able to provide an acknowledgment (delivery confirmation, read receipt, operator accept/reject), the alert managing system can be notified which in turn notifies the alert originating system. The alert originating system can take action based upon receipt of alert delivery and response acceptance to do things such as never start or pause medical device or system local alarm audio. | ||
| + | |||
| + | <!-- | ||
''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about. Do not use an actor/transaction diagram here. Show your graphic to someone for 5 seconds (literally) and ask them what it's about. If what they say hits the main points in your summary paragraph, you have succeeded. E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them. .>'' | ''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about. Do not use an actor/transaction diagram here. Show your graphic to someone for 5 seconds (literally) and ask them what it's about. If what they say hits the main points in your summary paragraph, you have succeeded. E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them. .>'' | ||
''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>'' | ''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>'' | ||
| + | --> | ||
==Benefits== | ==Benefits== | ||
| + | :*Provides a secondary means for notifying the appropriate person of a condition needing timely human intervention. | ||
| + | |||
| + | :*Automates otherwise manually initiated workflow notification for greater speed, improved content consistency, better record keeping. | ||
| + | |||
| + | :*Improves workflow notification efficiency by notifying the right person at the right time on the right device. Automates who to notify, on what device, how to do it. Telephony dial back for consultation and read back | ||
| + | |||
| + | :*May allow a clinician in a large or noisy unit to more quickly and accurately identify the source, nature, and action needed for an alert. | ||
| + | |||
| + | :*Provides an escalation mechanism designed to eliminate notification "black holes". Offers work task accept/escalate using two-way devices. Reduces “left a message”, “call back later” issues. | ||
| + | |||
| + | :*The closed loop alert dissemination status back to the alert originator can be used to postpone or pause local alarm audio based upon alert delivery and clinician acceptance. | ||
| + | |||
| + | <!-- | ||
''<List the key benefits the profile provides (e.g. error reduction, increased throughput) and how they come about (e.g. SWF reduces patient errors due to mistyped demographics at the modality by transfering demographics electronically from the Order Filler). Consider using a bullet list for readability>'' | ''<List the key benefits the profile provides (e.g. error reduction, increased throughput) and how they come about (e.g. SWF reduces patient errors due to mistyped demographics at the modality by transfering demographics electronically from the Order Filler). Consider using a bullet list for readability>'' | ||
| + | --> | ||
==Details== | ==Details== | ||
| + | <!-- | ||
''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>'' | ''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>'' | ||
| Line 22: | Line 39: | ||
''<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short. E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>'' | ''<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short. E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>'' | ||
| − | + | --> | |
| + | |||
| + | This profile extends the Device Enterprise Communication profile of the IHE Patient Care Devices domain to further specify the communication of alert data describing states and events significant to patient care from patient care devices to alert manager systems (systems which route alert to end devices for notification of caregivers, or to other systems that record patient care information). | ||
| + | |||
| + | These alerts may be physiological alarms, that is, representing the physiological state of the patient (such as a heart rate above or below a caregiver-specified safe range for the patient), or technical alarms, reflecting conditions in the patient care devices themselves that may require action from caregivers (such as ECG leads off the patient), or advisories not associasted with an alarm. | ||
| + | |||
| + | The intent of this profile is to give a uniform way of representing such common alert conditions in HL7 messages to facilitate interoperability of systems from different vendors. | ||
| + | |||
| + | |||
| + | :*Defines the interfaces needed to mediate between a patient care device and a system communicating with a smart phone or other portable device. | ||
| + | |||
==Systems Affected== | ==Systems Affected== | ||
| + | |||
| + | Patient care devices and intermediary (device concentrator) systems | ||
| + | |||
| + | Portable personnel notification systems (pagers, smart phones, and the like) | ||
| + | |||
| + | <!-- | ||
''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>'' | ''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>'' | ||
| Line 29: | Line 62: | ||
* ''Display systems may query, retrieve and display Evidence Documents.'' | * ''Display systems may query, retrieve and display Evidence Documents.'' | ||
* ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports | * ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports | ||
| + | --> | ||
| + | |||
| + | ==Actors & Transactions:== | ||
| + | |||
| + | [[Image:ACMactors.png]] | ||
| + | |||
| + | '''Actors''' | ||
| + | |||
| + | Alert Reporter – The Alert Reporter (AR) actor sources the alert (alert - physiological or technical, or advisory) to Alert Manager (AM). | ||
| + | |||
| + | Alert Manager – The Alert Manager (AM) actor receives the alert from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC). | ||
| − | + | Alert Communicator – The Alert Communicator (AC) actor receives the alert from the Alert Manager (AM) and sends the alert to the client application in the endpoint device. | |
| − | '' | + | '''Transactions''' |
| + | |||
| + | PCD-04 - Report Alert, sends original alert, an update, or conclusion of an alert from the AR actor to the AM actor (HL7 v2) | ||
| + | |||
| + | PCD-05 - Report Alert Status, provides status of alert dissemination, delivery status, and operator response from the AM actor to the AR actor (HL7 v2) | ||
| + | |||
| + | PCD-06 - Disseminate Alert, sends AR actor prepared alert message to the AC actor for delivery to endpoint communication devices (WCTP) | ||
| + | |||
| + | PCD-07 - Report Dissemination Alert Status, the AC actor reports back to the AM actor as to the success or failure of communicating the alert message to the endpoint communication device and the operator response (WCTP) | ||
==Specification== | ==Specification== | ||
| − | '''Profile Status:''' | + | '''Profile Status:''' Final Text |
| − | |||
'''Documents:''' | '''Documents:''' | ||
| + | [[PCD Profile Alert Communication Management | ACM Documents Page]] | ||
| + | |||
| + | <!-- | ||
''<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>'' | ''<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>'' | ||
| Line 47: | Line 101: | ||
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf Vol. 2] - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23 | :* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf Vol. 2] - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23 | ||
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf Vol. 3] - Appendix E | :* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf Vol. 3] - Appendix E | ||
| + | |||
| + | --> | ||
'''Underlying Standards:''' | '''Underlying Standards:''' | ||
| − | |||
| − | |||
:* [http://www.hl7.org HL7] | :* [http://www.hl7.org HL7] | ||
| − | :* | + | :* IEEE 11073-10101 |
| + | :* ISO/IEC 60601-1-8 | ||
| + | :* WCTP | ||
==See Also== | ==See Also== | ||
| − | |||
| + | '''Related Profiles''' | ||
| + | * ''[[PCD_Profile_DEC_Overview|Device Enterprise Communication]] [DEC] can transmit the same kinds of notifications to an information system rather than to the operator of an endpoint communication device'' | ||
| + | |||
| + | * ''[[PCD_Profile_MEMDMC_Overview|Medical Equipment Management Device Management Communication]] [MEM DMC] can use the ACM profile to communicate device management related alerts (calibration required, self-test fail, battery status or charging issues) to people (clinicians, clinical engineering)'' | ||
| + | |||
| + | * ''[[PCD_Profile_MEMLS_Overview|Medical Equipment Management Location Services]] [MEM LS] can use the ACM profile to communicate location observation alerts (movement, boundary transition, exceeding environmental limits, operator interaction with RTLS tags) to people (clinicians, clinical engineering), additionally an ACM AR or AM actor can be a consumer of MEM LS location observations and include that information in alert notifications'' | ||
| + | |||
| + | '''Reference Articles''' | ||
| − | + | Medical device interoperability and the Integrating the Healthcare Enterprise (IHE) initiative | |
| − | + | JG Rhoads, T Cooper, F Fuchs, P Schluter… - AAMI IT Horiz, 2010, Pp. 22-27 - | |
| + | [http://www.aami.org/publications/ITHorizons/2010/21-27_MDI_Rhoads.pdf PDF] | ||
| + | An open source toolkit for managing patient monitoring device alarms based on the IHE Alarm Communication Management profile. | ||
| + | MJB van Ettinger, JA Lipton, KJ Fuchs. Computers in Cardiology, 2009, Pp. 85 - 88, [http://cinc.mit.edu/archives/2009/pdf/0085.pdf PDF] | ||
| + | <!-- | ||
'''Consumer Information''' | '''Consumer Information''' | ||
| Line 70: | Line 137: | ||
The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile. ''<Replace the link with a link to the actual Purchasing page for the Profile>'' | The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile. ''<Replace the link with a link to the actual Purchasing page for the Profile>'' | ||
| − | |||
'''Implementer Information''' | '''Implementer Information''' | ||
The [[Profile Implementation Template]] provides additional information about implementing this Profile in software. ''<Replace the link with a link to the actual Implementation page for the Profile>'' | The [[Profile Implementation Template]] provides additional information about implementing this Profile in software. ''<Replace the link with a link to the actual Implementation page for the Profile>'' | ||
| − | + | ||
| − | |||
''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >'' | ''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >'' | ||
| − | + | --> | |
This page is based on the [[Profile Overview Template]] | This page is based on the [[Profile Overview Template]] | ||
[[Category:Profiles]] | [[Category:Profiles]] | ||
| + | [[Category:PCD Profile]] | ||
| + | [[Category:HL7v2]] | ||
Latest revision as of 03:10, 31 March 2022
Alert Communication Management (ACM) allows a patient care device or system to send a notification of an alert to a person on their communication device, anything from one-way pagers, to PBX phones, to Wi-Fi devices, to mobile phones. ACM was previously known as Alarm Communication Management and was changed to Alert Communication Management to broaden the scope beyond medical device physiologic and technical alarms to include advisories, such as workflow events and notifications.
Summary
The Alert Communication Management profile defines an HL7 V2 message for communicating detailed information about an alert (alarm - physiological or technical, or advisory) from a patient care device or system to an alert manager information system which then causes a message to be transmitted to an alert communication system which sends the message to an endpoint communication device (computer, one-way pager, PBX phone, Wi-Fi phone or tablet, or public wireless mobile device). If the endpoint communication device is able to provide an acknowledgment (delivery confirmation, read receipt, operator accept/reject), the alert managing system can be notified which in turn notifies the alert originating system. The alert originating system can take action based upon receipt of alert delivery and response acceptance to do things such as never start or pause medical device or system local alarm audio.
Benefits
- Provides a secondary means for notifying the appropriate person of a condition needing timely human intervention.
- Automates otherwise manually initiated workflow notification for greater speed, improved content consistency, better record keeping.
- Improves workflow notification efficiency by notifying the right person at the right time on the right device. Automates who to notify, on what device, how to do it. Telephony dial back for consultation and read back
- May allow a clinician in a large or noisy unit to more quickly and accurately identify the source, nature, and action needed for an alert.
- Provides an escalation mechanism designed to eliminate notification "black holes". Offers work task accept/escalate using two-way devices. Reduces “left a message”, “call back later” issues.
- The closed loop alert dissemination status back to the alert originator can be used to postpone or pause local alarm audio based upon alert delivery and clinician acceptance.
Details
This profile extends the Device Enterprise Communication profile of the IHE Patient Care Devices domain to further specify the communication of alert data describing states and events significant to patient care from patient care devices to alert manager systems (systems which route alert to end devices for notification of caregivers, or to other systems that record patient care information).
These alerts may be physiological alarms, that is, representing the physiological state of the patient (such as a heart rate above or below a caregiver-specified safe range for the patient), or technical alarms, reflecting conditions in the patient care devices themselves that may require action from caregivers (such as ECG leads off the patient), or advisories not associasted with an alarm.
The intent of this profile is to give a uniform way of representing such common alert conditions in HL7 messages to facilitate interoperability of systems from different vendors.
- Defines the interfaces needed to mediate between a patient care device and a system communicating with a smart phone or other portable device.
Systems Affected
Patient care devices and intermediary (device concentrator) systems
Portable personnel notification systems (pagers, smart phones, and the like)
Actors & Transactions:
Actors
Alert Reporter – The Alert Reporter (AR) actor sources the alert (alert - physiological or technical, or advisory) to Alert Manager (AM).
Alert Manager – The Alert Manager (AM) actor receives the alert from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC).
Alert Communicator – The Alert Communicator (AC) actor receives the alert from the Alert Manager (AM) and sends the alert to the client application in the endpoint device.
Transactions
PCD-04 - Report Alert, sends original alert, an update, or conclusion of an alert from the AR actor to the AM actor (HL7 v2)
PCD-05 - Report Alert Status, provides status of alert dissemination, delivery status, and operator response from the AM actor to the AR actor (HL7 v2)
PCD-06 - Disseminate Alert, sends AR actor prepared alert message to the AC actor for delivery to endpoint communication devices (WCTP)
PCD-07 - Report Dissemination Alert Status, the AC actor reports back to the AM actor as to the success or failure of communicating the alert message to the endpoint communication device and the operator response (WCTP)
Specification
Profile Status: Final Text
Documents:
Underlying Standards:
- HL7
- IEEE 11073-10101
- ISO/IEC 60601-1-8
- WCTP
See Also
Related Profiles
- Device Enterprise Communication [DEC] can transmit the same kinds of notifications to an information system rather than to the operator of an endpoint communication device
- Medical Equipment Management Device Management Communication [MEM DMC] can use the ACM profile to communicate device management related alerts (calibration required, self-test fail, battery status or charging issues) to people (clinicians, clinical engineering)
- Medical Equipment Management Location Services [MEM LS] can use the ACM profile to communicate location observation alerts (movement, boundary transition, exceeding environmental limits, operator interaction with RTLS tags) to people (clinicians, clinical engineering), additionally an ACM AR or AM actor can be a consumer of MEM LS location observations and include that information in alert notifications
Reference Articles
Medical device interoperability and the Integrating the Healthcare Enterprise (IHE) initiative JG Rhoads, T Cooper, F Fuchs, P Schluter… - AAMI IT Horiz, 2010, Pp. 22-27 - PDF
An open source toolkit for managing patient monitoring device alarms based on the IHE Alarm Communication Management profile. MJB van Ettinger, JA Lipton, KJ Fuchs. Computers in Cardiology, 2009, Pp. 85 - 88, PDF
This page is based on the Profile Overview Template