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
 
(49 intermediate revisions by 2 users not shown)
Line 4: Line 4:
 
</div>
 
</div>
  
−
==Dynamic Model Components==
+
===Description===
−
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 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?
 +
* [[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?
  
 +
==Requirements==
 +
===Trigger Events===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
−
| '''Term'''  
+
| '''Requirement'''  
−
| '''Definition'''
+
| 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.
 
|-
 
|-
−
| Interaction
+
| ''Rationale''
−
| 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.
+
| 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.
 
|-
 
|-
−
| Application Role
+
| ''MIF''
−
| 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.
+
| mif-model-dynamic.xsd/TriggerEvent
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each trigger event must have a unique name
 
|-
 
|-
−
| Trigger Event
+
| ''Rationale''
−
| reason or action why information is exchanged ; one and only one action to perform
+
| The trigger events must be able to be precisely referenced in human-to-human communication.
 
|-
 
|-
−
| Receiver Responsibilities
+
| ''MIF''
−
| Identifies a possible set of actions to be taken in response to the receipt of an interaction
+
|
 +
* mif-model-dynamic.xsd/TriggerEvent/@name
 
|}
 
|}
  
−
===Interaction===
 
−
Interactions are at the heart of messaging. The formal definition of an interaction is:
 
  
−
A unique association between a specific message type (information transfer), 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.  
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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
 +
|}
  
−
A single Interaction explicitly answers the questions:
 
  
−
1.What the particular message type is
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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
  
−
2.What caused the message to be sent
+
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)
  
−
3.How a receiving system knows when it has to send a particular type of response message.
+
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
 +
|}
  
−
As the list above indicates, each interaction is related to a trigger event, a message type and receiver responsibilities. In the Version 3 specification, the Interactions are presented with a name, the artifact ID, and a table that lists the sending and receiving application roles, the trigger event, the message type, the Event type and the Wrapper types. The sending and receiving application roles as well as the event type are listed in the Version 3 specification for information only
 
  
−
The Event type is the Trigger Event type. Valid values are interaction-based, state-transition based, user-based or unspecified.
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Trigger Events may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 +
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 +
* [[Requirements-Annotations#Rationale|Rationale]]
 +
* [[Requirements-Annotations#Requirements|Requirements]]
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Mapping|Mapping]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|}
  
−
The Wrapper types refer to the Transmission Wrapper and the Trigger Event Control Act Wrapper. The Trigger Event Control Act wrapper is a conditional wrapper which contains domain specific administrative information related to that which triggered the interaction. This type of wrapper does not appear with HL7 messages where there is no additional context that is needed to be exchanged dynamically, or with HL7 messages that are carrying commands to coordinate the operation of message handling services.
 
  
−
===Trigger Event===
+
===Interations===
−
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.  
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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
 +
|}
  
−
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:
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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
 +
|}
  
−
{| border="2" cellspacing="0" cellpadding="3" width="500"
+
 
−
| '''Type'''  
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
−
| '''Description'''
+
| '''Requirement'''  
 +
| Each interaction may have an interaction type.
 
|-
 
|-
−
| ''Interaction-Based''  
+
| ''Rationale''  
−
| 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.
+
| Interactions typically fall into one of a set of stereotypical behaviors. Each of these stereotypes have distinct expectations for the types of trigger events and receiver responsibilities associated with them.
 
|-
 
|-
−
| ''State-Based''  
+
| ''Methodology''
−
| 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
+
|
 +
*Query - Solicits data from the receiver</xs:documentation>
 +
*QueryResponse - Returns requested data to the query initiator, or an indication that requested data is unavailable.</xs:documentation>
 +
*EventNotification - Informs the receiver about the occurrence of a trigger event, along with full or partial data related to that trigger event.
 +
*RequestForAction - Solicits a specific action (trigger event) from the receiver.  Must be an action the receiving Role is theoretically capable of performing.
 +
*RequestResponseAccept - Notification of the agreement or conditional agreement to perform the requested action (trigger event) or a varient thereof.  I.e. the accept may propose an alternative to the initial request.
 +
*RequestResponseRefuse - Notification of the refusal to perform the requested action (trigger event).
 +
*UntriggeredNotification - Transmission of data that is independent of the occurrence of any state-transition event or other interaction.E.g. auto-publish, broadcast, backload
 
|-
 
|-
−
| ''User Action''  
+
| ''MIF''  
−
| 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.  
+
|
 +
* mif-model-dynamic.xsd/Interaction/@interactionType
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each interaction must identify the type of event that causes the exchange defined by the interaction to occur.
 +
|-
 +
| ''Rationale''
 +
| The same set of data might be exchanged for many different purposes and in many different circumstances.  Agreement on a specific reason for a given exchange is important to shared interpretation of the information. For example, a structure defining a prescription might be sent when asking for the prescription to be created in some central system, when asking a pharmacy to fill the prescription, or as a response to a query.  The same data is sent, but the triggering event (and thus the semantic interpretation of the information and what internal business process should be invoked) is different.
 
|-
 
|-
−
| ''Unspecified''  
+
| ''MIF''  
−
| Trigger events that don't fall into one of the other categories
+
| mif-model-dynamic.xsd/Interaction/invokingTriggerEvent
 
|}
 
