This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Requirements-Static Model"

From HL7Wiki
Jump to navigation Jump to search
 
(14 intermediate revisions by 2 users not shown)
Line 17: Line 17:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase
 
| mif-model-staticBase.xsd/ClassBase
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}}UML Class
 
|}
 
|}
  
Line 32: Line 35:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/AssociationBase
 
| mif-model-staticBase.xsd/AssociationBase
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}}UML Association
 
|}
 
|}
  
Line 47: Line 53:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassGeneralizationBase
 
| mif-model-staticBase.xsd/ClassGeneralizationBase
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} This could be modeled in the same way in UML, with a stereotype specifically indicating that a choice is being modeled.
 
|}
 
|}
  
Line 61: Line 70:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/@isSerializable
 
| mif-model-staticBase.xsd/StaticModelBase/@isSerializable
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} This could be indicated using an HL7 stereotype. Note, however, that all MOF-based models are serializable using XMI.
 
|}
 
|}
  
Line 73: Line 85:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticDerived.xsd/derivedStaticModel
 
| mif-model-staticDerived.xsd/derivedStaticModel
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-Model Management}}
 
|}
 
|}
  
Line 85: Line 100:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/@representationKind
 
| mif-model-staticBase.xsd/StaticModelBase/@representationKind
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-Tool}}
 
|}
 
|}
  
Line 103: Line 121:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/@conformanceLevel
 
| mif-model-staticBase.xsd/StaticModelBase/@conformanceLevel
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} An appropriate HL7 stereotype could have a tag indicating the conformance context.
 
|}
 
|}
  
Line 115: Line 136:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/@isAbstract
 
| mif-model-staticBase.xsd/StaticModelBase/@isAbstract
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} An HL7 model stereotype could have a tag for this.
 
|}
 
|}
−
 
−
 
−
TODO
 
  
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Static models must be able to be represented graphically and be able to have that graphical representation persisted.
+
| Static Models may have a number of different types of annotations
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Graphical representation has been found essential to enabling quick communication and understanding of model content.  I.e. "A picture is worth 1000 words". 
+
| See rationales for individual annotations types
 
|-
 
|-
−
| '' MIF''  
+
| ''Implementation''  
 
|  
 
|  
−
*mif-model-staticBase.xsd/StaticModelBase/graphicRepresentation
+
* [[Requirements-Annotations#Definition|Description]]
−
*mif-model-staticBase.xsd/StaticModelBase/figure
+
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
−
|}
+
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
−
 
+
* [[Requirements-Annotations#Rationale|Rationale]]
−
 
+
* [[Requirements-Annotations#Requirements|Requirements]]
−
TODO
+
* [[Requirements-Annotations#Design Comments|Design Comments]]
−
 
+
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
−
 
+
* [[Requirements-Annotations#Walkthrough|Walkthrough]]
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
+
* [[Requirements-Annotations#Appendix|Appendix]]
−
| '''Requirement'''
+
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
−
| Static models must be able to identify the other artifacts they are based on.
+
* [[Requirements-Annotations#Mapping|Mapping]]
−
|-
+
* [[Requirements-Annotations#Open Issue|Open Issue]]
−
| ''Rationale''
+
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
−
| Static models depend on datatypes and vocabulary and potentially interface packages and/or annotation libraries .  If someone reviewing a model doesn't have access to the same versions of these artifacts that were consulted in constructing the model, they will not be able to understand the content within the model and may even misinterpret the model.
+
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 
|-
 
|-
−
| '' MIF''  
+
| ''OMG Mapping''
−
|  
+
| {{OMG-MIF-HL7 Profile}} An HL7 model stereotype could have tags for these.
−
*mif-model-staticBase.xsd/StaticModelBase/importedDatatypeModelPackage
 
−
*mif-model-staticBase.xsd/StaticModelBase/importedVocabularyModelPackage
 
−
*mif-model-staticBase.xsd/StaticModelBase/importedInterfacePackage
 
−
*mif-model-staticBase.xsd/StaticModelBase/importedAnnotationLibrary
 
 
|}
 
|}
  
Line 156: Line 174:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Static models must be able to identify the other artifacts they are based on.
+
| Static models must be able to be represented graphically and be able to have that graphical representation persisted.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Static models depend on datatypes and vocabulary and potentially interface packages and/or annotation libraries .   
+
| Graphical representation has been found essential to enabling quick communication and understanding of model content.  I.e. "A picture is worth 1000 words".   
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
Line 165: Line 183:
 
*mif-model-staticBase.xsd/StaticModelBase/graphicRepresentation
 
*mif-model-staticBase.xsd/StaticModelBase/graphicRepresentation
 
*mif-model-staticBase.xsd/StaticModelBase/figure
 
*mif-model-staticBase.xsd/StaticModelBase/figure
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} UML is a graphical notation.
 
|}
 
|}
  
Line 181: Line 202:
 
*mif-model-staticBase.xsd/StaticModelBase/importedInterfacePackage
 
*mif-model-staticBase.xsd/StaticModelBase/importedInterfacePackage
 
*mif-model-staticBase.xsd/StaticModelBase/importedAnnotationLibrary
 
*mif-model-staticBase.xsd/StaticModelBase/importedAnnotationLibrary
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} UML already provides for importing of packages. However, such importation is necessary only to make names within the imported package visible without qualification -- it is allowable to reference elements within a package without importing it. Nevertheless, stereotyped UML import relationships could be used to represent the above HL7 dependencies.
 
|}
 
|}
  
Line 193: Line 217:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/additionalDatatypeModel
 
| mif-model-staticBase.xsd/StaticModelBase/additionalDatatypeModel
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} UML allows for the modeling of new data types, which could be stereotyped as appropriate for HL7. [This may need further discussion depending on a deeper review of the HL7 Datatype Flavor concept.]
 
|}
 
|}
  
Line 201: Line 228:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| In some circumstances a valueset or other vocabulary artifact may be specific to a particular static model rather than being generically defined and applicable to a variety of static models.  In these circumstances the vocabulary structures may need to be defined within the model that uses them.  (The alternative would be having 1..1 supplemental models maintained separately which would be a maintenance nightmare.
+
| In some circumstances a valueset or other vocabulary artifact may be specific to a particular static model rather than being generically defined and applicable to a variety of static models.  In these circumstances the vocabulary structures may need to be defined within the model that uses them.  (The alternative would be having 1..1 supplemental models maintained separately which would be a maintenance nightmare.)
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/additionalVocabularyModel
 
| mif-model-staticBase.xsd/StaticModelBase/additionalVocabularyModel
−
|}
 
−
 
−
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| Static models must be able to identify supplemental vocabulary information, particularly value sets, defined locally.
 
−
|-
 
−
| ''Rationale''
 
−
| In some circumstances a valueset or other vocabulary artifact may be specific to a particular static model rather than being generically defined and applicable to a variety of static models.  In these circumstances the vocabulary structures may need to be defined within the model that uses them.  (The alternative would be having 1..1 supplemental models maintained separately which would be a maintenance nightmare.
 
 
|-
 
|-
−
| '' MIF''  
+
| ''OMG Mapping''
−
| mif-model-staticBase.xsd/StaticModelBase/additionalVocabularyModel
+
| [Depends on the OMG Mapping for vocabulary models.]
 
|}
 
|}
  
Line 229: Line 247:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/vocabularyGuidance
 
| mif-model-staticBase.xsd/StaticModelBase/vocabularyGuidance
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} [Needs a deeper review of the HL7 concept of "vocabulary guidance".]
 
|}
 
|}
  
