CMET Documentation Guidelines

Last Updated: ND 01/09/2007

Examples of CMET descriptions (to use as guideline):

CMET: A_Encounter universal

Description: Used to identify a specific patient encounter in the event mood where the receiver is assumed to need all the data about the patient encounter.

CMET: A_Encounter minimal

Description: Used to identify a specific patient encounter in the event mood.

CMET: A_Encounter identified

Description: Used to identify a specific patient encounter in the event mood in cases of closely coupled systems where the receiver will have access to any needed information merely by receiving the identifier

Template for CMET Descriptions:

Used to identify an individual <or a type of > <domain class name>>.

Here’s an example of appropriate additional verbiage.

• A covered party may or may not be the same person/organization that is the beneficiary.

Following were also considered for template descriptions:

• Specifies <domain class name(s)>

• Describes <domain class/attribute names>.

• Provides information about <domain class ><including domain attribute names>

• Provides <domain data names> information <sufficient to ??>.

Guidelines

Positive Guidelines:

• the description should describe
• no need to describe optional/mandatory attributes or cardinality of attributes or associations (that information is specified by the model)
• CMETs in the same family should have a portion of their description that is common
• CMETs in the same family should have a portion of their description that is different but standardized based upon the type of CMET (universal, contactable, etc.) The standardized verbiage is included below.

Negative Guidelines:

• never indicate what attributes, classes, or associations are not included. Rationale: every description of related CMETs would sound similar except for more or less number of items indicating they weren't included; it's a waste and only begs the question why not.
• never include a rationale for why items were or weren't included. Rationale: listing items included just duplicates the model or message type specifications; listing items not included serves no useful purpose.
• never mention focal class, entry class, other CMETs (e.g. a separate A_Account CMET) or other similar terms. Rationale: the definition should be for domain experts and not include any modeling terms.
• don't include verbiage such as: this CMET has an "Abstract" domain model, or D-MIM. Rationale: the definition should be for domain experts and not include any modeling terms.
• don't include verbiage on how it differs from other CMETs/variants. Rationale: the standard definitions of CMET types should include that information.
• never include sections listing classes, attributes, associations, or whether they were included or not. Rationale: listing items included just duplicates the model or message type specifications; listing items not included serves no useful purpose, would require potentially long lists of items, and would allow for discussions regarding what other items are not included.

Standardized verbiage based on CMET type

• universal: used where the receiver is assumed to need all the data about the <domain name>
• identified and informational: used where the receiver is assumed to have one of the identifiers of the sender system
• contactable: used where the receiver is assumed to need to communicate with the person or organization (e.g. via phone, email, or postal mail)
• identified and confirmable: used in cases where the receiver may not have any of the identifiers and requires non-identifier attributes to match
• informational: used in cases where the receiver doesn’t require an identifier to process the message
• minimal: <no standard verbiage suggested>
• identified: used in cases of closely coupled systems where the receiver will have access to any needed information merely by receiving the identifier