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
 
(One intermediate revision by the same user not shown)
Line 129: Line 129:
 
{| 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 may have an interaction type.
 
|-
 
|-
 
| ''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
+
| 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.
 
|-
 
|-
| ''MIF''  
+
| ''Methodology''
 
|
 
|
* mif-model-dynamic.xsd/Interaction/argumentMessage
+
*Query - Solicits data from the receiver</xs:documentation>
* mif-model-dynamic.xsd/BoundStaticModel
+
*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.
{| border="2" cellspacing="0" cellpadding="3" width="600"
+
*RequestResponseRefuse - Notification of the refusal to perform the requested action (trigger event).
| '''Requirement'''
+
*UntriggeredNotification - Transmission of data that is independent of the occurrence of any state-transition event or other interaction.E.g. auto-publish, broadcast, backload
| Interactions must be able to bind to a message model or a document as the payload.
 
|-
 
| ''Rationale''
 
| There are two 'types' of static model content at HL7. RMIMs which represent workflow-type communications and Documents which represent point-in-time information.
 
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/BoundStaticModel
+
* mif-model-dynamic.xsd/Interaction/@interactionType
 
|}
 
|}
  
Line 156: Line 152:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Interaction receiver responsibilities must be supported
+
| Each interaction must identify the type of event that causes the exchange defined by the interaction to occur.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Frequently in response to an interaction, one or more 'response' interactions are triggeredThere 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.
+
| The same set of data might be exchanged for many different purposes and in many different circumstancesAgreement 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/receiverResponsiblities
 
 
|}
 
|}
  
Line 169: Line 164:
 
{| 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
+
| Each interaction must have a definition of the content allowed to be conveyed as part of the exchange defined by the interaction.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Frequently in response to an interaction, one or more 'response' interactions are triggeredThere can be multiple responses.
+
| A key part of standardizing communication is standardizing the data content to be exchanged and how that data will be structuredWithout 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/receiverResponsiblities
 
 
|}
 
|}
  
Line 182: Line 179:
 
{| 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.
+
| Interactions must be able to define the communication flow expectations on a receiver of the exchange
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Synonymous with trigger event typesSee Description above.
+
| 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 receiverThe 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.
 
|-
 
|-
| ''MIF''  
+
| ''Methodology''
|
+
|  
* mif-model-dynamic.xsd/Interaction/@interactionType
+
*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".
 
 
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| Interactions may include a use type.
 
|-
 
| ''Rationale''
 
| Identifies the type of content represented by the model when entered from the entry pointThe contentType determines whether the model is legitimate content for a classStub (binding) from another model.
 
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
+
* mif-model-dynamic.xsd/Interaction/receiverResponsiblity
 
|}
 
|}
  
Line 211: Line 200:
 
|-
 
|-
 
| ''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.
+
| 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''  
Line 224: Line 213:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Supports acknowledgements as well as query responses.
+
| 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''  
Line 237: Line 226:
 
|-
 
|-
 
| ''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.
+
| 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''  
Line 243: Line 232:
 
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent
 
* mif-model-dynamic.xsd/ReceiverResponsibly/invokingTriggerEvent
 
|}
 
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| 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===
 
===Application Roles===
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Interaction sender and receiver must have an application role.
+
| There is a need to define groupings of exchanges that systems might choose to support
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The sending and receiving application role are necessary to know which receiver responsibilities to triggerDuring a complex interaction pattern, both sending and receiving systems may trigger additional interactions based on receiver responsibilitiesTo support this, the sender and receiver are both assigned application roles which functionally describe their relation to each other in a business function.
+
| 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 uselessFor 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''  
Line 263: Line 283:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The sending and receiving application role must be able to be precisely referenced when creating interactions.
+
| There's a need to reference interactions in human-to-human communication
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 276: Line 296:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Used to build composites.
+
| 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''  
Line 289: Line 314:
 
|-
 
|-
 
| ''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.
+
| Application role is about the functional capability.  Need to document for each role what the application is capable of receiving and sending.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 300: Line 325:
 
{| 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.
+
| Each application role may either create or consume documents.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Application roles need to deal with documents as well as other static models.
+
| 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''  
Line 322: Line 347:
 
| ''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 338: Line 362:
  
  
===Static Model References===
+
===Structured Documents===
 
{| 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)
+
| HL7 v3 specifications need to support defining information structures without any accompanying dynamic model
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Documents the primary payload model as well as any parameterized stubs within the model.
+
| 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/StructuredDocument/DocumentDefinition
+
* mif-model-dynamic.xsd/StructuredDocument
 
|}
 
|}
  
Line 354: Line 378:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Structured documents may not have a dynamic model.
+
| Structured document definitions must have a unique name
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Documents are a point-in-time artifact and, as such, many times have no additional instruction to sending a document to a document repository other than to 'store' the document or a link to the document.  In this case, there is no state transition.
+
| Structured document definitions need to be referenced in human-to-human communication
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/StructuredDocument
+
* mif-model-dynamic.xsd/StructuredDocument/@name
 
|}
 
|}
  
Line 367: Line 391:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each static model must be able to be bound to one or more interactions, and to be bound to one or more other static models.
+
| Structured documents must have defined information structures
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Each interaction is bound to a specific payload model, for which is bound a specific control act wrapper model which is bound to a specific transport model.  This includes the binding to an appropriate parameter model for query interactions. The parameterized models are not bound until defining the interaction so that static models can be re-used in differing interactions to provide similar business function (acknowledgements, for example).
+
| 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/BoundStaticModel
+
* mif-model-dynamic.xsd/StructuredDocument/documentDefinition
 
|}
 
|}
  
Line 380: Line 407:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each static model has a content type.
+
| Interactions, Trigger Events, Application Roles and Structured Documents 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#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"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Naming must be driven by the binding of the static models to ensure separation of the models transparent.
+
| Static models need to be able to be combined at run-time
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Naming of each static model as bound still needs demarcation from the other model content.
+
| 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 messagesHowever, when referenced in a particular interaction, the specific message content needs to be defined
|-
 
| ''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 requiredNote this includes query requests as well as query responses.
 
 
|-
 
|-
| ''Rationale''  
+
| ''Methodology''
| The parameter list is required for both requests and responses.
+
| 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''  
 
|
 
|
 
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
 
* mif-model-dynamic.xsd/BoundStaticModel/parameterModel
* mif-model-dynamic.xsd/ParameterModel
 
|}
 
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''
 
| A parameter model is a list of passing parameters with a query request or those used to select records in a query response.  Each parameter has a parameter name and may have a traversal name.
 
|-
 
| ''Rationale''
 
| The parameter list is required for both requests and responses.  The parameter is a unique name per parameter in the same list.  The traversal name is the of the element when traversing from the association end directly to this specialized class
 
|-
 
| ''MIF''
 
|
 
* mif-model-dynamic.xsd/ParameterModel/@parameterName
 
* mif-model-dynamic.xsd/ParameterModel/@traversalName
 
 
|}
 
|}
  

Latest revision as of 16:31, 18 March 2010