Line 241: Line 262:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/subjectAreaPackage
 
| mif-model-staticBase.xsd/StaticModelBase/subjectAreaPackage
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} UML Package [But would a stereotype be appropriate?]
 
|}
 
|}
  
Line 249: Line 273:
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Some static models, generally templates, are constructed to give concrete representation to a clinical concept from one or more code systems.  For example, "blood pressue".  When a model has been constructed for this purpose, it needs to be able to identify what code(s) it is representing.
+
| Some static models, generally templates, are constructed to give concrete representation to a clinical concept from one or more code systems.  For example, "blood pressure".  When a model has been constructed for this purpose, it needs to be able to identify what code(s) it is representing.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/StaticModelBase/definitionalCode
 
| mif-model-staticBase.xsd/StaticModelBase/definitionalCode
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}}
 
|}
 
|}
−
 
  
 
=Entry Points=
 
=Entry Points=
Line 269: Line 295:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticFlat.xsd/StaticModel/entryPoint
 
| mif-model-staticFlat.xsd/StaticModel/entryPoint
−
|}
 
−
 
−
 
−
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
−
| '''Requirement'''
 
−
| Static models must be able to identify the places where serialization can begin.
 
 
|-
 
|-
−
| ''Rationale''  
+
| ''OMG Mapping''
−
| Most ITSs  communicate static model instances in a serialized manner, for example XML.  This serialization must be consistent across implementations for interoperability to occur.  As well, because models connect together, the order of serialization indicates where models can connect and thus the semantics that can be expressed through the association of a class in the connecting model with the class in the target model.  Consistent serialization means a consistent starting point.
+
| {{OMG-MIF-HL7 Profile}} Stereotype on Class.
−
|-
 
−
| ''Methodology
 
−
| HL7 models must have at least one entry point.  Some models (which are not directly implementable) may have more than one, indicating that there is more than one class within the model that may be the 'focus' of an exchange.
 
−
|-
 
−
| '' MIF''
 
−
| mif-model-staticFlat.xsd/StaticModel/entryPoint
 
 
|}
 
|}
  
Line 296: Line 310:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticFlat.xsd/StaticModel/entryPoint/@name
 
| mif-model-staticFlat.xsd/StaticModel/entryPoint/@name
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on EntryPoint stereotype.
 
|}
 
|}
  
Line 308: Line 325:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticFlat.xsd/StaticModel/entryPoint/@useKind
 
| mif-model-staticFlat.xsd/StaticModel/entryPoint/@useKind
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on EntryPoint stereotype.
 
|}
 
|}
  
  
−
TODO: annotations
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
−
 
