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

Harmonization: turn ParameterItem.semanticsText into a mandatory attribute

From HL7Wiki
Revision as of 17:48, 17 September 2006 by Rene spronk (talk | contribs)
Jump to navigation Jump to search

Editing of harmonisation proposals prior to a harmonization meeting is restricted to the proposal submitter and the co-chairs of the steward comittee. Other changes will be undone. Please add comments to the "discussion" page associated with this proposal.

Recommendation for HL7 RIM Change RECOMMENDATION ID:
Submitted by: INM Revision (# and date): 20060509
Date submitted: Committee status: Approved - 20060509
Submitted by: Rene Spronk  
NAME: turn ParameterItem.semanticsText into a mandatory attribute  

Stewards Position

REQUIRED - This table should contain one row for each Steward Committee affected by the recommendation.

TC RECOMMENDATION APPROVAL STATUS AFFECTED ENTITIES OF INTEREST TO TC
(responsibility level: S=Steward; I=Interested)
INM Under review S

Issue

  1. The parameterItem RIM class is defined to be a key/value pair. The v3 design principle states that when it comes to the interpretation of RIM-derived models one should be able to derive the full semantics of the model without having to look at the names of cloned classes. Queries as defined by committees quite often contain parameterItem clones without a semanticsText attribute. This way a value is conveyed without an underlying key.
  2. The use of Templates/TemplateId requires some kind of "code" to be present in the class.

Recommendation(s)

  • Create new mandatory attribute parameterItem.parameterType (CV), and to declare parameterItem.semanticsText to be deprecated. The value of semanticsText is effectively used as a code. A drawback is that one has to send the root OID, which will almost always be the OID of an HL7 (Universal) vocabulary.

Backwards compatibility: there are no backwards compatibility issues. Those able to process the old (erroneous) queries [there are some that have already gone normative] will certainly be able to process the new queries (with parameterType).

Rationale

All paremeterItem derived classes have to have the parameterType attribute with a predefined (default) value. The only circumstance where a parameterItem-clone would not have to have parameterType is a query that has only 1 parameterItem.

The RIM states that parameterItem is a name-value pair. ParameterType contains the "name" part of the name-value pair. See the "Link between parameterItem and RIM attributes" section of the Query Parameters Wiki page for a discussion on how to define the semantics associated with a parameter.

Note that although widely used by implementers of XML v3 Interactions, the name of the class-clone does not carry any semantic meaning and therefore can't be used (in abstract models, like R-MIMs) to distinguish between one parameterItem clone and another one. Using the className is XML ITS specific.

Recommended Action Items

  • Implement the proposed solution

Discussion

See the discussion page for discussions related to a prior version of this proposal.


Resolution