This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-Dynamic Model"
Jump to navigation
Jump to search
Line 7: | Line 7: | ||
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: | 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: | ||
− | + | {| border="2" cellspacing="0" cellpadding="3" width="600" | |
− | + | | '''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. | |
− | interaction | + | |- |
− | + | | 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 | ||
+ | |} | ||
+ | '''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: | |
− | + | •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-Transition 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 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. | ||
+ | Most trigger events are State-Transition based and will be encountered when reading the dynamic message model 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. | ||
− | |||
+ | 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. | ||
+ | '''State Machine''' | ||
a class (model focus) 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. | a class (model focus) 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. | ||
model - AMS | model - AMS | ||
− | |||
− | {| border="2" cellspacing="0" cellpadding="3" width=" | + | {| border="2" cellspacing="0" cellpadding="3" width="400" |
− | | ''' | + | | '''Type''' |
− | | ''' | + | | '''Description''' |
+ | |- | ||
+ | | ''Interaction-Based'' | ||
+ | | Many HL7 specifications are used by many countries. Even within a country, there is often a need to publish multiple languages to meet official language requirements or to satisfy the needs of local implementers. | ||
|- | |- | ||
− | | | + | | ''State-Based'' |
− | | | + | | Many HL7 specifications are used by many countries. Even within a country, there is often a need to publish multiple languages to meet official language requirements or to satisfy the needs of local implementers. |
|- | |- | ||
− | | | + | | ''User Action'' |
− | | | + | | Many HL7 specifications are used by many countries. Even within a country, there is often a need to publish multiple languages to meet official language requirements or to satisfy the needs of local implementers. |
|} | |} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" |