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 157: Line 157:
 
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 
|}
 
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
|  A static model may be a choice of payload models
 +
|-
 +
| ''Rationale''
 +
| In some models, the payload is actually a choice of models.  Used in models which bring in harmonized and/or summary data.
 +
|-
 +
| ''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
 +
|}
 +
  
 
===Interations===
 
===Interations===
Line 234: Line 262:
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
−
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
+
* mif-model-dynamic.xsd/BoundStaticModel
 
|}
 
|}
  
Line 249: Line 277:
 
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 
|}
 
|}
−
 
−
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
|  A static model may be a choice of payload models
 
−
|-
 
−
| ''Rationale''
 
−
| In some models, the payload is actually a choice of models.  Used in models which bring in harmonized and/or summary data.
 
−
|-
 
−
| ''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/ParameterModel
 
−
|}
 
−
 
  
 
===Receiver Responsibilities===
 
===Receiver Responsibilities===

Revision as of 22:22, 27 October 2009

This page documents one or more V3 Methodology Requirements

Description

The HL7 methodology includes two parts needed for communication pf information between systems, the static model (content itself and any wrappers) 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

Dynamic Model

Requirement HL7 requires a methdology 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

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
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.
MIF
  • mif-model-dynamic.xsd/TriggerEvent
  • mif-model-dynamic.xsd/Interaction/invokingTriggerEvent


Requirement Each trigger event must have a unique name
Rationale The trigger events must be able to be precisely referenced when creating interactions. The trigger event is the reason for communicating information.
MIF
  • mif-model-dynamic.xsd/TriggerEvent/@name


Requirement Each trigger event must include a type.
Rationale 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.
Methodology There are three types:
  • interaction-based - An interaction caused by the receipt of another interaction. For example query reponse.
  • state-based - An interaction caused by a change in status. For example, putting a repeating order on hold (to suspend action on that order)
  • user-based - An interaction caused by a user interacting with a system or some other environmental occurrence.
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


Requirement EnvironmentalOccurrence may have associated text.
Rationale Describes the nature of the environmental occurrence (e.g. user action)
MIF
  • mif-model-dynamic.xsd/EnvironmentalOccurrence/text


Requirement EnvironmentalOccurrence may have a related state transition.
Rationale Describes the state transition related to the environmental occurrence. 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).
MIF
  • mif-model-dynamic.xsd/EnvironmentalOccurrence/relatedStateTransition


Requirement State-based trigger events must reference the model being acted upon.
Rationale Required to know which information model to update.
MIF
  • mif-model-dynamic.xsd/EnvironmentalOccurrence/text

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 Each static model is bound to one or more interactions, and may 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.
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 A static model may be a choice of payload models
Rationale In some models, the payload is actually a choice of models. Used in models which bring in harmonized and/or summary data.
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


Interations

Requirement Each interaction must have a unique name
Rationale The interactions must be able to be precisely referenced esp. as part of receiver responsibilities.
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


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 include one or more sending application and receiving application.
Rationale ?.
MIF
  • mif-model-dynamic.xsd/Interaction/sendingApplication
  • mif-model-dynamic.xsd/Interaction/receivingApplication


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


Requirement Interactions have to 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 Interactions may include a use 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

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 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 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

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=28523"