+
| '''Requirement'''
 +
| Entry Points may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Definition|Description]]
 +
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 +
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 +
* [[Requirements-Annotations#Rationale|Rationale]]
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on EntryPoint stereotype.
 +
|}
  
 
=Classes=
 
=Classes=
Line 326: Line 367:
 
* mif-model-staticFlat.xsd/StaticModel/containedClass/commonModelElementRef
 
* mif-model-staticFlat.xsd/StaticModel/containedClass/commonModelElementRef
 
* mif-model-staticFlat.xsd/StaticModel/containedClass/templateParameter
 
* mif-model-staticFlat.xsd/StaticModel/containedClass/templateParameter
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Possibly use stereotyped import relationships.
 
|}
 
|}
  
Line 338: Line 382:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/@name
 
| mif-model-staticBase.xsd/ClassBase/@name
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Assuming stubs, CMETs and classes are all modeled as named elements in UML.
 
|}
 
|}
  
Line 350: Line 397:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/definingVocabulary
 
| mif-model-staticBase.xsd/ClassBase/definingVocabulary
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on a Class stereotype.
 
|}
 
|}
  
Line 362: Line 412:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/@nameLocked
 
| mif-model-staticBase.xsd/ClassBase/@nameLocked
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on a Class stereotype.
 
|}
 
|}
  
Line 374: Line 427:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/@isComplete
 
| mif-model-staticBase.xsd/ClassBase/@isComplete
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on a Class stereotype.
 
|}
 
|}
  
  
−
TODO: annotations
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Classes, CMETs and Stubs may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Definition|Definition]]
 +
* [[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#Formal Constraint|Formal Constraint]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a Class stereotype.
 +
|}
  
  
Line 391: Line 473:
 
* mif-model-staticBase.xsd/ClassBase/templateInfo/requiredTemplateGroup
 
* mif-model-staticBase.xsd/ClassBase/templateInfo/requiredTemplateGroup
 
* mif-model-staticBase.xsd/ClassBase/templateInfo/supportedTemplate
 
* mif-model-staticBase.xsd/ClassBase/templateInfo/supportedTemplate
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} It may be possible to represent an HL7 template as a UML package template containing constraints on the template parameters. However, some HL7-specific stereotyping may also be required to properly apply such a template in the context of a UML model.
 +
|}
 +
 +
=Specializations=
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Classes need to be able to identify other classes that they "subsume".
 +
|-
 +
| ''Rationale''
 +
| The idea of "specialization" is a key concept in object-oriented representations.  It allows classes to be extended by more refined versions with additional attributes and/or associations.  HL7 uses this in the standard OO sense for the reference model.  It also uses this as a mechanism to allow choices within finer-grained models where each leaf-level specialization in the inheritance structure reflects one of the options at run-time
 +
|-
 +
| '' MIF''
 +
| mif-model-staticFlat.xsd/FlatClass/childClass
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} UML Generalization
 
|}
 
|}
  
  
−
=State Machines=
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Classes with state attributes must be able to define their state machines.
+
| Specialization relationships need to identify their expected conformance level.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| State machines help define the dynamic behavior of objects instantiating a class.  This helps clarify the semantics of a class and also identifies what can be done with it over time.
+
| As with attributes, associations and datatypes properties, it's possible for variation in whether an implementation will support all possible specializations (choice options) of a class.  It's therefore necessary for specifications to identify which specializations must be supported by all implementations and which are optional.  It's also necessary for implementation profiles to identify which optional specializations will actually be supported, which will be ignored and which might result in an error if received.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
−
| mif-model-staticBase.xsd/ClassBase/behavior
+
| mif-model-staticFlat.xsd/FlatClass/childClass/@conformance
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Stereotype on Generalization.
 
|}
 
|}
  
−
 
+
=State Machines=
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
Line 416: Line 518:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/behavior
 
| mif-model-staticBase.xsd/ClassBase/behavior
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} State machine owned by a class.
 
|}
 
|}
  
Line 428: Line 533:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/behavior/@stateAttributeName
 
| mif-model-staticBase.xsd/ClassBase/behavior/@stateAttributeName
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on a StateMachine stereotype.
 
|}
 
|}
  
  
−
TODO: Annotations
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| State machines may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Walkthrough|Walkthrough]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a StateMachine stereotype.
 +
|}
  
  
Line 443: Line 570:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/behavior/figure
 
| mif-model-staticBase.xsd/ClassBase/behavior/figure
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} State machine diagram.
 
|}
 
|}
  
Line 455: Line 585:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/behavior/subState
 
| mif-model-staticBase.xsd/ClassBase/behavior/subState
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} UML state machines contain states.
 
|}
 
|}
  
  
−
TODO: annotations
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Staes may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Definition|Definition]]
 +
* [[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#Formal Constraint|Formal Constraint]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a State stereotype.
 +
|}
  
  
Line 470: Line 629:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/behavior/subState/containedStates
 
| mif-model-staticBase.xsd/ClassBase/behavior/subState/containedStates
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} UML provides for composite states.
 
|}
 
|}
  
Line 482: Line 644:
 
