Talk:PCD Profile Alarm Communication Management

The Following Is An Exchange of Emails Between Kevin O'Donnell and Monroe Patillo

Kevin's email was sent Tuesday, May 6, 2008 and Monroe's response was sent May 7, 2008 Kevin's message paragraphs are in red, Monroe's are black.

Kevin,

Thank you for your inquiry on our Wiki page regarding IHE PCD Alarm Communication management (ACM) and how it might relate to the Critical Results Brief Proposal. There is a potential relationship. The ACM AM actor offers potential resolution for some of the issues raised by the Critical Results Brief Proposal, such as…

Good to hear. Our premise was that although Radiology had some specific use cases that needed to be covered, the need for such alarms/alerts, and the mechanisms that would be used were not specific to Radiology so it made more sense for another domain to tackle it. Happy to hear about the PCD effort.

By the way, the Critical Results Detailed Proposal has a lot more relevant details than the Brief Proposal. For example it mentions the point you raise that the primary point of alarms is as notification, and although they may carry a small information payload, any bulk information should use existing methods/profiles for conveying reports, etc.

Having the information needed to track down the appropriate individual (likely to support staff to patient assignments and communications device to staff assignments) Likely to support escalation of event notifications should initial message recipients not respond in a timely manner or have their devices turned off Likely to record communications events (send, can’t send, receipt, acknowledge, etc.), although storage duration is not likely to be long term Its PCD responsiveness requirement means it is likely to utilize immediate communications devices not making use of store and forward techniques or WAN circuits

By being between the AR and AC actors, the AM actor isolates the AR actor from needing to know how to communicate with all the proprietary communications device systems in the industry.

True. The Alarm Manager would also then be responsible for facilitating the receipt/acknowledgement messages getting back to the Alarm Reporter. Since the process we will be facilitating is that Human A is responsible for making sure that Human B has received/understood the alarm, Human A is "on the hook" until they have received positive communication that their responsibility has been discharged.

Through the future addition of use models for RAD, LAB, and other activities, the ACM profile is anticipated to be widely utilized, by all IHE domains as needed, well beyond the initial PCD effort. However, it is understood that not all vendor products currently recognized as potential AM actors support the full breadth of desired functionality, like communications presence concepts, passing incremental communications status steps back to the alarm sourcing system, and flexible image support for things like waveform snippets, and that the AM to AC communications is currently, and is expected to be for quite some time, noticeably vendor specific if not proprietary. Therefore early vendor adoption is eased through constraining required functionality and by specifying the data items, but not the protocol or end device presentation in the AM to AC communications.

I can understand some of the practical constraints of the industry. I'm not sure if you've had Steve Moore, or Lynn Felhoffer (two of the project managers for the Connectathon who write/validate the test cases) at any of your TC meetings, but you might want to run some of your thoughts past them.

Leaving out device presentation is reasonable and typical in IHE profiles since it does not affect interoperability. Leaving the protocol unconstrained on the other hand, does raise significant interoperability issues which is the raison d'etre of IHE. There are ways to allow flexibility, such as making a list of accepted protocols and requiring the hub to support ALL protocols and the leaf nodes to have the option of choosing one or more. The evaluation is how much effort does that add to the hub and what does each protocol gain. In some cases an extra protocol handles a necessary capability that no other protocol can, in others it pulls in a whole body of leaf nodes that would not otherwise play.

Unfortunately, our PCD ACM effort has a small window of opportunity in which to get the supplement created and distributed for review and signoff and into the Connectathon this year thus our initial focus is on PCD systems as the only Alarm Reporter (AR) actors.

The annual cycle is definitely a challenge. If you can set it up so that the requirements on Alarm Manager will not change with the added use cases, you can potentially add other Reporters later without invalidating existing implementations. Of course that means working through the other use cases. Probably a good profile to leave in Trial Implementation for a couple years to leave your options open for changing requirements.

The ACM is meant to receive and dispatch event notifications in an expedited manner. It is not meant to be a means of directly providing highly detailed information or documents for the events it conveys, although including active references to such information on other systems has potential. The ACM is not meant to provide access to or to display patient medical imagery. It is not meant to replace profiles for detailed information or historical access to EMR, HIS, PACS, or LIS systems.

Agreed. That was our conclusion too. The alert notifies the recipient of the existence and nature of a critical result. In this case, perhaps a radiology report with a critical finding. A one line summary of the finding might be carried by ACM, and perhaps a reference, but accessing/ viewing the report is outside the scope. The interesting bit will be how to dove-tail the two so that a "receipt" for the viewing can be logged. Our thoughts had been that we might be able to leverage ATNA (although when we discussed it with some people in the ITI domain they pointed out that this would need to be reviewed since ATNA was designed for tracking privacy details and might not be completely appropriate). I invite you or any member of the RAD, LAB, IT, or any other interested domain to audit our efforts or to request addition to the distribution. I've cc'd Paul Nagy who was the original proponent of the Radiology Use Case. We'd be very happy if you could include the Radiology Use Case in your documented list of use cases. If there are details you think are missing or a detail you are not sure if you have addressed, I'm sure we can fill in the details.

I'm not sure if ACM was ever brought up at the Domain Coordination Cmte. I apologize if I missed it. That would have been the best time to try and get Paul or others involved.

Til later,

 Kevin

We expect this week to be adding tables for the HL7 messages (strong focus on ORU^R01) and alarm parameter enumerations (for specifying alarm profile specific things like alarm priority).

Regards,

Monroe