|}
  
−
Most trigger events are State-Transition based and will be encountered when reading the dynamic message model (state diagram) 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.
 
  
−
===State Machine===
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
−
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.  
+
| '''Requirement'''
 +
| Each interaction must have a definition of the content allowed to be conveyed as part of the exchange defined by the interaction.
 +
|-
 +
| ''Rationale''
 +
| A key part of standardizing communication is standardizing the data content to be exchanged and how that data will be structured. Without knowledge of the data to be conveyed, interoperability cannot be achieved.
 +
|-
 +
| ''Methodology''
 +
| Refer to [[Requirements-Dynamic Model#Bound Models|Bound Models]]
 +
|-
 +
| ''MIF''
 +
| mif-model-dynamic.xsd/Interaction/argumentMessage
 +
|}
  
−
[[Image:RIM_ActStatus.gif|800px]]
 
  
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Interactions must be able to define the communication flow expectations on a receiver of the exchange
 +
|-
 +
| ''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.  In other cases, there is an expectation that an "event" will occur within the receiving system that will result in additional communications.
 +
|-
 +
| ''Methodology''
 +
|
 +
*HL7 does not standardize the 'internal' behavior of applications as that is outside the scope of the organization's mandate.  However, behavior around expressed communications is part of interoperability and is therefore defined.
 +
* Receiver responsibilities are defined as a set of 0..* mutually exclusive alternatives.  The receiver is expected to perform one and only one of the listed set of responsibilities.  (It is possible for a defined responsibility to be "do nothing".
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/Interaction/receiverResponsiblity
 +
|}
  
−
===Class Diagram using UML===
+
===Receiver Responsibilities===
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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.  This set of conditions ensures that the allowed communication behavior of the receiver is fully defined.  For example, one responsibility might be invoked if a request is accepted, another if the request is not accepted but an alternative is proposed, and a third responsibility invoked in all other circumstances.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ReceiverResponsibly/reason
 +
|}
  
−
[[Image:RIM_ActStatus.gif|800px]]
 
  
−
===Requirements===
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| An interaction binds one trigger event, one payload model, one control act wrapper, one transport wrapper, a sending application role, a receiving application role, and one or more receiver responsibilities.  
+
| A receiver responsibility may have one or more 'response' interactions.
 +
|-
 +
| ''Rationale''
 +
| A common pattern of communications is to send some sort of response when a piece of information has been received.  This type of receiver responsibility allows interactions to be chained together.  Supports acknowledgements as well as query responses.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingInteraction
 +
|}
  
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| A receiver responsibility may have one or more 'response' trigger events.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| ??.
+
| Some interactions may result in a defined "real world event" occurring in the receiving application. For example, if a request for fulfillment of an order is 'accepted', there may be a requirement that the receiver 'activate' a 'Promise' object.  That trigger event would then fire all interactions having that state transition as the initiating trigger event
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
−
* mif-model-dynamic.xsd
+
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent
 
|}
 
|}
 +
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| An interaction binds one trigger event, one payload model, one control act wrapper, one transport wrapper, a sending application role, a receiving application role, and one or more receiver responsibilities.
+
| Interactions may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 +
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 +
* [[Requirements-Annotations#Rationale|Rationale]]
 +
* [[Requirements-Annotations#Requirements|Requirements]]
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Mapping|Mapping]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Static Example|Static Example]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|}
  
 +
 +
===Application Roles===
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| There is a need to define groupings of exchanges that systems might choose to support
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| ??.
+
| Applications that choose to implement random combinations of interactions will not interoperate. For example, a system that can send a query but cannot receive the response is useless.  For true interoperability there needs to be a collection of interactions defined that a particular system can send and/or receive.  That application would then be able to communicate with any system that supports the paired grouping.
 +
 
 +
Application roles serve many purposes:
 +
* They can be the foundation for formal specifications and RFPs
 +
* They provide an idea of desired/expected behavior
 +
* They form a foundation for conformance testing
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
−
* mif-model-dynamic.xsd
+
* mif-model-dynamic.xsd/ApplicationRole
 
|}
 
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each application role must have a unique name
 +
|-
 +
| ''Rationale''
 +
| There's a need to reference interactions in human-to-human communication
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/@name
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each application role may have related application roles.
 +
|-
 +
| ''Rationale''
 +
