|
|
| Line 5: |
Line 5: |
| | =CMET Balloting= | | =CMET Balloting= |
| | | | |
| − | CMET: A_Encounter universal
| + | ==History== |
| | | | |
| − | :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.
| + | ==Guidelines== |
| − | | |
| − | | |
| − | 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
| |
