|
|
| (4 intermediate revisions by the same user not shown) |
| Line 5: |
Line 5: |
| | =CMET Balloting= | | =CMET Balloting= |
| | | | |
| − | CMET: A_Encounter universal | + | ==History== |
| | + | CMETs Release 1 was comprised of a full set of CMETs covering many domains and were balloted as a block. Modelling & Methodology was work group responsible for managing the ballot process. CMETs Release 2 provided additional CMET from Release 1 (release 2 was cumulative with the release 1 CMETs). The cumulative mechanism was adopted for releases of CMETs going forward. |
| | | | |
| − | :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.
| + | Release 1 and Release 2 were submitted for ANSI certification. Unfortunately following these two releases, the submissions to ANSI were not kept up to date with the actual balloting of CMETs. CMET Release 3 to 9 were balloted but submitted. |
| | | | |
| | + | For a period of time, CMET Releases seemed to be numbered in conjunction with Normative Edition releases. For example, CMET Release 5 came out as part of Normative Edition 2005. When no new release of CMETs was provided in Normative Edition 2008 but a new release of CMETs was done for Normative Edition 2009, most people simply skipped Release 8 creating further confusion in the CMET release names. |
| | | | |
| − | CMET: A_Encounter minimal | + | When it was discovered that the CMET releases needed to be submitted to ANSI, it was decided to re-ballot Releases 3 through 9 with an up-down ballot. |
| | | | |
| − | :Description: Used to identify a specific patient encounter in the event mood.
| + | ==Guidelines== |
| − | | |
| − | | |
| − | 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
| |
Last Updated: March 26, 2014
CMET Balloting
History
CMETs Release 1 was comprised of a full set of CMETs covering many domains and were balloted as a block. Modelling & Methodology was work group responsible for managing the ballot process. CMETs Release 2 provided additional CMET from Release 1 (release 2 was cumulative with the release 1 CMETs). The cumulative mechanism was adopted for releases of CMETs going forward.
Release 1 and Release 2 were submitted for ANSI certification. Unfortunately following these two releases, the submissions to ANSI were not kept up to date with the actual balloting of CMETs. CMET Release 3 to 9 were balloted but submitted.
For a period of time, CMET Releases seemed to be numbered in conjunction with Normative Edition releases. For example, CMET Release 5 came out as part of Normative Edition 2005. When no new release of CMETs was provided in Normative Edition 2008 but a new release of CMETs was done for Normative Edition 2009, most people simply skipped Release 8 creating further confusion in the CMET release names.
When it was discovered that the CMET releases needed to be submitted to ANSI, it was decided to re-ballot Releases 3 through 9 with an up-down ballot.
Guidelines
