This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Domain Message Information Model"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) (→Issues) |
|||
| Line 6: | Line 6: | ||
==Guidance== | ==Guidance== | ||
| − | *D-MIMs (or [[DIM]]s in | + | *D-MIMs (or [[DIM]]s in [[HDF]] 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 [[DAM]]s ([[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 | + | *A key differentiator between DIMs and R-MIMs (CIMs) is that DIMs are not intended to be serializable |
| − | ** | + | |
| + | *There is only one "principle" domain model for each domain which encompasses the totality of the domain. It may be composed of multiple child-DIMs that represent specific subsets of the DIM. A DIM may reference subsets of other domain models via CMETs. | ||
| + | **Exceptions include "collector" domains such as CMETs and (possibly) Shared Messages which draw materials from other sources | ||
*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. | *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. | ||
Revision as of 16:27, 13 October 2006
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 HDF 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.
- A key differentiator between DIMs and R-MIMs (CIMs) is that DIMs are not intended to be serializable
- There is only one "principle" domain model for each domain which encompasses the totality of the domain. It may be composed of multiple child-DIMs that represent specific subsets of the DIM. A DIM may reference subsets of other domain models via CMETs.
- Exceptions include "collector" domains such as CMETs and (possibly) Shared Messages which draw materials from other sources
- 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
- As long as one doesn't have to guarantee that a new D-MIM be Semantically Backward Compatible with a previous version of that D-MIM, and there is no need to ever assign a new artefact ID to a D-MIM, a D-MIM can probably be balloted. D-MIMs are balloted today, but don't achieve normative/DSTU status. What advantage does the committee see in having a D-MIM with DSTU status? Rene spronk 01:34, 6 Jul 2006 (CDT)
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
