Common Message Element Types

CMETs (Common Message Element Types) are a work product produced by a particular committee for expressing a common, useful and reusable concept. They are generally "consumed", or used by both the producing committee and other committees. Because they are intended for common use across messages produced by all committees, they are proposed to, reviewed by, and maintained by the CMET task force of the MnM committee. The CMET task force harmonizes and becomes steward for all CMETs.

A CMET can be envisioned as a message type fragment that is reusable by other message types. Any message type can reference a CMET, including other CMETs. As an example, several committees may require the use of a common concept, that of a person in the role of a patient. A CMET can be defined to express this concept as a message type that clones a role played by a person, with all appropriate attributes. The CMET is then used to uniformly represent the concept for all interested committees.

CMET Hierarchy

As described in the V3 Guide, CMETs are categorized along two axes- an attribution axis and a generalization-specialization axis.

• Attribution refers to the level of specificity of the CMET. As a CMET is implemented as a message type derived from an HMD and R-MIM in the same manner as all other message types, the message type may contain complete information about a concept, or minimal information about a concept. At the complete extreme, this is known as the universal level of attribution of the CMET. Typically, the other extreme is known as the identified level of attribution of the CMET, or universal and identified variants, respectively. The universal variant of a CMET is always present, and all other variants, if they exist, are derived by restriction from the universal variant. The common CMET variants are described below.

• The Generalization-Specialization axis allows a message designer to choose between several specializations of a concept in a CMET. These choices always are between specializations of a RIM class that plays the central role in the concept modeled by the CMET. For example, we may model an Entity of type LivingSubject in the same fashion as an Entity of type Person or NonPersonLivingSubject (with the exception of the Entity specialization itself!). This results in a generalized CMET called E_LivingSubject, and several specialized CMETs called E_Person and E_NonPersonLivingSubject. With the exception of the entity itself (LivingSubject, Person, NonPersonLivingSubject), the rest of the CMETs are equivalent.

Common CMET Variants

CMETS come in several flavours or variants from the most detailed to the least. Designers should select an appropriate level of detail when building RMIMs. The common variants are:

1. universal - this variant includes all attributes and associations present in the R-MIM. Any of non-mandatory and non-required attributes and/or associations may be present or absent, as permitted in the cardinality constraints.

2. minimal - provides more than identified, but not as much as universal. There are not expected to be many of these.

3. contactable - provides sufficient information to allow the object identified to be contacted. This is likely to have the content of identified and confirmable plus telephone number.

4. informational - generally the same information content as "contactable", but with required (not mandatory) ids on entry point class. This flavor allows expression of the CMET even when mandatory information is not known.

5. identified and confirmable - this extends the identified variant by adding just sufficient additional information to allow the identity of object modeled to be confirmed by a number of corroborating items of data; for instance a patient's date of birth and current address. However, specific contact information, such as telephone number, are not viewed as confirming information.

6. identified and informational - generally the same information content as "contactable" but using new "informational" CMETs as dependant CMETs. This flavor allows expression of the CMET when non-focal class information is not known.

7. identified - this variant is a proper subset of universal and is intended to provide sufficient information to identify the object(s) modeled by the CMET. This variant is only suitable for use within TIGHTLY COUPLED SYSTEMS ONLY. This variant provides ONLY the ID (and code where applicable) and Name. Other variants may not be substituted at runtime.

8. Other variants may be developed in future.