Question: How does the HL7 v3 Dynamic Model work

Dec 5, 2012

Question:

What is the actual usage of HL7 dynamic model? The interaction defines trigger event, composite message type, and receiver responsibilities. But does it really matter in message exchange? How are trigger events and receiver responsibilities expected to be used?

Answer:

Trigger events provide context about when interactions are expected to be exchanged.  For example, a particular notification interaction might be expected to be sent when the state of an object changes to “completed”.  In theory, a system that fails to initiate an interaction when the event described by the trigger event occurs could be considered non-conformant.  However, the trigger event alone isn’t sufficient for an interaction to flow.  The application also needs to have an appropriate recipient defined and meet other business rules such as access permissions.  As well, there are no rules about exactly how quickly after the occurrence of the event the interaction needs to actually be sent over the wire.  The best that can really be done is to confirm that a compliant system is capable of sending the interaction in response to the defined triggering condition.

Another consideration is that some interactions may share the same trigger event.  Frequently this is a acknowledgement interaction and a notification interaction, both triggered by a state transition caused by some sort of request interaction.  This means that if a system supports both interactions, it would be expected to invoke both kinds when the event occurs.

Finally, trigger events give a little bit of insight into expected application behaviour.  If the trigger event is a state transition, then that identifies that the application actually changes the state of the specified object type.

Receiver responsibilities are more important.  They define the “application acknowledgement” that is expected in response to a given interaction.  For example, an interaction that requests that a prescription be suspended might have receiver responsibilities to either change the state of the prescription (fire a trigger event) and send an acknowledgement interaction indicating the prescription has been changed or, alternatively, to send a “refusal” interaction indicating that the state of the prescription wasn’t changed and possibly indicating why.

Most commonly receiver responsibilities follow simple patterns.  Query interactions have a responsibility to send a response.  State transition requests and fulfilment requests typically have alternate receiver responsibilities for both acceptance and refusal.  Notifications generally have no receiver responsibilities.  They might receive back an accept acknowledgement, but no application-level acknowledgement is expected.

However, receiver responsibilities can get more sophisticated.  For example, a request to fulfil an order might be met with a counter-proposal interaction that says “I can’t do that, but I could do this instead”, which might in turn have a receiver responsibility to agree or refuse.  These patterns are rare, in part because they don’t work well in synchronous architectures.

HL7 has been looking for alternative dynamic model that provides broader capabilities, such as the ability to indicate that a lab system, after promising to fulfil an order also has a responsibility to later send the results, or perhaps a cancellation of their promise indicating they were unable to fulfil the test (lost the sample, etc.)  However, it’s been challenging to do this in a way that doesn’t make v3 more overwhelmingly complex than it already is, both for committees designing the specifications and the implementers who must realize them.

Note: Lloyd McKenzie provided this answer - thanks Lloyd