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.

What is a Domain

Dring its Conference Call on January 19, 2007, M&M decided to publish this item on the Wiki as part of the DMIM discussion. The item reflects a building consensus around the following points of agreement:

• All artifacts should derive from some coherent set of knowledge as represented in a single model. This is a "semantic domain" and is the focus of an HDF DIM.
• Publishing should be able to aggregate content from semantic domains into collections that are useful for committees that address multiple semantic domains
• Future (18 moths or more out) tooling will allow such publishing, as the MIF allows for such distinctions
• Today, several committees are using a single "publishing domain" (really just a package) to publish multiple "semantic domains" each as a topic, including Decision Support, Patient Administration, Common Messages, and Patient Care.
• Other committees are maintaining correct semantic domains, such as Pharmacy with Medication and RX. and Lab with OO, LB, SP.
• Publishing should determine which pattern is being followed in each of today's "Domains" and should require:
  • That the style be declared at the front of the domain introduction
  • That a committee not do both. That is, in each publishing domain either every topic is a semantic domain or all of the topics are in a single semantic domain. Note: This may represent an issue for Patient Care.

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 static 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 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.

• Note that the methodology may evolve to introduce a new concept of "pattern D-MIMs" a la Clinical Statement where balloting as DSTU or Normative may have value. However, until such time as this methodology is defined and agreed, balloting of such D-MIMs will have no weight on other models.

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

Resolution

Accept the above as lore

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?

20070108 MnM/INM WGM: Current methodology requires the definition of a D-MIM in a domain. (This lore needs to be documented). The case of shared messages the topics can be groups and one (or more) D-MIMs can be constructed. - see MnM minutes for the official wording of this motion. - (see discussion page for history of the discussion)

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.