| '' MIF''  
 
| '' MIF''  
 
| mif-model-staticBase.xsd/ClassBase/behavior/transition
 
| mif-model-staticBase.xsd/ClassBase/behavior/transition
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} UML state machines contain transitions.
 
|}
 
|}
  
  
−
TODO: Annotations
+
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| State Transitions may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Definition|Definition]]
 +
* [[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#Walkthrough|Walkthrough]]
 +
* [[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]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a Transition stereotype.
 +
|}
  
 +
=Attributes=
 +
Most requirements for class attributes can be found in the general section on [[Requirements-Static Model Features|Static model feature requirements]]
  
−
=Attributes=
 
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Class attributes with types convertible to string must be able to identify their default values
+
| Some attributes need to be marked as "immutable"
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Within the RIM, default values can be omitted from instances.  For other static models, default values give guidance to implementers on what is an appropriate default.
+
| HL7 uses attributes and vocabulary in place of distinct classes to ensure that the reference model can be expressed in a simple way.  These attribute values are not changeable and need to be distinguished from others.  In addition, immutable attributes may be rendered differently in some [[Requirements-Implementation Technology Specifications|Implementation Technology Specifications]].
 +
|-
 +
| '' MIF''
 +
| mif-model-staticBase.xsd/Attribute/@isImmutable
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Make the attribute read-only.
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Some attributes need to have supplemental "properties".
 
|-
 
|-
−
| ''MIF Issue''
+
| ''Rationale''  
−
| In theory there may be a use-case for default values for attributes with types that are not expressible as strings.  E.g. CD, ED.  It's also possible there could be a use-case for defaults for an association.  Neither of these are supported by MIF at present.
+
| At the moment, some attributes are flagged with an "isDocumentCharacteristic" property that identifies how those attributes are interpreted.  Other properties may be added over time.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
−
| mif-model-staticBase.xsd/Attribute/@defaultValue
+
| mif-model-staticBase.xsd/Attribute/property
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value(s) on a Property stereotype.
 
|}
 
|}
  
Line 506: Line 713:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Class attributes with types convertible to string must be able to identify their fixed values
+
| Class attributes may have a number of different types of annotations
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Fixed values are common constraints on what value an attribute may have in an instance, particularly for structural attributes that are often constrained to a fixed value within a given static model.
+
| See rationales for individual annotations types
 
|-
 
|-
−
| ''MIF Issue''
+
| ''Implementation''
−
| In theory there may be a use-case for fixed values for attributes with types that are not expressible as strings.  E.g. CD, ED.
+
|
 +
* [[Requirements-Annotations#Definition|Description]]
 +
* [[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#Formal Constraint|Formal Constraint]]
 +
* [[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]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a Property stereotype.
 +
|}
 +
 
 +
=Association Ends=
 +
Each association has an end for each class it is connected to that describes how the association  is navigated from that class.
 +
 
 +
Most requirements for class association ends can be found in the general section on [[Requirements-Static Model Features|Static model feature requirements]]
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Associations must indicate whether their names are considered "locked"
 +
|-
 +
| ''Rationale''
 +
| HL7 uses a formal naming algorithm to ensure that association navigation names are consistent with the semantics represented by the association.  Because of the requirement for association traversal name uniqueness within the context of a class, the addition or removal of associations from a class sometimes results in a change to the names of associations connected to a class. When this occurs after a model has been implemented, it creates interoperability issues. By marking the names of "old" associations within a model as 'locked', the naming algorithm knows to leave those classes alone, regardless of the addition or removal of classes and associations.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
−
| mif-model-staticBase.xsd/Attribute/@fixedValue
+
| mif-model-staticBase.xsd/AssociationEndBase/@nameLocked
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on a Property stereotype. (Association ends are properties in UML.)
 
|}
 
|}
  
Line 521: Line 762:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Class attributes with types convertible to string must be able to identify defaults that are determined based on the implementation environment rather than specific values
+
| Associations that recurse must be able to identify limits on the depth of recursion.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Some attributes such as language, realm, country, etc. can be defaulted based the environment in which the instance is being communicated.  However, this requires the ability to differentiate between a default that is a "value" vs. a default that is a textual explanation of how the environmental default is determined.
+
| Just like any other relationship, failure of implementations to be consistent in their expectations on recursion depth can result in interoperability issues.  If a sender nests an association 4 deep and the receiver can only handle nesting three levels deep, information will be lost.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
−
| mif-model-staticBase.xsd/Attribute/@defaultFrom
+
| mif-model-staticBase.xsd/AssociationEndBase/@maximumRecursionDepth
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged value on an Property stereotype. (Or perhaps on Association?)
 
|}
 
|}
  
