This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Requirements-Dynamic Model"

From HL7Wiki
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:
  
−
interaction - A single exchange of data between systems (sending/receiving each with an application role) for a particular reason with a set of expected response behaviors (user action, interaction response, state based)
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
−
 
+
| '''Term'''
−
interaction binds wrappers with payload - transport wrapper, control act (trigger event) wrapper, payload
+
| '''Definition'''
−
 
+
|-
−
interaction patterns
+
| Interaction
−
user action - trigger event
+
| 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 based (query) -  
+
|-
−
state based - introduction of state machine, statuses
+
| 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 ; ne and only one action to perform
+
|-
 +
| 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.
  
−
application role - functional capability of a system/application
+
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.
  
−
parameter model - Identifies a parameter and the static model it is bound to.
+
In the v3 standard, most trigger events will be a specifiedType, from the following list:
  
−
BoundStaticModel - Identifies a root static model as well as any models bound to parameterized stubs within the model.
+
•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.  
  
−
receiver responsibility - Identifies a possible set of actions to be taken in response to the receipt of an interaction.
 
  
 +
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
  
−
state machine?
 
  
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
+
{| border="2" cellspacing="0" cellpadding="3" width="400"
−
| '''Term'''  
+
| '''Type'''  
−
| '''Definition'''
+
| '''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.
 
|-
 
|-
−
| Interaction
+
| ''State-Based''
−
| A single exchange of data between systems (sending/receiving each with an application role) for a particular reason with a set of expected response behaviors (user action, interaction response, state based).  Definition of the interaction includes declaration of the trigger event, transport wrapper, control act wrapper, and payload.
+
| 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.
 
|-
 
|-
−
| Trigger Event
+
| ''User Action''
−
| reason or action why information is exchanged ; ne and only one action to perform
+
| 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.
 
|}
 
|}
−
 
−
 
−
application role - functional capability of a system/application
 
−
 
−
parameter model - Identifies a parameter and the static model it is bound to.
 
−
 
−
BoundStaticModel - Identifies a root static model as well as any models bound to parameterized stubs within the model.
 
−
 
−
receiver responsibility - Identifies a possible set of actions to be taken in response to the receipt of an interaction.
 
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"

Revision as of 16:05, 19 October 2009

This page documents one or more V3 Methodology Requirements

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

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. model - AMS


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.
Term Descriptive free-text metadata about an artifact must be able to be captured in a primary language along with translations to other languages
Definition 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.
MIF
  • mif-model-dynamic.xsd
Retrieved from "https://wiki.hl7.org/w/index.php?title=Requirements-Dynamic_Model&oldid=28146"