Harmonization: turn ParameterItem.semanticsText into a mandatory attribute

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.
  • parameterType gets a fixed value assigned to it at committee design-time.

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.

(Lloyd) I would support such a proposal, but only if the ITS didn't require sending it over the wire. I'm also not sure that semanticsText needs to be deprecated. Conceptually, I'd like to hold out hope that we'll get our constraint language that allows us to formally express the semantics of a query parameter. Once there, we can look at making the element mandatory.

(Rene) It would be a "structural attribute" which (just like other structural codes) need not be sent on the wire.

(Grahame): hang on. using templates with parameterized queries would be a good idea. If we want this, we need slightly different rules - the parameterType need not be set by committee. In fact, the committee stage is too early - forcing committees to always define all the parameterTypes would mean that at times they would have to create more general parameter types (such as "some database field" instead of "database field x"), which would be difficult for implementers. Implementors don't want to confront templated queries at run-time, but need to do so at application design time. This has implications for templates which are taken up in the template specification. So agree to deprecate semanticsText, and create parameterType, but let committees define parameterType where suitable. When committees define parameterType, it won't be sent over the wire unless fixed and default values are being sent.