This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Requirements-Dynamic Model"

From HL7Wiki
Jump to navigation Jump to search
Line 3: Line 3:
 
This page documents one or more [[:category:V3 Methodology Requirements|V3 Methodology Requirements]]
 
This page documents one or more [[:category:V3 Methodology Requirements|V3 Methodology Requirements]]
 
</div>
 
</div>
 +
 +
===Description===
 +
The HL7 methodology includes two parts needed for communication information between systems, the static model (content itself) and the dynamic model (what is the receiver supposed to do with the information that has been communicated).  This section seeks to briefly describe the dynamic model and to thoroughly document the dynamic model requirements for MIF.
 +
 +
The core of the HL7 dynamic model is the interaction.  A formal definition from HL7:
 +
 +
A unique association between a specific message type (static model or document), 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 (static model which may be a document, a external addressing (transport) wrapper, and an 'action' wrapper.
 +
2.What caused the message to be sent (triggering event)
 +
3.What is expected of the receiving system (trigger event)
 +
3.How a receiving system knows when it has to send a particular type of response message(s) - (receiver responsibilities).
  
 
===Requirements===
 
===Requirements===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each trigger event must have a unique name
+
| Each interaction must have a trigger event.  HL7 needs to be able to define the 'real world' occurrences that result in a need for information to be exchanged
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The trigger events must be able to be precisely referenced when creating interactions.  The trigger event is the reason for communicating information.
+
| The trigger events must be able to be precisely referenced when creating interactions.  The trigger event is the reason for communicating information.  Part of interoperability is not only what information will get shared but also the circumstances where it will be shared.  A system that does not share the appropriate information at the correct time will not achieve interoperability.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/TriggerEvent/@name
+
* mif-model-dynamic.xsd/Interaction/@invokingTriggerEvent
 
|}
 
|}
  
Line 20: Line 33:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Trigger events may have annotations
+
| Each trigger event must have a unique name
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
+
| The trigger events must be able to be precisely referenced when creating interactions. The trigger event is the reason for communicating information.
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for.  
 
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/TriggerEvent/@annotations
+
* mif-model-dynamic.xsd/TriggerEvent/@name
 
|}
 
|}
  
Line 34: Line 46:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| There are three types of triggering events
+
| Each trigger event must include a type.  There are three types.
 
*interaction-based
 
*interaction-based
 
*state-based
 
*state-based
Line 40: Line 52:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Each trigger event must include a type.   
+
| The trigger event types communiate the 'pattern' expected as far as receiver responsibilities.  For example, and interaction-based trigger event is 'kicked off' when a triggering interaction is communicated.   
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 78: Line 90:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Interactions may have annotations
+
| Each interaction must include one or more static models.  There are use cases where only the transport wrapper, and/or transport and control act wrapper are communicated without a 'payload' (meaning a static model or document).
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
+
| The interactions must be able to be precisely referenced esp. as part of receiver responsibilities.  Also, the receiving system needs to kn ow
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for.
 
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/Interaction/@annotations
 
|}
 
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''
 
| Each interaction must include one (reference to a) trigger event and static model.
 
|-
 
| ''Rationale''
 
| The interactions must be able to be precisely referenced esp. as part of receiver responsibilities.
 
|-
 
| ''MIF''
 
|
 
* mif-model-dynamic.xsd/Interaction/@invokingTriggerEvent
 
 
* mif-model-dynamic.xsd/Interaction/@argumentMessage
 
* mif-model-dynamic.xsd/Interaction/@argumentMessage
 
|}
 
|}
Line 141: Line 138:
 
|
 
|
 
* mif-model-dynamic.xsd/Interaction/@interactionType
 
* mif-model-dynamic.xsd/Interaction/@interactionType
|}
 
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''
 
| Structured documents may have annotations
 
|-
 
| ''Rationale''
 
| Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
 
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for.
 
|-
 
| ''MIF''
 
|
 
* mif-model-dynamic.xsd/StructuredDocument/@annotations
 
 
|}
 
|}
  
Line 272: Line 255:
 
|
 
|
 
* mif-model-dynamic.xsd/ApplicationRole/@name
 
* mif-model-dynamic.xsd/ApplicationRole/@name
|}
 
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''
 
| Application roles may have annotations.
 
|-
 
| ''Rationale''
 
| Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
 
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for.
 
|-
 
| ''MIF''
 
|
 
* mif-model-dynamic.xsd/ApplicationRole/@annotations
 
 
|}
 
|}
  

Revision as of 15:23, 21 October 2009