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 5: Line 5:
  
 
===Description===
 
===Description===
−
The HL7 methodology includes two parts needed for communication of information between systems, the static model (information content itself and any wrappers) and the dynamic model which describes the circumstances under which that information is sent and how that exchange fits into an overall pattern of communication.   
+
The HL7 methodology includes two parts needed for communication of information between systems, the static model (information content itself and any wrappers) and the dynamic model which describes the circumstances under which that information is sent and how that exchange fits into an overall pattern of communication.  "Dynamic model" refers to a set of interrelated artifacts that together define the behavioral portion of an HL7 v3 specification. The artifacts include:
−
 
+
* [[Requirements-Dynamic Model#Trigger Events|Trigger Events]]: When is information exchanged?
−
The core of the HL7 dynamic model is the interaction.  A formal definition from HL7:
+
* [[Requirements-Dynamic Model#Trigger Events|Application Roles]]: Who are the participants in an exchange?
−
 
+
* [[Requirements-Dynamic Model#Interactions|Interactions]]: What are the characteristics of a single exchange, including its place in an overall communication pattern?
−
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:  
 
−
#What the particular message type is (static model which may be a document, a external addressing (transport) wrapper, and an 'action' wrapper.
 
−
#What caused the message to be sent (triggering event)
 
−
#What is expected of the receiving system (trigger event)
 
−
#How a receiving system knows when it has to send a particular type of response message(s) - (receiver responsibilities).
 
−
 
 
−
Interactions are categorized by type and each type is typified by a pattern of receiver responsibilities.
 
−
*interaction-based - An interaction caused by the receipt of another interaction.  For example query response receiver responsibility.
 
−
*state-based - An interaction caused by a change in status.  For example, putting a repeating order on hold (to suspend action on that order).  Receiver responsibility is usually a confirm or other acknowledgement.
 
−
*user-based  - An interaction caused by a user interacting with a system or some other environmental occurrence.  Receiver responsibilities varies from a simple acknowledgement to multiple interactions (for example, lab order fulfillment).
 
  
 
==Requirements==
 
==Requirements==
−
===Dynamic Model===
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| HL7 requires a methodology and structure for both sending information as well as communicating the 'reason' information has been communicated.  The reason for the information communication are the dynamic model components.  The primary structure is the interaction (described above).
 
−
|-
 
−
| ''Rationale''
 
−
| A formal structure is needed to produce formalized, harmonized, interoperable standards.
 
−
|-
 
−
| ''MIF''
 
−
|
 
−
* mif-model-dynamic.xsd/Interaction
 
−
|}
 
−
 
 
===Trigger Events===
 
===Trigger Events===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| 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
+
| There needs to be a means of defining and standardizing the definition of 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.  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.
+
| 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
−
* mif-model-dynamic.xsd/TriggerEvent
 
−
* mif-model-dynamic.xsd/Interaction/invokingTriggerEvent
 
 
|}
 
|}
  
Line 56: Line 29:
 
|-
 
|-
 
| ''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 in human-to-human communication.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 66: Line 39:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Each trigger event must include a type.
+
| Each trigger event must identify, as formally as possible, the real-world occurrence that causes information to flow.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| The trigger event types communicate the 'pattern' expected as far as receiver responsibilities.  For example, and interaction-based trigger event is 'kicked off' when a triggering interaction is communicated.
+
| The purpose of a trigger event is to give a standardized label to a particular type of real-world event so that it can be referenced.  If the real-world event isn't defined or is defined only loosely, the trigger event's purpose won't be met.
 
|-
 
|-
 
| ''Methodology''  
 
| ''Methodology''  
−
| There are three types:
+
| There are three categories:
−
*interaction-based - An interaction caused by the receipt of another interaction.  For example query response.
+
*interaction-based - An interaction caused by the receipt of another interaction.  For example query response.  Interaction based trigger events reference the interaction that triggers them.
−
*state-based - An interaction caused by a change in status.  For example, putting a repeating order on hold (to suspend action on that order)
+
*state transition-based - An interaction caused by a change in status.  For example, putting a repeating order on hold (to suspend action on that order).  State-based trigger events reference the static model, class and state transition they are associated with
−
*user-based  - An interaction caused by a user interacting with a system or some other environmental occurrence.
+
*environment-based  - An interaction caused by a user interacting with a system or some other environmental occurrence.  For example, user deciding to query a system; daily notification sent out at 2am.  Environment based trigger events include a textual description of the real world event, as there is no more formal way of defining them.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 81: Line 54:
 
* Interaction-based: mif-model-dynamic.xsd/TriggeringEvent/interaction
 
* Interaction-based: mif-model-dynamic.xsd/TriggeringEvent/interaction
 
* State-based:  mif-model-dynamic.xsd/TriggeringEvent/stateTransition
 
* State-based:  mif-model-dynamic.xsd/TriggeringEvent/stateTransition
−
* User-based:  mif-model-dynamic.xsd/TriggeringEvent/environmentalOccurrence
+
* User-based:  mif-model-dynamic.xsd/TriggeringEvent/environmentalOccurrence/text
 
|}
 
|}
  
Line 87: Line 60:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| EnvironmentalOccurrence may have associated text.
+
| EnvironmentalOccurrence may have a related state transition.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Describes the nature of the environmental occurrence (e.g. user action)
+
| Some events that aren't directly caused by a state transition might still have an association to a transition. There are two common situations where this occurs:
−
|-
+
* Request for a state transition to occur; and
−
| ''MIF''
+
* Request for fulfillment of a state transition
−
|
 
−
* mif-model-dynamic.xsd/EnvironmentalOccurrence/text
 
−
|}
 
  
 +
