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

(Lloyd) However, a domain that doesn't have a top-level all-encompassing domain doesn't really fit the definition of a proper domain.

Open Issue #3: Topic level D-MIMs

In several existing domains, MT (common message types) DS (Decision support), and the RCRIM domains (RR, RP, RT) we have disjoint material because of the intended use (MT) of the content, or because of the nature of the groups being supported (DS and RCRIM). In those cases, we are actually balloting the content by "Topic", which leads, of course to the question:

Why are "DIM"s (or DMIMs) limited to a domain, particularly where we have topics. Why not accept "tDIM"s - Topic-level DIMs?? This is the way the content is prepared and reviewed in those areas anyway? Admittedly, when the ballot was simple - eight domains, we could make an argument for mandatory DIMs at the domain level. Today, that decisions NEEDS TO BE RECONSIDERED. The base rule is good, but: Are there no exceptions? How to deal with things like RCRIM and DS? What about MT, where the material is more abstract and does not foot with any one domain.

INM also has the opposite issue: all of the control act wrapper domains (MCAI, query, master file) share one common D-MIM - we wouldn't want to make changes to the controlAct class in one of these domains whilst not also making them in the other domains. I would *love* to see those three domains turned into one. They really are dealing with a common understanding. The alternative, would be to create multiple wrapper levels. I.e. Define ControlAct in one domain and Registration in another domain and have people stitch them together as part of their interaction definition. However, we'll need new tools to support capturing these multiple wrapper levels.

There's no issue having D-MIMs at multiple levels.