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
|
| 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
|
| 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
|
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
|
| 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
|
| 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
|
| 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
|
| 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
|
| Requirement
|
Static Models may have a number of different types of annotations
|
| Rationale
|
See rationales for individual annotations types
|
| Implementation
|
|
| 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
|
| 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
|
| 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 .
|
| MIF
|
- mif-model-staticBase.xsd/StaticModelBase/graphicRepresentation
- mif-model-staticBase.xsd/StaticModelBase/figure
|
| 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
|
| 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
|
| 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
|
| 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
|
| 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
|
| 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
|
| 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 pressue". 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
|
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
|
| 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
|
| 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
|
| 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
|
| Requirement
|
Entry Points may have a number of different types of annotations
|
| Rationale
|
See rationales for individual annotations types
|
| Implementation
|
|
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
|
| 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
|
| 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
|
| 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
|
| 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
|
| Requirement
|
Classes, CMETs and Stubs may have a number of different types of annotations
|
| Rationale
|
See rationales for individual annotations types
|
| Implementation
|
|
| 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
|
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
|
| 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
|
| 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
|
| Requirement
|
State machines may have a number of different types of annotations
|
| Rationale
|
See rationales for individual annotations types
|
| Implementation
|
|
| 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
|
| 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
|
| Requirement
|
Staes may have a number of different types of annotations
|
| Rationale
|
See rationales for individual annotations types
|
| Implementation
|
|
| 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
|
| 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
|
| Requirement
|
State Transitions may have a number of different types of annotations
|
| Rationale
|
See rationales for individual annotations types
|
| Implementation
|
|
Attributes
Most requirements for class attributes can be found in the general section on Static model feature requirements
