Domain Message Information Model

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.

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

Open Issue #1: Normative D-MIM

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)

Open Issue #2: Domain without D-MIM

The shared messages domain (COMT) has a number of topics. Each topic is based on its own use-case, as such a D-MIM can only be constructed in a rather arteficial way by creating a join (a superset) of all R-MIMs contained in the domain. Does one have to include a D-MIM in this domain? What are the criteria for including a D-MIM?

• (Woody) You said you had tried the super-set approach. Was that difficult to define? Was it Disconnected?
  • (Rene) It's not disconnected - yet. It is however rather artificial, and the walkthrough doesn't provide a lot of information...
• We should (at minimum) consider the pros and cons of the alternatives which include (but are not restricted to):

1. Require a maintained DMIM for every published domain.

   Well, limited to those domains that defines Message Types, probably.

2. Attempt to bind each of the COMT artifacts to a DMIM in some other published domain.

   Forget it - you may try, but there won't be a fit for most (if not all) of them.

3. Identify the RIM as the DMIM for COMT (although there are RIM elements that no COMT will ever use, I suspect.

   That's in option - but it would be a first and might create a precedent.

4. Allow a "segmented" DMIM, made up of multiple sets of classes that might overlap?
5. Drop the must have a DMIM rule for COMT and COCT?

   See UML_ITS_Policy#Serialization_Details - if there is no D-MIM then a D-MIM based serialization process won't be possible.

6. Create multiple D-MIMs in COMT where each D-MIM is equal to 1 R-MIM