Line 533: Line 777:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Class attributes with types convertible to string must be able to identify constraints on the length of the values expressed.
+
| Associations must be able to capture "history" just the same as the HXIT datatype.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Mismatch in support for lengths can result in interoperability issues.  For example if the sender sends 50 characters but the receiver can only process 40 characters, information will be lost.  Obviously the concept of "length" is not meaningful if the attribute can't be expressed as a string.
+
| The HXIT datatype allows a timestamp and linkage to a particular ControlAct to be associated with each repetition of an attribute.  This allows for detailed history information of exactly when a part of a model was changed, by whom, why, etc.  This same sort of information can need to be captured for associations.  And associations must therefore indicate whether that information is allowed or not.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
−
|
+
| mif-model-staticBase.xsd/AssociationEndBase/@referenceHistory
−
* mif-model-staticBase.xsd/Attribute/@minimumLength
+
|-
−
* mif-model-staticBase.xsd/Attribute/@maximumLength
+
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a Property stereotype.
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Association ends may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Definition|Description]]
 +
* [[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#Formal Constraint|Formal Constraint]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Tagged values on a Property stereotype. (Same as the annotations for a property used as an attribute.)
 
|}
 
|}
  
Line 547: Line 821:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Class attributes must be able to indicate whether they are allowed to be 'null' values.
+
| When an association points to a choice structure (an abstract class having specializations), it needs to capture traversal names for each of the classes, CMETs and stubs in the choice hierarchy.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| Not all
+
| With some ITSs, such as XML, there's a requirement that traversal names be distinct when the types are distinct.  By definition, a choice structure consists of multiple potential types.  Each of those types therefore requires a name.
 
|-
 
|-
 
| '' MIF''  
 
| '' MIF''  
−
|
+
| mif-model-staticBase.xsd/AssociationEndBase/ChoiceItem/@traversalName
−
* mif-model-staticBase.xsd/Attribute/@minimumLength
+
|-
−
* mif-model-staticBase.xsd/Attribute/@maximumLength
+
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Perhaps a stereotype on a dependency from the association end to each choice item, with the traversal name as a tagged value.
 
|}
 
|}

Latest revision as of 16:44, 28 July 2010

This page documents one or more V3 Methodology Requirements

Static models define the information structures for the data to be shared by HL7 standards. This includes the types of data elements, the constraints on those data elements and the meaning of each element.

Key Constructs

Requirement There needs to be a mechanism of grouping data elements that are related.
Rationale Without organization into logical groupings, data elements become hard to manage or interpret. As well, grouping helps to define the semantics of an element by allowing inheritance of semantics from the definition of the group.
Methodology HL7 uses the object-oriented concept of "class" to group related data elements
MIF mif-model-staticBase.xsd/ClassBase
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML Class


Requirement There needs to be a mechanism of defining the relationships between groups of related data elements.
Rationale The semantics of information in a model is often conveyed by the relationships between those elements. For example, the group of elements representing "Person" might be related to the group representing "Lab Result" as the subject, the performer, supervisor, etc.
Methodology HL7 uses the object-oriented concept of "association" to link related groups of data elements
MIF mif-model-staticBase.xsd/AssociationBase
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML Association


Requirement When designing a data model, there needs to be a way of allowing choices of different groupings of concepts when constructing an instance.
Rationale Instances often need to allow for flexibility. For example, an observation might be made by a patient, a healthcare provider or a patient representative. The set of information to be collected would vary in each circumstance and the model must define what each group of data must be as well as indicate that any one of those options is allowed (and only those options are allowed).
Methodology HL7 uses the idea of "choices". A choice is an abstract class having no attributes with one or more specialization classes. Each specialization represents one of the options within the choice.
MIF mif-model-staticBase.xsd/ClassGeneralizationBase
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

This could be modeled in the same way in UML, with a stereotype specifically indicating that a choice is being modeled.


Model metadata

Requirement Models must be able to indicate whether they are serializable or not.
Rationale The ability to serialize a model instance in a standardized way is essential for transmitting instances via technologies that require serialization (e.g. XML). However, other HL7 models (such as the RIM ) do not need to be serializable. Knowing whether a model is serializable indicates what sorts of things can be done with it.
MIF mif-model-staticBase.xsd/StaticModelBase/@isSerializable
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

This could be indicated using an HL7 stereotype. Note, however, that all MOF-based models are serializable using XMI.


Requirement It must be possible to represent one static model as a set of deltas from another static model.
Rationale The HL7 methodology relies on a premise of constraint where models are constructed based on other "more abstract" models using a process of derivation . Often these models only make a few constraints to the parent model. However, if the parent model is updated, these models need to be updated to remain proper constraints of the parent. By storing only the "changes" from the parent model the amount of maintenance is significantly reduced.
MIF mif-model-staticDerived.xsd/derivedStaticModel
OMG Mapping

Model Management: This MIF requirement is best addressed using specific tool capabailities or within the modeling infrastructure.


Requirement Static models need to be able to identify what format they're represented in.
Rationale A given static model might be represented in its flat or serialized form or as a derived model. Because each of these representations allows different things to be done with it, it's essential to be able to differentiate what a particular representation looks like.
MIF mif-model-staticBase.xsd/StaticModelBase/@representationKind
OMG Mapping

Tool Feature: This MIF requirement is addressed by a capability that is specific to particular tool implementations.


