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

PA CMET neg

From HL7Wiki
Jump to navigation Jump to search

V3_PA_CMET_R9_N1_2009JAN Ballot Issue

Link to [[1]] ballot resolution spreadsheet.

Voter (item #4): In R_Patient [universal], it does not make sense to have any attributes with cardinality 1..1 or 1..*, since any type of specialization needs to be derivable

WG response: The WG finds this not persuasive. The WG carefully considered the minimum cardinality for each attribute and association in this model and set a minimum cardinality of 1 for only specific, justified cases

Voter response: I do NOT accept the feedback regarding R_Patient [universal]. There is a rule that all other CMET flavors should be derivable from the universal variant. Currently, your R_Patient [identified] is NOT derivable from [universal].

WG response: The following quote from the V3 Guide does seem to support the voter's position.

The attribution axis corresponds to the CMET’s message type, and always contains at least three variants:

Axis 1: Attribution

  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. detailed – this variant is a proper subset of the universal variant, and provides a named variant that may restrict the universal variant. Any of non-mandatory and non-required attributes and/or associations may be present or absent, as permitted in the cardinality constraints.
  3. identified – this variant is a proper subset of universal and detailed. Only the mandatory and required attributes and associations may appear. Other variants may not be substituted at runtime.

Other variants that are proper subsets of universal may be defined and identified along this axis. These variants tighten constraints on one or more attributes/associations of the universal variant, falling somewhere between detailed and identified.

Proposed changes

  • Mandatory Patient.id [1..*], which is optional [0..*] in [informational].
  • Required Patient.statusCode [1..1], which is not present in some other flavors.
  • Required association with EntityChoiceSubject [1..1], which is not present in [identified].
  • Required Person.name [1..*], which means having an ‘empty’ Person class is simply not possible.

Return to Agenda

PA ConCall 20090225