This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Requirements-Dynamic Model"

From HL7Wiki
Jump to navigation Jump to search
Line 16: Line 16:
 
#What is expected of the receiving system (trigger event)
 
#What is expected of the receiving system (trigger event)
 
#How a receiving system knows when it has to send a particular type of response message(s) - (receiver responsibilities).
 
#How a receiving system knows when it has to send a particular type of response message(s) - (receiver responsibilities).
 +
 +
The interactions are grouped by type and each type is typified by a pattern of receiver responsibilities.
 +
*interaction-based - An interaction caused by the receipt of another interaction.  For example query response receiver responsibility.
 +
*state-based - An interaction caused by a change in status.  For example, putting a repeating order on hold (to suspend action on that order).  Receiver responsibility is usually a confirm or other acknowledgement.
 +
*user-based  - An interaction caused by a user interacting with a system or some other environmental occurrence.  Receiver responsibilities varies from a simple acknowledgement to multiple interactions (for example, lab order fulfillment).
  
 
==Requirements==
 
==Requirements==
Line 21: Line 26:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| HL7 requires a methdology and structure for both sending information as well as communicating the 'reason' information has been communicated.  The reason for the information communication are the dynamic model components.  The primary structure is the interaction (described above).
+
| HL7 requires a methodology and structure for both sending information as well as communicating the 'reason' information has been communicated.  The reason for the information communication are the dynamic model components.  The primary structure is the interaction (described above).
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
Line 64: Line 69:
 
|-
 
|-
 
| ''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.   
+
| The trigger event types communicate the 'pattern' expected as far as receiver responsibilities.  For example, and interaction-based trigger event is 'kicked off' when a triggering interaction is communicated.   
 
|-
 
|-
 
| ''Methodology''  
 
| ''Methodology''  
 
| There are three types:
 
| There are three types:
*interaction-based - An interaction caused by the receipt of another interaction.  For example query reponse.
+
*interaction-based - An interaction caused by the receipt of another interaction.  For example query response.
 
*state-based - An interaction caused by a change in status.  For example, putting a repeating order on hold (to suspend action on that order)
 
*state-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.
 
*user-based  - An interaction caused by a user interacting with a system or some other environmental occurrence.
Line 98: Line 103:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Describes the state transition related to the environmental occurrence.  A frequent example is when a user requests info to be posted to a patient's EHR (related state transition is to 'complete' an observation) and record it or to request diagnostic testing (related state transition is to 'activate' an order).
+
| Describes the state transition related to the environmental occurrence.  A state transition includes the static model, the class, and the transition.  A frequent example is when a user requests info to be posted to a patient's EHR (related state transition is to 'complete' an observation) and record it or to request diagnostic testing (related state transition is to 'activate' an order).  Trigger isn't actually the state transition but is associated with it.  E.g. a request for the transition or request for fulfilllment of a previous transition.  The triggering action is something else, but it's still useful to tie these together because of the semantic linkage.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 109: Line 114:
 
{| 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.
+
| A state transition includes the static model, the class, and the transition.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
Line 116: Line 121:
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/EnvironmentalOccurrence/text
+
* mif-model-dynamic.xsd/stateTransition
 
|}
 
|}
  
Line 135: Line 140:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| Each static model is bound to one or more interactions, and may be bound to one or more other static models.
+
| Structured documents may not have a dynamic model.
 +
|-
 +
| ''Rationale''
 +
| Documents are a point-in-time artifact and, as such, many times have no additional instruction to sending a document to a document repository other than to 'store' the document or a link to the document.  In this case, there is no state transition.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each static model must be able to be bound to one or more interactions, and to be bound to one or more other static models.
 
|-
 
|-
 
| ''Rationale''  
 
| ''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.
+
| Each interaction is bound to a specific payload model, for which is bound a specific control act wrapper model which is bound to a specific transport model.  This includes the binding to an appropriate parameter model for query interactions.  The parameterized models are not bound until defining the interaction so that static models can be re-used in differing interactions to provide similar business function (acknowledgements, for example).
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 161: Line 179:
 
{| 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
+
Naming must be driven by the binding of the static models to ensure separation of the models transparent.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| In some models, the payload is actually a choice of models.  Used in models which bring in harmonized and/or summary data.
+
| Naming of each static model as bound still needs demarcation from the other model content.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 229: Line 247:
 
{| 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.
+
| Interactions must be able to bind to a message model or a document as the payload.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
Line 242: Line 260:
 
{| 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
+
| Interaction receiver responsibilities must be supported
 
|-
 
|-
 
| ''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.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 255: Line 273:
 
{| 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 interaction may include one or more receiver responsibilities
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| ?.
+
| Frequently in response to an interaction, one or more 'response' interactions are triggered.  There can be multiple responses.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/Interaction/sendingApplication
+
* mif-model-dynamic.xsd/Interaction/receiverResponsiblities
* mif-model-dynamic.xsd/Interaction/receivingApplication
 
 
|}
 
|}
  
Line 272: Line 289:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Synonymous with trigger event types.
+
| Synonymous with trigger event types.  See Description above.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 285: Line 302:
 
|-
 
|-
 
| ''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.
+
| Identifies the type of content represented by the model when entered from the entry point.  The contentType determines whether the model is legitimate content for a classStub (binding) from another model.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
Line 298: Line 315:
 
|-
 
|-
 
| ''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 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.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  

Revision as of 22:55, 10 November 2009