In the first case, the triggering action is usually some user or system decision, but not the actual state transition (because it hasn't happened yet - it's just being asked for.  For example, when a user requests info to be posted to a patient's EHR (related state transition is to 'complete' an observation)
  
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
+
In the second case, the state transition happened some time ago (possibly seconds, possibly days).  A decision has been taken to ask another system to "action" that state transition.  For example, "please fill this prescription".
−
| '''Requirement'''
 
−
| EnvironmentalOccurrence may have a related state transition.
 
−
|-
 
−
| ''Rationale''
 
−
| Describes the state transition related to the environmental occurrence.  A state transition includes the static model, the class, and the transition.  A frequent example is when a user requests info to be posted to a patient's EHR (related state transition is to 'complete' an observation) and record it or to request diagnostic testing (related state transition is to 'activate' an order).  Trigger isn't actually the state transition but is associated with it.  E.g. a request for the transition or request for fulfilllment of a previous transition.  The triggering action is something else, but it's still useful to tie these together because of the semantic linkage.
 
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 109: Line 75:
 
* mif-model-dynamic.xsd/EnvironmentalOccurrence/relatedStateTransition
 
* mif-model-dynamic.xsd/EnvironmentalOccurrence/relatedStateTransition
 
|}
 
|}
−
 
  
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| A state transition includes the static model, the class, and the transition.
+
| Trigger Events may have a number of different types of annotations
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Required to know which information model to update.
+
| See rationales for individual annotations types
 
|-
 
|-
−
| ''MIF''  
+
| ''Implementation''  
−
|
+
|  
−
* mif-model-dynamic.xsd/stateTransition
+
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
−
|}
+
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
−
 