Requirement Static models must be able to indicate the type of conformance rules that apply to the model design, specifically around the use of extensions
Rationale HL7 has three distinct sets of rules for models depending on what context the model is created in. In order to enforce those rules, the context must be known.
Methodology
  • International: The model is an international standard - no extensions allowed.
  • RealmExtension: Realm specific extensions allowed in the primary namespace.
  • Localization: Non-balloted specification. Extensions allowed, but only in discrete namespaces
MIF mif-model-staticBase.xsd/StaticModelBase/@conformanceLevel
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

An appropriate HL7 stereotype could have a tag indicating the conformance context.


Requirement Static models must be able to indicate whether they are intended to be directly used in the construction of instances, or whether they are only intended to be used as design artifacts to aid the creation of other models.
Rationale High-level models such as the RIM, Domain Information Models, and some CIMs are not intended to be used directly in the construction of instances. They are too abstract to be safely usable. Without a way to distinguish the intended use of the models, they may be mis-used by implementers.
MIF mif-model-staticBase.xsd/StaticModelBase/@isAbstract
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

An HL7 model stereotype could have a tag for this.


Requirement Static Models may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

An HL7 model stereotype could have tags for these.


Requirement Static models must be able to be represented graphically and be able to have that graphical representation persisted.
Rationale Graphical representation has been found essential to enabling quick communication and understanding of model content. I.e. "A picture is worth 1000 words".
MIF
  • mif-model-staticBase.xsd/StaticModelBase/graphicRepresentation
  • mif-model-staticBase.xsd/StaticModelBase/figure
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML is a graphical notation.


Requirement Static models must be able to identify the other artifacts they are based on.
Rationale Static models depend on datatypes and vocabulary and potentially interface packages and/or annotation libraries . If someone reviewing a model doesn't have access to the same versions of these artifacts that were consulted in constructing the model, they will not be able to understand the content within the model and may even misinterpret the model.
MIF
  • mif-model-staticBase.xsd/StaticModelBase/importedDatatypeModelPackage
  • mif-model-staticBase.xsd/StaticModelBase/importedVocabularyModelPackage
  • mif-model-staticBase.xsd/StaticModelBase/importedInterfacePackage
  • mif-model-staticBase.xsd/StaticModelBase/importedAnnotationLibrary
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

UML already provides for importing of packages. However, such importation is necessary only to make names within the imported package visible without qualification -- it is allowable to reference elements within a package without importing it. Nevertheless, stereotyped UML import relationships could be used to represent the above HL7 dependencies.


Requirement Static models must be able to identify supplemental datatype flavors defined locally.
Rationale HL7 has the concept of Datatype Flavors . In some circumstances a datatype flavor may be specific to a particular static model rather than being generically defined and applicable to a variety of static models. In these circumstances the flavor needs to be defined within the model that uses it.
MIF mif-model-staticBase.xsd/StaticModelBase/additionalDatatypeModel
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

UML allows for the modeling of new data types, which could be stereotyped as appropriate for HL7. [This may need further discussion depending on a deeper review of the HL7 Datatype Flavor concept.]


Requirement Static models must be able to identify supplemental vocabulary information, particularly value sets, defined locally.
Rationale In some circumstances a valueset or other vocabulary artifact may be specific to a particular static model rather than being generically defined and applicable to a variety of static models. In these circumstances the vocabulary structures may need to be defined within the model that uses them. (The alternative would be having 1..1 supplemental models maintained separately which would be a maintenance nightmare.)
MIF mif-model-staticBase.xsd/StaticModelBase/additionalVocabularyModel
OMG Mapping [Depends on the OMG Mapping for vocabulary models.]


Requirement Static models must be able to document vocabulary constraints or considerations that apply across the entire model.
Rationale While many HL7 models are constructed in a way that is independent of any particular technology solution, most models make at least some sort of assumptions about the types of technologies that will be used. These assumptions need to be understood by the implementers of the model if the model is to be implemented safely.
MIF mif-model-staticBase.xsd/StaticModelBase/vocabularyGuidance
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

[Needs a deeper review of the HL7 concept of "vocabulary guidance".]


Requirement Static models must be able to group classes into named collections based on "subject area".
Rationale Some models are too large to be easily understood as a whole. Even for those that are understandable, dividing of the model into a set of sub-sections helps to aid in comprehensibility.
MIF mif-model-staticBase.xsd/StaticModelBase/subjectAreaPackage
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML Package [But would a stereotype be appropriate?]


Requirement Static models need to be able to identify what coded concept they represent.
Rationale Some static models, generally templates, are constructed to give concrete representation to a clinical concept from one or more code systems. For example, "blood pressure". When a model has been constructed for this purpose, it needs to be able to identify what code(s) it is representing.
MIF mif-model-staticBase.xsd/StaticModelBase/definitionalCode
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Entry Points

Requirement Static models must be able to identify the places where serialization can begin.
Rationale Most ITSs communicate static model instances in a serialized manner, for example XML. This serialization must be consistent across implementations for interoperability to occur. As well, because models connect together, the order of serialization indicates where models can connect and thus the semantics that can be expressed through the association of a class in the connecting model with the class in the target model. Consistent serialization means a consistent starting point.
Methodology HL7 models must have at least one entry point. Some models (which are not directly implementable) may have more than one, indicating that there is more than one class within the model that may be the 'focus' of an exchange.
MIF mif-model-staticFlat.xsd/StaticModel/entryPoint
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Stereotype on Class.


