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

Position of Concerned Organizations

ORG.NAME	RECOMMENDATION APPROVAL STATUS	AFFECTED ENTITIES OF INTEREST TO ORG
InM	Approved, 20060509	Query classes
MnM	Under Review	Methodology issues
ITS	Under Review	Impact on ITSs, e.g. RIM based ITS

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).

Non-blue classes: if & when "top of the RIM" classes were used for queries (which was intended in 2006; and may still happen at some point in the future), the concept of parameterType has a direct equivalent: Act.code.

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 R1 specific.

Recommended Action Items

• Implement the proposed solution

Discussion

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

(Lloyd, 2006) 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, 2009) ..if with ITS you mean XML ITS R1 then I agree. A RIM based ITS should require it to be sent on the wire.

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

(Grahame, 2006): 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.

A bit of history:

• Sometime in 2006: Proposal dropped - moot point, depends on outcome of the blue classes v. top half of RIM discussion.
• January 2009: turned into an active item again, because of issue related to Clone names by Patrick Loyd.
• January 2009: RIMBAA also has an interest in resolvong this, because of RIM based ITS. The creation of such an ITS requires that there be no dependencies on clone names.

René: it seems there are a couple of open questions which need to be resolved:

1. Is it still possible to use semanticsText as it was originally intended by means of a Constraint Language? Depending on the answer semanticsText should, or shouldn't, be deprecated.
2. Should the value of parameterType be sent over the wire? In the current XML ITS R1? In an RIM based ITS?
3. When should parameterType be valued? Should it always be valued?
   • Rene: to me the requirements of a RIM based ITS are such that in that ITS you'd always need to have a value for parameterType.