+
* [[Requirements-Annotations#Rationale|Rationale]]
−
===Static Model References===
+
* [[Requirements-Annotations#Requirements|Requirements]]
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
+
* [[Requirements-Annotations#Design Comments|Design Comments]]
−
| '''Requirement'''
+
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
−
| Structured documents have a document definition (static model)
+
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
−
|-
+
* [[Requirements-Annotations#Mapping|Mapping]]
−
| ''Rationale''
+
* [[Requirements-Annotations#Open Issue|Open Issue]]
−
| Documents the primary payload model as well as any parameterized stubs within the model.
+
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
−
|-
+
* [[Requirements-Annotations#Change Request|Change Request]]
−
| ''MIF''
+
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
−
|
 
−
* mif-model-dynamic.xsd/StructuredDocument/DocumentDefinition
 
 
|}
 
|}
  
  
 +
===Interations===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Structured documents may not have a dynamic model.
+
| HL7 v3 specifications must be able to define each possible "exchange" of information including the structure and type of information to be sent, the circumstances in which it is sent and expectations on the receiver.
−
|-
 
−
| ''Rationale''
 
−
| Documents are a point-in-time artifact and, as such, many times have no additional instruction to sending a document to a document repository other than to 'store' the document or a link to the document.  In this case, there is no state transition.
 
−
|-
 
−
| ''MIF''
 
−
|
 
−
* mif-model-dynamic.xsd/StructuredDocument
 
−
|}
 
−
 
 
−
 
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| Each static model must be able to be bound to one or more interactions, and to be bound to one or more other static models.
 
−
|-
 
−
| ''Rationale''
 
−
| Each interaction is bound to a specific payload model, for which is bound a specific control act wrapper model which is bound to a specific transport model.  This includes the binding to an appropriate parameter model for query interactions.  The parameterized models are not bound until defining the interaction so that static models can be re-used in differing interactions to provide similar business function (acknowledgements, for example).
 
−
|-
 
−
| ''MIF''
 
−
|
 
−
* mif-model-dynamic.xsd/BoundStaticModel
 
−
|}
 
−
 
 
−
 
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| Each static model has a content type.
 
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Identifies the type of content represented by the model when entered from this entry point.  The contentType determines whether the model is legitimate content for a classStub from another model.
+
| A single exchange is the lowest possible unit of actual interoperability.  While an exchange is made up of multiple components, there is no interoperability without at least one successfully completed exchange.  To have interoperability, the characteristics of that exchange must be fully defined and agreed to by both parties.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
−
|
+
| mif-model-dynamic.xsd/Interaction
−
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 
−
|}
 
−
 
 
−
 
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
|  Naming must be driven by the binding of the static models to ensure separation of the models transparent.
 
−
|-
 
−
| ''Rationale''
 
−
| Naming of each static model as bound still needs demarcation from the other model content.
 
−
|-
 
−
| ''MIF''
 
−
|
 
−
* mif-model-dynamic.xsd/BoundStaticModel/specialization
 
−
|}
 
−
 
 
−
 
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| For each query interaction, an additional binding to the parameter list is required.  Note this includes query requests as well as query responses.
 
−
|-
 
−
| ''Rationale''
 
−
| The parameter list is required for both requests and responses.
 
−
|-
 
−
| ''MIF''
 
−
|
 
−
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
 
−
* mif-model-dynamic.xsd/ParameterModel
 
 
|}
 
|}
  
  
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| A parameter model is a list of passing parameters with a query request or those used to select records in a query response.  Each parameter has a parameter name and may have a traversal name.
 
−
|-
 
−
| ''Rationale''
 
−
| The parameter list is required for both requests and responses.  The parameter is a unique name per parameter in the same list.  The traversal name is the of the element when traversing from the association end directly to this specialized class
 
−
|-
 
−
| ''MIF''
 
−
|
 
−
* mif-model-dynamic.xsd/ParameterModel/@parameterName
 
−
* mif-model-dynamic.xsd/ParameterModel/@traversalName
 
−
|}
 
−
 
−
===Interations===
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
Line 223: Line 119:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| The interactions must be able to be precisely referenced esp. as part of receiver responsibilities.
+
| Interactions must be able to be referenced in human communication
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 440: Line 336:
 
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 
|}
 
|}
 +
 +
 +
===Static Model References===
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Structured documents have a document definition (static model)
 +
|-
 +
| ''Rationale''
 +
| Documents the primary payload model as well as any parameterized stubs within the model.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument/DocumentDefinition
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Structured documents may not have a dynamic model.
 +
|-
 +
| ''Rationale''
 +
| Documents are a point-in-time artifact and, as such, many times have no additional instruction to sending a document to a document repository other than to 'store' the document or a link to the document.  In this case, there is no state transition.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each static model must be able to be bound to one or more interactions, and to be bound to one or more other static models.
 +
|-
 +
| ''Rationale''
 +
| Each interaction is bound to a specific payload model, for which is bound a specific control act wrapper model which is bound to a specific transport model.  This includes the binding to an appropriate parameter model for query interactions.  The parameterized models are not bound until defining the interaction so that static models can be re-used in differing interactions to provide similar business function (acknowledgements, for example).
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/BoundStaticModel
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each static model has a content type.
 +
|-
 +
| ''Rationale''
 +
| Identifies the type of content represented by the model when entered from this entry point.  The contentType determines whether the model is legitimate content for a classStub from another model.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
|  Naming must be driven by the binding of the static models to ensure separation of the models transparent.
 +
|-
 +
| ''Rationale''
 +
| Naming of each static model as bound still needs demarcation from the other model content.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/BoundStaticModel/specialization
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| For each query interaction, an additional binding to the parameter list is required.  Note this includes query requests as well as query responses.
 +
|-
 +
| ''Rationale''
 +
| The parameter list is required for both requests and responses.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
 +
* mif-model-dynamic.xsd/ParameterModel
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| A parameter model is a list of passing parameters with a query request or those used to select records in a query response.  Each parameter has a parameter name and may have a traversal name.
 +
|-
 +
| ''Rationale''
 +
| The parameter list is required for both requests and responses.  The parameter is a unique name per parameter in the same list.  The traversal name is the of the element when traversing from the association end directly to this specialized class
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ParameterModel/@parameterName
 +
* mif-model-dynamic.xsd/ParameterModel/@traversalName
 +
|}
 +
  
 