Requirement Entry points must have a name
Rationale Names allow the entry points to be referred to within a model and by humans.
MIF mif-model-staticFlat.xsd/StaticModel/entryPoint/@name
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on EntryPoint stereotype.


Requirement Entry points must be able to identify how they're intended to be used
Rationale Models can be used for a variety of purposes – as wrappers, CMETs, templates, etc. Identifying the intended use of an entry point clarifies for users of the model how the model is intended to be used from that entry point.
MIF mif-model-staticFlat.xsd/StaticModel/entryPoint/@useKind
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on EntryPoint stereotype.


Requirement Entry Points may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on EntryPoint stereotype.

Classes

Requirement Static models must support referencing of CMETs and Stubs .
Rationale HL7 models cannot function in a manner that is totally self contained. Models need to be able to reference other models to allow for re-use, componentization and separation of concerns.
MIF
  • mif-model-staticFlat.xsd/StaticModel/containedClass/commonModelElementRef
  • mif-model-staticFlat.xsd/StaticModel/containedClass/templateParameter
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Possibly use stereotyped import relationships.


Requirement Stubs, CMET references and Classes must all have unique names within a model
Rationale Names allow human reference and also allow explicit reference of the particular class, CMET or stub referenced by an association or entry point.
MIF mif-model-staticBase.xsd/ClassBase/@name
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

Assuming stubs, CMETs and classes are all modeled as named elements in UML.


Requirement Classes based on RIM immutable coded attributes must be able to identify their associated structural vocabulary.
Rationale The RIM uses structural vocabulary to supplement its object hierarchy. Thus knowing the base physical class in the RIM is not sufficient to know the full meaning of a class. In the case of stubs and CMETs, the vocabulary reference identifies the physical class that will be at the root of the referenced model. For classes in the RIM, the vocabulary reference identifies the location within structural vocabulary hierarchy that corresponds to a class in the physical class hierarchy.
MIF mif-model-staticBase.xsd/ClassBase/definingVocabulary
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on a Class stereotype.


Requirement Classes must indicate whether their names are considered "locked"
Rationale HL7 uses a formal naming algorithm to ensure that class names are consistent with the semantics represented by the class. Because of the requirement for class name uniqueness in the model, the addition or removal of classes from a model sometimes results in a change to the names within a model. When this occurs after a model has been implemented, it creates interoperability issues. By marking the names of "old" classes within a model as 'locked', the naming algorithm knows to leave those classes alone, regardless of the addition or removal of classes.
MIF mif-model-staticBase.xsd/ClassBase/@nameLocked
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on a Class stereotype.


Requirement Classes derived from the RIM must be able to distinguish whether omitted attributes and associations are prohibited or unconstrained.
Rationale In models like RMIMs, omitting an attribute present in the RIM class an RMIM class is derived from means that the attribute is not allowed to appear in instances (except potentially as an extension.) However, in some templates, the desire is to only enforce constraints on what elements must appear, not to prohibit the appearance of anything unspecified. Without an indicator as to which approach is desired, the class cannot be correctly implemented
MIF mif-model-staticBase.xsd/ClassBase/@isComplete
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on a Class stereotype.


Requirement Classes, CMETs and Stubs may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a Class stereotype.


Requirement At a given class within a static model, the model must be able to assert what templates can be applied and what templates are known that might optionally be applied at that location.
Rationale Templates allow the application of a set of constraints to a model without altering the wire-format of the instance. As such, templates represent re-usable constraints. Rather than copying those constraints into every model where they need to apply, it is easier to just reference the template. This also significantly simplifies the maintenance effort. Listing of optional templates simplifies things for implementers by providing them with a list of optional constraint sets that are known to be appropriate.
MIF
  • mif-model-staticBase.xsd/ClassBase/templateInfo/requiredTemplateGroup
  • mif-model-staticBase.xsd/ClassBase/templateInfo/supportedTemplate
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

It may be possible to represent an HL7 template as a UML package template containing constraints on the template parameters. However, some HL7-specific stereotyping may also be required to properly apply such a template in the context of a UML model.

Specializations

Requirement Classes need to be able to identify other classes that they "subsume".
Rationale The idea of "specialization" is a key concept in object-oriented representations. It allows classes to be extended by more refined versions with additional attributes and/or associations. HL7 uses this in the standard OO sense for the reference model. It also uses this as a mechanism to allow choices within finer-grained models where each leaf-level specialization in the inheritance structure reflects one of the options at run-time
MIF mif-model-staticFlat.xsd/FlatClass/childClass
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML Generalization


Requirement Specialization relationships need to identify their expected conformance level.
Rationale As with attributes, associations and datatypes properties, it's possible for variation in whether an implementation will support all possible specializations (choice options) of a class. It's therefore necessary for specifications to identify which specializations must be supported by all implementations and which are optional. It's also necessary for implementation profiles to identify which optional specializations will actually be supported, which will be ignored and which might result in an error if received.
MIF mif-model-staticFlat.xsd/FlatClass/childClass/@conformance
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Stereotype on Generalization.

