MIF OMG Solution Options
This page is a work in progress and does not reflect any official recommendation. It is intended for the use of those working on the OMG MIF project only.
The following tables list key methodology aspects of HL7 and describes how they might be met using industry standards.
Each table as 6 columns, which are intended for use as follows:
Requirement: Identifies the requirement being mapped. Only non-obvious requirements will be listed. For example, if mapping static models to UML, saying that "Class" maps to "Class" doesn't accomplish much. A link may be provided to the V3 Methodology Requirements section that discusses the requirement.
Existing support: Indicates that there is a direct home for the concept in the main proposed standard. This would only be relevant if the direct home wasn't already obvious.
Add to standard: Indicates that this concept is a candidate to be added into the proposed standard based on expected cross-industry applicability
Cross-industry profile: Indicates that the concept isn't broadly applicable enough for use in the base standard, but might reasonably be part of a cross-industry profile on the standard using native extension mechanisms. The expectation is that all elements part of such a profile would receive broad support by tooling vendors.
HL7-specific: Indicates that the concept is specific enough to HL7 that broad industry tooling support is unlikely and that, at least for the purpose of artifact development and maintenance, the feature would either need to be supported by custom tooling or would need to be considered for refactoring or dropping from HL7's requirements to allow broader industry tooling use.
Methodology revision: Describes a means by which the same 'objective' could be achieved using an alternate methodology that might be better in alignment with common industry practices and thus with off-the-shelf tooling capabilities. This section will explain the proposed methodology change and how the resulting change would map to the proposed standard. A discussion on costs & benefits (i.e. what HL7 would gain and lose by making the change) should also be provided.
In some cases, more than one solution column may be filled in. For example, both cross-industry profile and methodology revision might be options. In the event the description doesn't easily fit within a single table column, a short summary may be provided with a link to a secondary page providing detail may be used. (The secondary page should provide a link at the top back to this one.)
Static Model
General The presumed mapping for static model content is the UML 2.0 class model
| Requirement | Existing support | Add to standard | HL7-specific | Methodology Revision |
| Differentiating serializable models | ||||
| 'Derived' static models | ||||
| Model conformance level | ||||
| Model dependencies | ||||
| Local datatypes | ||||
| Local vocabulary | ||||
| Model conformance level | ||||
| Definitional codes | ||||
| Entry points | ||||
| CMETs | ||||
| Stubs | ||||
| Definitional vocabulary | ||||
| Name locking | ||||
| Complete vs. incomplete models | ||||
| Template usage | ||||
| Conformance | ||||
| Immutable | ||||
| Recursion depth | ||||
| History reference | ||||
| Association naming for choices |