===Future Requirements (not complete)===
 
===Future Requirements (not complete)===

Revision as of 05:10, 11 November 2009

This page documents one or more V3 Methodology Requirements

Description

The HL7 methodology includes two parts needed for communication of information between systems, the static model (information content itself and any wrappers) and the dynamic model which describes the circumstances under which that information is sent and how that exchange fits into an overall pattern of communication. "Dynamic model" refers to a set of interrelated artifacts that together define the behavioral portion of an HL7 v3 specification. The artifacts include:

  • Trigger Events: When is information exchanged?
  • Application Roles: Who are the participants in an exchange?
  • Interactions: What are the characteristics of a single exchange, including its place in an overall communication pattern?

Requirements

Trigger Events

Requirement There needs to be a means of defining and standardizing the definition of the 'real world' occurrences that result in a need for information to be exchanged.
Rationale 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-model-dynamic.xsd/TriggerEvent


Requirement Each trigger event must have a unique name
Rationale The trigger events must be able to be precisely referenced in human-to-human communication.
MIF
  • mif-model-dynamic.xsd/TriggerEvent/@name


Requirement Each trigger event must identify, as formally as possible, the real-world occurrence that causes information to flow.
Rationale The purpose of a trigger event is to give a standardized label to a particular type of real-world event so that it can be referenced. If the real-world event isn't defined or is defined only loosely, the trigger event's purpose won't be met.
Methodology There are three categories:
  • interaction-based - An interaction caused by the receipt of another interaction. For example query response. Interaction based trigger events reference the interaction that triggers them.
  • state transition-based - An interaction caused by a change in status. For example, putting a repeating order on hold (to suspend action on that order). State-based trigger events reference the static model, class and state transition they are associated with
  • environment-based - An interaction caused by a user interacting with a system or some other environmental occurrence. For example, user deciding to query a system; daily notification sent out at 2am. Environment based trigger events include a textual description of the real world event, as there is no more formal way of defining them.
MIF
  • Interaction-based: mif-model-dynamic.xsd/TriggeringEvent/interaction
  • State-based: mif-model-dynamic.xsd/TriggeringEvent/stateTransition
  • User-based: mif-model-dynamic.xsd/TriggeringEvent/environmentalOccurrence/text


