Domain Message Information Model
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
This page documents Lore, i.e. all the facts and traditions about a particular subject that have been accumulated over time, but that have not been documented in a ballot yet.
Glossary definition: A Domain Message Information Model (D-MIM) is a form of Refined Message Information Model (R-MIM) constructed to represent the totality of concepts embodied in the individual R-MIMs needed to support the communication requirements of a particular HL7 domain.
For more information see Information Models.
Guidance
- D-MIMs (or DIMs in v2 speak) are Domain models representing a committee's (or group of committee's) understanding of the "data" and relationships that are relevant within the area of clinical or administrative knowledge represented by that domain expressed in HL7 modeling terms. DIMs should represent the majority, or preferably all, of the requirements documented within a committee's DAMs (Domain Analysis Model) expressed in RIM modeling terms. All DIMs must be a proper constraint on the HL7 RIM.
- There is only one "principle" domain model for each domain which encompasses the totality of the domain. It may be composed of multiple sub-DIMs that represent specific subsets of the DIM. A DIM may reference subsets of other domain models via CMETs.
- Note that thus doesn't hold true for two reasons: (a) query R-MIMs aren't modeled in a D-MIM, (b) certain domains (e.g. Shared Messages) are fragmented (the use-cases for the R-MIMs may be totally disjunct) and (c) CMET "R-MIMs" in a domain may not be a subset of the DIM. So one can say that In principle there is 1 DIM, but one can't say there is only 1 principle DIM. Rene spronk 01:22, 6 Jul 2006 (CDT)
- All static models published within a domain, with the exception of query definitions, must be derived as a proper subset from the DIM. Any model that is not a proper constraint on the DIM is considered to be in violation of publication guidelines and is subject to negative ballot.
- DIMs are considered "informative" in a similar manner to Storyboards regardless of the ballot state of their domains in that DIMs are non-implementable and thus cannot be binding on implementers. Designers creating derived models based on a particular domain for local use within their organization should try to align with the DIM for the respective domain and are encouraged to feed-back changes to accomodate their requirements. However, as they are operating outside the HL7 standards development process, they cannot expect that the DIM will not evolve in the future in a manner that is not compatible with whatever constraint static models they design.
- DIMs should be expected to evolve over time. Committees are expected to align future versions of artifacts with the version of the DIM in place at the time the new versions of those artifacts are balloted. Committees are not expected to maintain compatibility between the DIM and previously balloted artifacts, though violation of this compatibility will necessitate new artifact ids when the old artifacts are updated.
Issues
Patient care believes it is appropriate to ballot D-MIMs as DSTU and to maintain their D-MIMs as static between DSTU versions, recognizing that new content undergoing DSTU or committee level ballot may not represent a proper subset of their D-MIM
Recommendation
- MnM to endorse the above as approved lore
- MnM to contact publishing and arrange for this information to be reflected in the V3 Publishers Guide
- MnM to reflect the above information in the HDF
