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
 
(17 intermediate revisions by 2 users not shown)
Line 5: Line 5:
  
 
===Description===
 
===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 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 specificationThe artifacts include:
 
+
* [[Requirements-Dynamic Model#Trigger Events|Trigger Events]]: When is information exchanged?
The core of the HL7 dynamic model is the interactionA 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:  
 
1.What the particular message type is (static model which may be a document, a external addressing (transport) wrapper, and an 'action' wrapper.
 
2.What caused the message to be sent (triggering event)
 
3.What is expected of the receiving system (trigger event)
 
3.How a receiving system knows when it has to send a particular type of response message(s) - (receiver responsibilities).
 
  
 
==Requirements==
 
==Requirements==
===Dynamic Model===
+
===Trigger Events===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| HL7 requires a structure for the dynamic model components.  The primary structure is the interaction (described above).
+
| 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''  
| A formal structure is needed to produce formalized, harmonized standards.
+
| 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/Interaction
 
 
|}
 
|}
  
===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
+
| Each trigger event must have a unique name
 
|-
 
|-
 
| ''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.
+
| The trigger events must be able to be precisely referenced in human-to-human communication.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/TriggerEvent
+
* mif-model-dynamic.xsd/TriggerEvent/@name
* mif-model-dynamic.xsd/Interaction/invokingTriggerEvent
 
 
|}
 
|}
  
Line 48: Line 39:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each trigger event must have a unique name
+
| Each trigger event must identify, as formally as possible, the real-world occurrence that causes information to flow.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The trigger events must be able to be precisely referenced when creating interactionsThe trigger event is the reason for communicating information.
+
| 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''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/TriggerEvent/@name
+
* 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
 
|}
 
|}
  
Line 61: Line 60:
 
{| 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.
+
| EnvironmentalOccurrence may have a related state transition.
 
|-
 
|-
 
| ''Rationale''  
 
| ''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.   
+
| 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
| ''Methodology''
+
* Request for fulfillment of a state transition
| There are three types:
+
 
*interaction-based - An interaction caused by the receipt of another interaction.  For example query reponse.
+
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)
*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.
+
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''  
 
|
 
|
* Interaction-based: mif-model-dynamic.xsd/TriggeringEvent/interaction
+
* mif-model-dynamic.xsd/EnvironmentalOccurrence/relatedStateTransition
* State-based:  mif-model-dynamic.xsd/TriggeringEvent/stateTransition
 
* User-based:  mif-model-dynamic.xsd/TriggeringEvent/environmentalOccurrence
 
 
|}
 
|}
  
Line 82: Line 79:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| EnvironmentalOccurrence may have associated text.
+
| Trigger Events may have a number of different types of annotations
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Describes the nature of the environmental occurrence (e.g. user action)
+
| See rationales for individual annotations types
 
|-
 
|-
| ''MIF''  
+
| ''Implementation''  
|
+
|  
* mif-model-dynamic.xsd/EnvironmentalOccurrence/text
+
* [[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]]
 
|}
 
|}
  
  
 +
===Interations===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| EnvironmentalOccurrence may have a related state transition.
+
| 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''  
 
| ''Rationale''  
| Describes the state transition related to the environmental occurrenceA 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).
+
| A single exchange is the lowest possible unit of actual interoperabilityWhile 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/EnvironmentalOccurrence/relatedStateTransition
 
 
|}
 
|}
 
  
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| State-based trigger events must reference the model being acted upon.
+
| Each interaction must have a unique name
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Required to know which information model to update.
+
| Interactions must be able to be referenced in human communication
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/EnvironmentalOccurrence/text
+
* mif-model-dynamic.xsd/Interaction/@name
 
|}
 
|}
  
===Static Model References===
+
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Structured documents have a document definition (static model)
+
| Each interaction may have an interaction type.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Documents the primary payload model as well as any parameterized stubs within the model.
+
| 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''  
 
|
 
|
* mif-model-dynamic.xsd/StructuredDocument/@DocumentDefinition
+
* mif-model-dynamic.xsd/Interaction/@interactionType
 
|}
 
|}
  
  
 
 
===Interations===
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each interaction must have a unique name
+
| Each interaction must identify the type of event that causes the exchange defined by the interaction to occur.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The interactions must be able to be precisely referenced esp. as part of receiver responsibilities.
+
| 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''  
|
+
| mif-model-dynamic.xsd/Interaction/invokingTriggerEvent
* mif-model-dynamic.xsd/Interaction/@name
 
 
|}
 
|}
  
Line 151: Line 164:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''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).
+
| Each interaction must have a definition of the content allowed to be conveyed as part of the exchange defined by the interaction.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The interactions must be able to be precisely referenced esp. as part of receiver responsibilities. Also, the receiving system needs to kn ow
+
| 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''  
|
+
| mif-model-dynamic.xsd/Interaction/argumentMessage
* mif-model-dynamic.xsd/Interaction/argumentMessage
 
 
|}
 
|}
  
Line 164: Line 179:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each interaction may include one or more receiver responsibilities
+
| Interactions must be able to define the communication flow expectations on a receiver of the exchange
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Frequently in response to an interaction, one or more 'response' interactions are triggered.  There can be multiple responses.
+
| 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''  
 
|
 
|
* mif-model-dynamic.xsd/Interaction/receiverResponsiblities
+
* mif-model-dynamic.xsd/Interaction/receiverResponsiblity
 
|}
 
|}
  
 
+
===Receiver Responsibilities===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each interaction may include one or more sending application and receiving application.
+
| Each receiver responsibility must have a reason.
 
|-
 
|-
 
| ''Rationale''  
 
| ''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''  
 
