Dynamic Model
This page documents Lore, i.e. all the facts and traditions about a particular subject that have been accumulated over time, but that have not been documented in a ballot yet.
The Version 3 Dynamic Model was first defined in 1996, and has been only modestly changed since then. The primary elements of the dynamic model (as defined in November 2003) are:
- Trigger Events, which determine when certain messages will be communicated;
- Interactions, which specify the message content, the sender, and the receivers; and
- Application Roles, which represent groupings of functionality that an application can do. This includes interactions an application can send, as well as interactions it can receive. In effect this means that one and the same interaction can be used by different application roles.
- Communication Process Models, (new 2006) which represent sequences of interactions that are related to one and the same business process.
History of Application Roles as a component of the Dynamic Model
Although simple to define, the original interaction model had a primary flaw in that the set of unique bindings described for the interaction led to rapid proliferation of very detailed application roles and interactions, which served to obscure the primary purposes of the dynamic model.
This proliferation arose from several sources. Generally, an implementer of a receiving application, is interested in the requirement to interpret and act upon a particular message payload, and the consequent responsibility to act on that message. Implementers of sending applications must consider the responsibility to recognize the event that “fires” the interaction, and its communication responsibilities to a set of receiving application roles.
The first source of proliferation was the fact that for any given message, there might be several classes of application roles interested in receiving it. There are many circumstances in which "broadcasting" a particular message has merit. In that circumstance, the sender has no way of knowing the type of application roles that may be receiving the communication.
Secondly, the communication paradigm calls for the addition of message wrappers that are germane to the type of receiving application role for a given message. Thus any given payload might be wrapped two different ways for a given initiating trigger event. This automatically led to two or more interactions for a given trigger event and basic payload.
Finally, even if the tight binding of interactions is appropriate for detailed conformance claims, it is very difficult for the technical committees of HL7 to identify all possible application roles at the time specification is created, and even more difficult to prune those roles to an appropriate set. Rather, it seemed more reasonable to have the committees define, the generic foundations for a suite of potential interactions, and then to determine sets of application roles for conformance by analyzing the usage patterns of these interactions in actual implementations.
To that end, changes to the dynamic model were discussed during the fall 2003 Working Group Meeting in Memphis, and further elucidated during an interim Methodology AND Modeling tools meeting in November 2003. The revisions made to the dynamic model involve the separation of the definition of application roles and interactions. In simple terms, basic interactions will be defined as part of the HL7 normative specification. These interactions can be combined ‘as appropriate’ by implementers. Over time, HL7 will begin defining normative Application Roles (interfaces) that support common sets of interactions. HL7 currently defines a limited set of informative application roles.