State Machines

Requirement Classes with state attributes must be able to define their state machines.
Rationale State machines help define the dynamic behavior of objects instantiating a class. This helps clarify the semantics of a class and also identifies what can be done with it over time.
MIF mif-model-staticBase.xsd/ClassBase/behavior
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

State machine owned by a class.


Requirement The state machine must identify the attribute to which the state machine applies.
Rationale It's hard to use a state machine if you don't know where to convey or find the current state . . .
MIF mif-model-staticBase.xsd/ClassBase/behavior/@stateAttributeName
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on a StateMachine stereotype.


Requirement State machines may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a StateMachine stereotype.


Requirement The state machine must be able to be represented graphically
Rationale A diagram of a state machine is much easier to understand than a flat enumeration of states and transitions
MIF mif-model-staticBase.xsd/ClassBase/behavior/figure
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

State machine diagram.


Requirement State machines must list the states they contain, including name
Rationale A state machine doesn't accomplish much if you don't know what the states are
MIF mif-model-staticBase.xsd/ClassBase/behavior/subState
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML state machines contain states.


Requirement Staes may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a State stereotype.


Requirement States must be able to contain sub-states
Rationale Sometimes a given state can be partitioned into multiple substates and both the superstate and its substates can be of interest in different use-cases
MIF mif-model-staticBase.xsd/ClassBase/behavior/subState/containedStates
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML provides for composite states.


Requirement State machines must list the state transitions they support, including name
Rationale A state machine that doesn't permit transitions between the states doesn't accomplish much.
MIF mif-model-staticBase.xsd/ClassBase/behavior/transition
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

UML state machines contain transitions.


Requirement State Transitions may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a Transition stereotype.

Attributes

Most requirements for class attributes can be found in the general section on Static model feature requirements

Requirement Some attributes need to be marked as "immutable"
Rationale HL7 uses attributes and vocabulary in place of distinct classes to ensure that the reference model can be expressed in a simple way. These attribute values are not changeable and need to be distinguished from others. In addition, immutable attributes may be rendered differently in some Implementation Technology Specifications.
MIF mif-model-staticBase.xsd/Attribute/@isImmutable
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

Make the attribute read-only.


Requirement Some attributes need to have supplemental "properties".
Rationale At the moment, some attributes are flagged with an "isDocumentCharacteristic" property that identifies how those attributes are interpreted. Other properties may be added over time.
MIF mif-model-staticBase.xsd/Attribute/property
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value(s) on a Property stereotype.


Requirement Class attributes may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a Property stereotype.

Association Ends

Each association has an end for each class it is connected to that describes how the association is navigated from that class.

Most requirements for class association ends can be found in the general section on Static model feature requirements

Requirement Associations must indicate whether their names are considered "locked"
Rationale HL7 uses a formal naming algorithm to ensure that association navigation names are consistent with the semantics represented by the association. Because of the requirement for association traversal name uniqueness within the context of a class, the addition or removal of associations from a class sometimes results in a change to the names of associations connected to a class. When this occurs after a model has been implemented, it creates interoperability issues. By marking the names of "old" associations within a model as 'locked', the naming algorithm knows to leave those classes alone, regardless of the addition or removal of classes and associations.
MIF mif-model-staticBase.xsd/AssociationEndBase/@nameLocked
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on a Property stereotype. (Association ends are properties in UML.)


Requirement Associations that recurse must be able to identify limits on the depth of recursion.
Rationale Just like any other relationship, failure of implementations to be consistent in their expectations on recursion depth can result in interoperability issues. If a sender nests an association 4 deep and the receiver can only handle nesting three levels deep, information will be lost.
MIF mif-model-staticBase.xsd/AssociationEndBase/@maximumRecursionDepth
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged value on an Property stereotype. (Or perhaps on Association?)


Requirement Associations must be able to capture "history" just the same as the HXIT datatype.
Rationale The HXIT datatype allows a timestamp and linkage to a particular ControlAct to be associated with each repetition of an attribute. This allows for detailed history information of exactly when a part of a model was changed, by whom, why, etc. This same sort of information can need to be captured for associations. And associations must therefore indicate whether that information is allowed or not.
MIF mif-model-staticBase.xsd/AssociationEndBase/@referenceHistory
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a Property stereotype.


Requirement Association ends may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Tagged values on a Property stereotype. (Same as the annotations for a property used as an attribute.)


Requirement When an association points to a choice structure (an abstract class having specializations), it needs to capture traversal names for each of the classes, CMETs and stubs in the choice hierarchy.
Rationale With some ITSs, such as XML, there's a requirement that traversal names be distinct when the types are distinct. By definition, a choice structure consists of multiple potential types. Each of those types therefore requires a name.
MIF mif-model-staticBase.xsd/AssociationEndBase/ChoiceItem/@traversalName
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Perhaps a stereotype on a dependency from the association end to each choice item, with the traversal name as a tagged value.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Requirements-Static_Model&oldid=39544"