View source for OO CR008-625 Add Alert Trigger Event

{{OO Open Change Requests}}
{{OO Open V2.8 Change Requests}}
Return to [[:Category:OO Change Requests|OO Change Requests]] page.

{|width=100% cellspacing=0 cellpadding=2 border=1
|| '''Submitted by:''' Harry Solomon
|| '''Revision date:''' <<Revision Date>>
|-
|| '''Submitted date:''' 11-May-2009
|| '''Change request ID:''' OO CR008
|-
|| '''Standard/IG:''' Standard
|| '''Artifact ID, Name: ''' <<Artifact ID, Name>>
|-
|}

== Issue ==
See [Image:OO CR008-625.doc]


See [http://wiki.hl7.org/images/6/68/OO_CR008-625.doc V2.8 Proposal 625] for problem definition and proposal.

== Recommendation ==


== Rationale ==


== Discussion ==
*14-May-2009
**How addressed with OUL?
***Assumption is that ORU data is sufficient as the alert is less data, more summary.
**Why trigger instead of PRT or other attribute?
***Want application level acknowledgement that the alert was received.
**How do we avoid the “second” ORU to override the first if the placer/filler number is the same?
***Needs further thought.
**Did we cover all alerts through this mechanism?
***What vocabulary do we use in observation ID to encode the alert?  Particularly if the alert is raised as the result of multiple observations.
***How do we link the source observations to the summary alert?
***Does the alert include the underlying observations or only reference?
**Do we have all the application acknowledgement statuses that we need?
**Should the acknowledgement include PID/ORC/OBR/OBX segments to enable responses to a specific component of the initial message.
***Is there a use case for multiple patients to be included in an alert?  If not, may not need some of that.
***Should use case only stay at alert message level?
***If the initial alert message consists of multiple alerts, can the acknowledgement be only all or none, or also some?
**Assumption: The alert sending system has the responsibility to track whether all targeted providers indeed send an acknowledgement as that may happen over time (not all at once).
**Describe use cases of CDS type alerts derived from multiple separate ordered observations
**All points addressed in _02 version.
*25-Sep-2009
**Break out general update to 7.3 intro to a separate proposal
**In queue ack can be done through ACK rather than ORA, remove from proposal
**Replace order-specific rules for Segment Group with use of OBR-49 result handling flag
**Define ORU^R40 separate from ORU^R01 to avoid confusion
**All points addressed in _03 version.
*12-Nov-2009
**Motion to accept new ORU trigger event to place alert to be acknowledged by clinical user, allows specification of the observation that alert is based on, plus supporting observations will be sent. Also includes application level ACK
**These triggers could be used for devices.  As long as everybody realizes that the alert triggers involve a separate communication track then the base results reporting.
**Austin: Are alerts targeted to single recipient or broadcoast?
***Good question – alert itself can ID intended recipient, it is not constrained – one can get multiple ACKs back.
***Could be intended recipient, but “alert distribution manager” ultimately designates.  Could receive multiple acknowledgement.  Would be helpful to have some additional clarifying language to indicate that multiple acknowledgement may be returned, or even none.  
***More of an implementation thing, but it needs to be made clear that multiple ACKs can be sent back, how application processes is, does not need to be defined. Sending application does not know who all it gets distribution to – alert distribution engine can resend based on rules, might be hierarchy, originating application does not know those rules. If it receives none, then someone needs to FU via phone
***None, one or multiple application level responses may be returned, but it is up to the implementation configuration to be handled – Harry to write this in updated proposal.

== Recommended Action Items ==


== Resolution ==
*12-Nov-2009
**Austin: Move to accept proposal with proposed amendment – second by Rob Hausam, further discussion – no, 
****against:0,  abstain: 0, in favor:11