|
 
|
* mif-model-dynamic.xsd/Interaction/sendingApplication
+
* mif-model-dynamic.xsd/ReceiverResponsibly/reason
* mif-model-dynamic.xsd/Interaction/receivingApplication
 
 
|}
 
|}
  
Line 191: Line 210:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each interaction may have an interaction type.
+
| A receiver responsibility may have one or more 'response' interactions.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Synonymous with trigger event types.
+
| 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''  
 
|
 
|
* mif-model-dynamic.xsd/Interaction/@interactionType
+
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingInteraction
 
|}
 
|}
  
Line 204: Line 223:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Interactions have to be able to bind to a message model or a document as the payload.
+
| A receiver responsibility may have one or more 'response' trigger events.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| There are two 'types' of static model content at HL7RMIMs which represent workflow-type communications and Documents which represent point-in-time information.
+
| 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' objectThat trigger event would then fire all interactions having that state transition as the initiating trigger event
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
+
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent
 
|}
 
|}
  
Line 217: Line 236:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Interactions may include a use type.
+
| Interactions may have a number of different types of annotations
 
|-
 
|-
 
| ''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.
+
| See rationales for individual annotations types
 
|-
 
|-
| ''MIF''  
+
| ''Implementation''  
|
+
|  
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
+
* [[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"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| A static model may be a choice of payload models
+
| There is a need to define groupings of exchanges that systems might choose to support
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| In some models, the payload is actually a choice of modelsUsed in models which bring in harmonized and/or summary data.
+
| 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 receiveThat 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/BoundStaticModel/specialization
+
* mif-model-dynamic.xsd/ApplicationRole
 
|}
 
|}
  
Line 243: Line 280:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| For each query interaction, an additional binding to the parameter list is required.  Note this includes query requests as well as query responses.
+
| Each application role must have a unique name
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The parameter list is required for both requests and responses.
+
| There's a need to reference interactions in human-to-human communication
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/ParameterModel
+
* mif-model-dynamic.xsd/ApplicationRole/@name
 
|}
 
|}
  
  
===Receiver Responsibilities===
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each receiver responsibility must have a reason.
+
| Each application role may have related application roles.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Indicates the conditions under which this receiver responsibility should be chosenShould 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.
+
| When defining conformance structures, it's useful to allow composition of common combinations into more complex structuresFor 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''  
 
|
 
|
* mif-model-dynamic.xsd/ReceiverResponsibly/reason
+
* mif-model-dynamic.xsd/ApplicationRole/relatedApplicationRoles
 
|}
 
|}
  
Line 270: Line 311:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| A receiver responsibility may have one or more 'response' interactions.
+
| Each application role may be either or both sending interactions and/or receiving interactions.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Supports acknowledgements as well as query responses.
+
| Application role is about the functional capability.  Need to document for each role what the application is capable of receiving and sending.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/ReceiverResponsibly/@invokingInteraction
+
* mif-model-dynamic.xsd/ApplicationRole/sendsInteractions
 +
* mif-model-dynamic.xsd/ApplicationRole/receivesInteractions
 
|}
 
|}
  
Line 283: Line 325:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| A receiver responsibility may have one or more 'response' trigger events.
+
| Each application role may either create or consume documents.
 
|-
 
|-
 
| ''Rationale''  
 
| ''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.
+
| 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''  
 
|
 
|
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent
+
* mif-model-dynamic.xsd/ApplicationRole/createsDocuments
 +
* mif-model-dynamic.xsd/ApplicationRole/consumesDocuments
 
|}
 
|}
  
  
===Application Roles===
+
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each application role must have a unique name
+
| Interactions, Trigger Events, Application Roles and Structured Documents may have a number of different types of annotations
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The sending and receiving application role must be able to be precisely referenced when creating interactions.
+
| See rationales for individual annotations types
 
|-
 
|-
| ''MIF''  
+
| ''Implementation''  
|
+
|  
* mif-model-dynamic.xsd/ApplicationRole/@name
+
* [[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"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each application role may have related application roles.
+
| HL7 v3 specifications need to support defining information structures without any accompanying dynamic model
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Used to build composites.
+
| 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''  
 
|
 
|
* mif-model-dynamic.xsd/ApplicationRole/relatedApplicationRoles
+
* mif-model-dynamic.xsd/StructuredDocument
 
|}
 
|}
  
Line 323: Line 378:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each application role may be either or both sending interactions and/or receiving interactions.
+
| Structured document definitions must have a unique name
 
|-
 
|-
 
| ''Rationale''  
 
| ''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.
+
| Structured document definitions need to be referenced in human-to-human communication
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/ApplicationRole/sendsInteractions
+
* mif-model-dynamic.xsd/StructuredDocument/@name
* mif-model-dynamic.xsd/ApplicationRole/receivesInteractions
 
 
|}
 
|}
  
Line 337: Line 391:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each application role may either create or consume a document.
+
| Structured documents must have defined information structures
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Application roles need to deal with documents as well as other static models.
+
| 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''  
 
|
 
|
* mif-model-dynamic.xsd/ApplicationRole/createsDocuments
+
* mif-model-dynamic.xsd/StructuredDocument/documentDefinition
* mif-model-dynamic.xsd/ApplicationRole/consumesDocuments
 
 
|}
 
|}
 
  
  
Line 359: Line 414:
 
| ''Implementation''  
 
| ''Implementation''  
 
|  
 
|  
* [[Requirements-Annotations#Definition|Description]]
 
 
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
Line 373: Line 427:
 
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 
* [[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)===
 
===Future Requirements (not complete)===

Latest revision as of 16:31, 18 March 2010