Requirement EnvironmentalOccurrence may have a related state transition.
Rationale Some events that aren't directly caused by a state transition might still have an association to a transition. There are two common situations where this occurs:
  • Request for a state transition to occur; and
  • Request for fulfillment of a state transition

In the first case, the triggering action is usually some user or system decision, but not the actual state transition (because it hasn't happened yet - it's just being asked for. For example, when a user requests info to be posted to a patient's EHR (related state transition is to 'complete' an observation)

In the second case, the state transition happened some time ago (possibly seconds, possibly days). A decision has been taken to ask another system to "action" that state transition. For example, "please fill this prescription".

MIF
  • mif-model-dynamic.xsd/EnvironmentalOccurrence/relatedStateTransition


Requirement Trigger Events may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation


Interations

Requirement HL7 v3 specifications must be able to define each possible "exchange" of information including the structure and type of information to be sent, the circumstances in which it is sent and expectations on the receiver.
Rationale A single exchange is the lowest possible unit of actual interoperability. While an exchange is made up of multiple components, there is no interoperability without at least one successfully completed exchange. To have interoperability, the characteristics of that exchange must be fully defined and agreed to by both parties.
MIF mif-model-dynamic.xsd/Interaction


Requirement Each interaction must have a unique name
Rationale Interactions must be able to be referenced in human communication
MIF
  • mif-model-dynamic.xsd/Interaction/@name


Requirement 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 The interactions must be able to be precisely referenced esp. as part of receiver responsibilities. Also, the receiving system needs to kn ow
MIF
  • mif-model-dynamic.xsd/Interaction/argumentMessage
  • mif-model-dynamic.xsd/BoundStaticModel


Requirement Interactions must be able to bind to a message model or a document as the payload.
Rationale There are two 'types' of static model content at HL7. RMIMs which represent workflow-type communications and Documents which represent point-in-time information.
MIF
  • mif-model-dynamic.xsd/BoundStaticModel


Requirement Interaction receiver responsibilities must be supported
Rationale Frequently in response to an interaction, one or more 'response' interactions are triggered. There can be multiple responses. For a simple, two-part example, a 'transaction' is not complete until both a request trigger event is and information is communication and it's confirm response is receiver. The confirm response is the 'receive responsibility'. These responsibilities are communicated by the sender and are intended to 'complete' a business function.
MIF
  • mif-model-dynamic.xsd/Interaction/receiverResponsiblities


Requirement Each interaction may include one or more receiver responsibilities
Rationale Frequently in response to an interaction, one or more 'response' interactions are triggered. There can be multiple responses.
MIF
  • mif-model-dynamic.xsd/Interaction/receiverResponsiblities


Requirement Each interaction may have an interaction type.
Rationale Synonymous with trigger event types. See Description above.
MIF
  • mif-model-dynamic.xsd/Interaction/@interactionType


Requirement Interactions may include a use type.
Rationale Identifies the type of content represented by the model when entered from the entry point. The contentType determines whether the model is legitimate content for a classStub (binding) from another model.
MIF
  • mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind

Receiver Responsibilities

Requirement Each receiver responsibility must have a reason.
Rationale Indicates the conditions under which this receiver responsibility should be chosen. Should be mutually exclusive with the conditions of all other receiver responsibilities for this interaction. Also, the combined reasons for all receiver responsibilities should be complete. I.e. There should be no circumstance that doesn't fit into the reason of one and only one receiver responsibility.
MIF
  • mif-model-dynamic.xsd/ReceiverResponsibly/reason


Requirement A receiver responsibility may have one or more 'response' interactions.
Rationale Supports acknowledgements as well as query responses.
MIF
  • mif-model-dynamic.xsd/ReceiverResponsibly/invokingInteraction


Requirement A receiver responsibility may have one or more 'response' trigger events.
Rationale Indicates that the specified trigger event should be fired, along with any interactions associated with that trigger event and supported by any of the receiving system's application roles.
MIF
  • mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent

Application Roles

Requirement Interaction sender and receiver must have an application role.
Rationale The sending and receiving application role are necessary to know which receiver responsibilities to trigger. During a complex interaction pattern, both sending and receiving systems may trigger additional interactions based on receiver responsibilities. To support this, the sender and receiver are both assigned application roles which functionally describe their relation to each other in a business function.
MIF
  • mif-model-dynamic.xsd/ApplicationRole


Requirement Each application role must have a unique name
Rationale The sending and receiving application role must be able to be precisely referenced when creating interactions.
MIF
  • mif-model-dynamic.xsd/ApplicationRole/@name


Requirement Each application role may have related application roles.
Rationale Used to build composites.
MIF
  • mif-model-dynamic.xsd/ApplicationRole/relatedApplicationRoles


Requirement Each application role may be either or both sending interactions and/or receiving interactions.
Rationale Application role is about the functional capability. Need to document for each role when the application expects to receiving information and act; or sends information.
MIF
  • mif-model-dynamic.xsd/ApplicationRole/sendsInteractions
  • mif-model-dynamic.xsd/ApplicationRole/receivesInteractions


Requirement Each application role may either create or consume a document.
Rationale Application roles need to deal with documents as well as other static models.
MIF
  • mif-model-dynamic.xsd/ApplicationRole/createsDocuments
  • mif-model-dynamic.xsd/ApplicationRole/consumesDocuments


Requirement Interactions, Trigger Events, Application Roles and Structured Documents may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation


Static Model References

Requirement Structured documents have a document definition (static model)
Rationale Documents the primary payload model as well as any parameterized stubs within the model.
MIF
  • mif-model-dynamic.xsd/StructuredDocument/DocumentDefinition


Requirement Structured documents may not have a dynamic model.
Rationale Documents are a point-in-time artifact and, as such, many times have no additional instruction to sending a document to a document repository other than to 'store' the document or a link to the document. In this case, there is no state transition.
MIF
  • mif-model-dynamic.xsd/StructuredDocument


Requirement Each static model must be able to be bound to one or more interactions, and to be bound to one or more other static models.
Rationale Each interaction is bound to a specific payload model, for which is bound a specific control act wrapper model which is bound to a specific transport model. This includes the binding to an appropriate parameter model for query interactions. The parameterized models are not bound until defining the interaction so that static models can be re-used in differing interactions to provide similar business function (acknowledgements, for example).
MIF
  • mif-model-dynamic.xsd/BoundStaticModel


Requirement Each static model has a content type.
Rationale Identifies the type of content represented by the model when entered from this entry point. The contentType determines whether the model is legitimate content for a classStub from another model.
MIF
  • mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind


Requirement Naming must be driven by the binding of the static models to ensure separation of the models transparent.
Rationale Naming of each static model as bound still needs demarcation from the other model content.
MIF
  • mif-model-dynamic.xsd/BoundStaticModel/specialization


Requirement For each query interaction, an additional binding to the parameter list is required. Note this includes query requests as well as query responses.
Rationale The parameter list is required for both requests and responses.
MIF
  • mif-model-dynamic.xsd/BoundStaticModel/parameterModel
  • mif-model-dynamic.xsd/ParameterModel


Requirement A parameter model is a list of passing parameters with a query request or those used to select records in a query response. Each parameter has a parameter name and may have a traversal name.
Rationale The parameter list is required for both requests and responses. The parameter is a unique name per parameter in the same list. The traversal name is the of the element when traversing from the association end directly to this specialized class
MIF
  • mif-model-dynamic.xsd/ParameterModel/@parameterName
  • mif-model-dynamic.xsd/ParameterModel/@traversalName


Future Requirements (not complete)

Note that HL7 is currently re-developing and replacing the current dynamic model methodolgy. Below are SOME of the requirements. Requirements are still being determined and documented as part of the HL7 Enterprise Architecture Framework Alpha implementation projects.

Future 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
  • TBD
Retrieved from "https://wiki.hl7.org/w/index.php?title=Requirements-Dynamic_Model&oldid=29041"