| When defining conformance structures, it's useful to allow composition of common combinations into more complex structures.  For example a "Pharmacy system" application role might be composed of "Prescription filler", "Dispense notifier", "Medication profile querier" and similar roles.
 +
|-
 +
| ''Methodology''
 +
| Two types of composition are defined:
 +
*AtLeastOne - The container application role must implement at least one, possibly more (including all) contained application roles.
 +
*Includes - Defines the relationship where the container contains the contents.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/relatedApplicationRoles
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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 what the application is capable of receiving and sending.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/sendsInteractions
 +
* mif-model-dynamic.xsd/ApplicationRole/receivesInteractions
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each application role may either create or consume documents.
 +
|-
 +
| ''Rationale''
 +
| In addition to sending and receiving messages (services), applications may also create and consume documents, which don't have an associated dynamic model.  This capability also needs to be bound into the definition of a system's characteristics.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/createsDocuments
 +
* mif-model-dynamic.xsd/ApplicationRole/consumesDocuments
 +
|}
 +
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 +
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 +
* [[Requirements-Annotations#Rationale|Rationale]]
 +
* [[Requirements-Annotations#Requirements|Requirements]]
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Mapping|Mapping]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|}
 +
 +
 +
===Structured Documents===
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| HL7 v3 specifications need to support defining information structures without any accompanying dynamic model
 +
|-
 +
| ''Rationale''
 +
| Some standards do not involve any behavioral aspects.  The definitions of any behavior are outside the scope of the standard.  While this may reduce chances of interoperability, it does allow for increased flexibility on the usage of the standard
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Structured document definitions must have a unique name
 +
|-
 +
| ''Rationale''
 +
| Structured document definitions need to be referenced in human-to-human communication
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument/@name
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Structured documents must have defined information structures
 +
|-
 +
| ''Rationale''
 +
| Seeing as there's no dynamic model, the only thing left to standardize is the data content and structure.
 +
|-
 +
| ''Methodology''
 +
| Refer to [[Requirements-Dynamic Model#Bound Models|Bound Models]]
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument/documentDefinition
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 +
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 +
* [[Requirements-Annotations#Rationale|Rationale]]
 +
* [[Requirements-Annotations#Requirements|Requirements]]
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Mapping|Mapping]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|}
 +
 +
 +
===Bound Models===
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Static models need to be able to be combined at run-time
 +
|-
 +
| ''Rationale''
 +
| Sometimes static models need to be constructed in such a way that they have associations that point to variable "un-defined" content.  Before the model can be used, these "stub" locations need to be resolved.  For example, a model that defines the transport information for a message might be capable of conveying many types of messages.  However, when referenced in a particular interaction, the specific message content needs to be defined
 +
|-
 +
| ''Methodology''
 +
| HL7 models can contain named stubs or "template parameters" [To do: insert reference].  These parameters are then bound to other static models when the static model is referenced in a document or interaction definition.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
 +
|}
 +
 +
 +
===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.
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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
 +
|}
 +
 
</div>
 
</div>
 
[[Category:V3 Methodology Requirements]]
 
[[Category:V3 Methodology Requirements]]

Latest revision as of 16:31, 18 March 2010

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 may have an interaction type.
Rationale Interactions typically fall into one of a set of stereotypical behaviors. Each of these stereotypes have distinct expectations for the types of trigger events and receiver responsibilities associated with them.
Methodology
  • Query - Solicits data from the receiver</xs:documentation>
  • QueryResponse - Returns requested data to the query initiator, or an indication that requested data is unavailable.</xs:documentation>
  • EventNotification - Informs the receiver about the occurrence of a trigger event, along with full or partial data related to that trigger event.
  • RequestForAction - Solicits a specific action (trigger event) from the receiver. Must be an action the receiving Role is theoretically capable of performing.
  • RequestResponseAccept - Notification of the agreement or conditional agreement to perform the requested action (trigger event) or a varient thereof. I.e. the accept may propose an alternative to the initial request.
  • RequestResponseRefuse - Notification of the refusal to perform the requested action (trigger event).
  • UntriggeredNotification - Transmission of data that is independent of the occurrence of any state-transition event or other interaction.E.g. auto-publish, broadcast, backload
MIF
  • mif-model-dynamic.xsd/Interaction/@interactionType


Requirement Each interaction must identify the type of event that causes the exchange defined by the interaction to occur.
Rationale The same set of data might be exchanged for many different purposes and in many different circumstances. Agreement on a specific reason for a given exchange is important to shared interpretation of the information. For example, a structure defining a prescription might be sent when asking for the prescription to be created in some central system, when asking a pharmacy to fill the prescription, or as a response to a query. The same data is sent, but the triggering event (and thus the semantic interpretation of the information and what internal business process should be invoked) is different.
MIF mif-model-dynamic.xsd/Interaction/invokingTriggerEvent


Requirement Each interaction must have a definition of the content allowed to be conveyed as part of the exchange defined by the interaction.
Rationale A key part of standardizing communication is standardizing the data content to be exchanged and how that data will be structured. Without knowledge of the data to be conveyed, interoperability cannot be achieved.
Methodology Refer to Bound Models
MIF mif-model-dynamic.xsd/Interaction/argumentMessage


Requirement Interactions must be able to define the communication flow expectations on a receiver of the exchange
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. In other cases, there is an expectation that an "event" will occur within the receiving system that will result in additional communications.
Methodology
  • HL7 does not standardize the 'internal' behavior of applications as that is outside the scope of the organization's mandate. However, behavior around expressed communications is part of interoperability and is therefore defined.
  • Receiver responsibilities are defined as a set of 0..* mutually exclusive alternatives. The receiver is expected to perform one and only one of the listed set of responsibilities. (It is possible for a defined responsibility to be "do nothing".
MIF
  • mif-model-dynamic.xsd/Interaction/receiverResponsiblity

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. This set of conditions ensures that the allowed communication behavior of the receiver is fully defined. For example, one responsibility might be invoked if a request is accepted, another if the request is not accepted but an alternative is proposed, and a third responsibility invoked in all other circumstances.
MIF
  • mif-model-dynamic.xsd/ReceiverResponsibly/reason


Requirement A receiver responsibility may have one or more 'response' interactions.
Rationale A common pattern of communications is to send some sort of response when a piece of information has been received. This type of receiver responsibility allows interactions to be chained together. 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 Some interactions may result in a defined "real world event" occurring in the receiving application. For example, if a request for fulfillment of an order is 'accepted', there may be a requirement that the receiver 'activate' a 'Promise' object. That trigger event would then fire all interactions having that state transition as the initiating trigger event
MIF
  • mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent


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


Application Roles

Requirement There is a need to define groupings of exchanges that systems might choose to support
Rationale Applications that choose to implement random combinations of interactions will not interoperate. For example, a system that can send a query but cannot receive the response is useless. For true interoperability there needs to be a collection of interactions defined that a particular system can send and/or receive. That application would then be able to communicate with any system that supports the paired grouping.

Application roles serve many purposes:

  • They can be the foundation for formal specifications and RFPs
  • They provide an idea of desired/expected behavior
  • They form a foundation for conformance testing
MIF
  • mif-model-dynamic.xsd/ApplicationRole


Requirement Each application role must have a unique name
Rationale There's a need to reference interactions in human-to-human communication
MIF
  • mif-model-dynamic.xsd/ApplicationRole/@name


Requirement Each application role may have related application roles.
Rationale When defining conformance structures, it's useful to allow composition of common combinations into more complex structures. For example a "Pharmacy system" application role might be composed of "Prescription filler", "Dispense notifier", "Medication profile querier" and similar roles.
Methodology Two types of composition are defined:
  • AtLeastOne - The container application role must implement at least one, possibly more (including all) contained application roles.
  • Includes - Defines the relationship where the container contains the contents.
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 what the application is capable of receiving and sending.
MIF
  • mif-model-dynamic.xsd/ApplicationRole/sendsInteractions
  • mif-model-dynamic.xsd/ApplicationRole/receivesInteractions


Requirement Each application role may either create or consume documents.
Rationale In addition to sending and receiving messages (services), applications may also create and consume documents, which don't have an associated dynamic model. This capability also needs to be bound into the definition of a system's characteristics.
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


Structured Documents

Requirement HL7 v3 specifications need to support defining information structures without any accompanying dynamic model
Rationale Some standards do not involve any behavioral aspects. The definitions of any behavior are outside the scope of the standard. While this may reduce chances of interoperability, it does allow for increased flexibility on the usage of the standard
MIF
  • mif-model-dynamic.xsd/StructuredDocument


Requirement Structured document definitions must have a unique name
Rationale Structured document definitions need to be referenced in human-to-human communication
MIF
  • mif-model-dynamic.xsd/StructuredDocument/@name


Requirement Structured documents must have defined information structures
Rationale Seeing as there's no dynamic model, the only thing left to standardize is the data content and structure.
Methodology Refer to Bound Models
MIF
  • mif-model-dynamic.xsd/StructuredDocument/documentDefinition


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


Bound Models

Requirement Static models need to be able to be combined at run-time
Rationale Sometimes static models need to be constructed in such a way that they have associations that point to variable "un-defined" content. Before the model can be used, these "stub" locations need to be resolved. For example, a model that defines the transport information for a message might be capable of conveying many types of messages. However, when referenced in a particular interaction, the specific message content needs to be defined
Methodology HL7 models can contain named stubs or "template parameters" [To do: insert reference]. These parameters are then bound to other static models when the static model is referenced in a document or interaction definition.
MIF
  • mif-model-dynamic.xsd/BoundStaticModel/parameterModel


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