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
Line 133: Line 133:
 
{| 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
+
| Each interaction may have an interaction type.
 +
|-
 +
| ''Rationale''
 +
| Synonymous with trigger event types.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/Interaction/@interactionType
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Structured documents may have annotations
 +
|-
 +
| ''Rationale''
 +
| Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
 +
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/StructuredDocument/@annotations
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Structured documents have a document definition (static model)
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| The sending and receiving application role must be able to be precisely referenced when creating interactions.
+
| Documents the primary payload model as well as any parameterized stubs within the model.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd/ApplicationRole/@name
+
* mif-model-dynamic.xsd/StructuredDocument/@DocumentDefinition
 
|}
 
|}
  
Line 153: Line 180:
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd
+
* mif-model-dynamic.xsd/BoundStaticModel/@parameterModel
 +
|}
 +
 
 +
 
 +
{| 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 this entry point.  The contentType determines whether the model is legitimate content for a classStub from another model.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/BoundStaticModel/@entryPointUseKind
 
|}
 
|}
  
Line 159: Line 199:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| For each interaction, trigger event, document, and application role, annotations must be supported:
+
| A static model may be a choice of payload models
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
| Annotations assist with usability.
+
| In some models, the payload is actually a choice of models.  Used in models which bring in harmonized and/or summary data.
 
|-
 
|-
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd
+
* mif-model-dynamic.xsd/BoundStaticModel/@specialization
 
|}
 
|}
  
Line 179: Line 219:
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
* mif-model-dynamic.xsd
+
* mif-model-dynamic.xsd/ParameterModel
 +
|}
 +
 
 +
 
 +
{| 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 one receiver responsibility.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ReceiverResponsibly/@reason
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| A receiver responsibility may have one or more 'response' interactions.
 +
|-
 +
| ''Rationale''
 +
| Supports acknowledgements as well as query responses.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ReceiverResponsibly/@invokingInteraction
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| A receiver responsibility may have one or more 'response' trigger events.
 +
|-
 +
| ''Rationale''
 +
| Indicates that the specified trigger event should be fired, along with any interactions associated with that trigger event and supported by any of the receiving system's application roles.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ReceiverResponsibly/@invokingTriggerEvent
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each application role must have a unique name
 +
|-
 +
| ''Rationale''
 +
| The sending and receiving application role must be able to be precisely referenced when creating interactions.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/@name
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Application roles may have annotations.
 +
|-
 +
| ''Rationale''
 +
| Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
 +
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/@annotations
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each application role may have related application roles.
 +
|-
 +
| ''Rationale''
 +
| Used to build composites.
 +
|-
 +
| ''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 when the application expects to receiving information and act; or sends information.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/@sendsInteractions
 +
* mif-model-dynamic.xsd/ApplicationRole/@receivesInteractions
 +
|}
 +
 
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Each application role may either create or consume a document.
 +
|-
 +
| ''Rationale''
 +
| Application roles need to deal with documents as well as other static models.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ApplicationRole/@createsDocuments
 +
* mif-model-dynamic.xsd/ApplicationRole/@consumesDocuments
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Requirement.
 +
|-
 +
| ''Rationale''
 +
| Why.
 +
|-
 +
| ''MIF''
 +
|
 +
* mif-model-dynamic.xsd/ParameterModel
 
|}
 
|}
  

Revision as of 14:39, 21 October 2009