Difference between revisions of "Requirements-Dynamic Model"
| Line 86: | Line 86: | ||
|- | |- | ||
| ''Rationale'' | | ''Rationale'' | ||
| − | | | + | | This is the definition of an HL7 interaction. |
|- | |- | ||
| ''MIF'' | | ''MIF'' | ||
| Line 95: | Line 95: | ||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
| '''Requirement''' | | '''Requirement''' | ||
| − | | | + | | Communicate conformance of receiver responsibilities. It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). |
|- | |- | ||
| ''Rationale'' | | ''Rationale'' | ||
| − | | | + | | It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). |
|- | |- | ||
| ''MIF'' | | ''MIF'' | ||
Revision as of 19:48, 19 October 2009
This page documents one or more V3 Methodology Requirements
Contents
Dynamic Model Components
The behavioral aspects of communicating via HL7 V3 information models is referred to in HL7 as the dynamic model. The dynamic model includes the following:
| Term | Definition |
| Interaction | A single exchange of data between systems (sending/receiving each with an application role) for a particular reason (trigger event) with a set of expected response behaviors (receiver responsibilities). Definition of the interaction includes declaration of the trigger event, transport wrapper, control act wrapper, and payload. |
| Application Role | Functional capability of a system/application. In an interaction both the sending system and receiving system have specific application roles. Application roles represent a set of communication responsibilities that might be implemented by an application. Thus they describe system components or sub-components that send and/or receive interactions. |
| Trigger Event | reason or action why information is exchanged ; one and only one action to perform |
| Receiver Responsibilities | Identifies a possible set of actions to be taken in response to the receipt of an interaction |
Interaction
Interactions are at the heart of messaging. The formal definition of an interaction is:
A unique association between a specific message type (information transfer), a particular trigger event that initiates or "triggers" the transfer, and the Receiver Responsibilities (in terms of response interactions) associated with the receipt of the Interaction.
A single Interaction explicitly answers the questions:
1.What the particular message type is
2.What caused the message to be sent
3.How a receiving system knows when it has to send a particular type of response message.
As the list above indicates, each interaction is related to a trigger event, a message type and receiver responsibilities. In the Version 3 specification, the Interactions are presented with a name, the artifact ID, and a table that lists the sending and receiving application roles, the trigger event, the message type, the Event type and the Wrapper types. The sending and receiving application roles as well as the event type are listed in the Version 3 specification for information only
The Event type is the Trigger Event type. Valid values are interaction-based, state-transition based, user-based or unspecified.
The Wrapper types refer to the Transmission Wrapper and the Trigger Event Control Act Wrapper. The Trigger Event Control Act wrapper is a conditional wrapper which contains domain specific administrative information related to that which triggered the interaction. This type of wrapper does not appear with HL7 messages where there is no additional context that is needed to be exchanged dynamically, or with HL7 messages that are carrying commands to coordinate the operation of message handling services.
Trigger Event
A trigger event is an explicit set of conditions that initiate the transfer of information between system components (application roles). It is a real-world event such as the placing of a laboratory order or drug order. The trigger event must be systematically recognizable by an automated system.
Within the v3 standards, trigger events are defined by a name, an artifact ID, a description, and a Type. The Structured Name is used to sort the trigger events within a particular domain into a logical sequence and is assigned by the Technical Committee.The required Structured Name for a trigger event must comprise Mood, State -Transition and Type, however note that all committees are not yet following these recommendations in current ballots.
In the v3 standard, most trigger events will be a specifiedType, from the following list:
| Type | Description |
| Interaction-Based | Trigger events can be based on another interaction. For example, the response to a query (which is an interaction) is an Interaction Based trigger event. |
| State-Based | Trigger events resulting from a state transition as depicted in the State Transition Model for a particular message interaction. The trigger for canceling a document, for example, may be considered a State Transition Based trigger event |
| User Action | User Request Based: Trigger events may be based on a user request. For example, the trigger event that prompts a system to send all accumulated data to a tracking system every 12 hours is considered User Based. |
| Unspecified | Trigger events that don't fall into one of the other categories |
Most trigger events are State-Transition based and will be encountered when reading the dynamic message model (state diagram) information defined to support a particular message interaction. Some trigger events may be based on more than one state transition, which are assumed to occur simultaneously. In some cases, trigger events may not fall into any of the three categories defined in the above list. In these cases, Unspecified will appear as the Type. The trigger event Type, when specified, affects the responsibilities of the interactions initiated by that trigger event.
State Machine
The behavioral aspect of a class is defined in a state diagram associated with a class in an information model. State diagrams, which show all of the potential states for a class, are developed for classes that are the central subject of an interaction. These classes are called subject classes. Interactions are sometimes motivated by changes in the state of a subject class. For example, Act may be identified as a subject class. The vocabulary domain for the Act.status_cd declares the defined states for the Act. Those states include Active, Suspended, Cancelled, Complete, and Aborted. A state diagram depicts the allowable class states with a box labeled with the name of the state. Changes in state are called state transitions and are depicted in the diagram by a line with a arrowhead showing the direction of the transition. An example of a state transition might be the change in the state of an Act from Active to Complete. The change in state (state transition) is associated with a trigger event that causes the transition. The trigger event in this example might be the fulfillment of an order. An order is a special type of Act. The transition from an Active order to a Completed order is triggered by the fulfillment of the Order. The state diagram depicts the states, trigger event, and state transitions of interest.
Class Diagram using UML
Requirements
| Requirement | An interaction binds one trigger event, one payload model, one control act wrapper, one transport wrapper, a sending application role, a receiving application role, and one or more receiver responsibilities. |
| Rationale | This is the definition of an HL7 interaction. |
| MIF |
|
| Requirement | Communicate conformance of receiver responsibilities. It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). |
| Rationale | It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). |
| MIF |
|
