This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "CMET Maintenance and Ballot Procedures"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "Category:HowToCategory:AboutCMETs Last Updated: March 26, 2014 =CMET Balloting= CMET: A_Encounter universal :Description: Used to identify a specific patient encou...")
 
(Replaced content with "Category:HowToCategory:AboutCMETs Last Updated: March 26, 2014 =CMET Balloting= ==History== ==Guidelines==")
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
 

Revision as of 18:32, 26 March 2014

Last Updated: March 26, 2014


CMET Balloting

History

Guidelines