Harmonization: add QuerySpec.responseTemplateId attribute

Editing of harmonization 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:
Sponsored by: INM	Approval date by committee: See Nature of ParameterItem .
Revision (# and date): 20061206	Date submitted:
Editor/Author: Rene Spronk
PROPOSALNAME: create new Scope related parameter class

Stewards Position

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

Issue

INM has accepted a motion to state that "The ParameterItem class cannot be used to constrain scope by columns". " (i.e. constrain the scope of the model in a query response interaction). To use an analogy: if a v3 query by parameter query is expressed as a "SELECT x,y FROM <server database> WHERE a=1 AND b=2", then the use of ParameterItem is limited to a and b.

We need to introduce a new way to identify x and y ("the columns"). This proposal introduces a way to convey information related to the desired scoe of the response model (“the selection of columns”).

Recommendation(s)

• Add a new responseTemplateId attribute to the existing QuerySpec RIM class, with the following description:
  • responseTemplateId:: SET<II> (0..*), with the definition:”The identification of a set of template-defined constraints the response SHOULD comply to. The value of this attribute provides a unique identifier for the templates in question.” Note: SHOULD, not SHALL. Compliance with the requested constraint in scope is considered to be optional in the UV standard, implementation guides (the Query Profile as published by a query server) could specify the realm- or implementation specific use of this attribute.

Given the defrinition of QuerySpec (This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class specification.) it seems to be the correct place for this type of attribute. In a sense the new attribute is akin the (now deprecated, see harmonization proposal xxxx) QuerySpec.responseElementGroupId attribute. That attribute contained identifiers of Message Types, the proposed attribute contains Template IDs.

Alternative solutions (considered, but not proposed):

• Add a new “blue class” called “ScopeControl” to convey the responseTemplateIds. Associate the new class with the QueryByParameter class (0..1 for each QueryByParameter class).
• instead of adding a responseTemplateId attribute (SET<II>), a scopeTypeCode attribute could be used, CWE CV.
• somhow combine the functionality of the existing SortControl class with the functionality as required by the new use-case. Both identify requested behaviour of the query server application.

RIM Recommendation(s)

• Add the new attribute to the QuerySpec class as described above.

This proposal is known to have an impact on normative queries that are using ParameterItem to constrain the scope of the response model. Adoption of this proposal would mean that those query interactions have to be corrected.

Vocabulary Recommendation(s)

• None.

Rationale

The Receiver Responsibilities of an interaction indicate the response interaction and also the Message Type (the static model) contained in that response interaction. The static model (the scope thereof) contained in a response is uniquely determined by the initial interaction.

During the May2006 ballot cycle an issue related to the correct usage of the ParameterItem RIM class came up as part of the ballot reconciliation of a couple of committees. Can one use a ParameterItem to define a query that specifies the scope of the response? Example: a committee has defined a query with a 0..* ParameterItem class to identify the classes they’d like to see returned in the response model. This effectively allows a sender to indicate a subset of the response model to be returned. INM has adopted a motion not to allow the ParameterItem class to be used for this purpose, as it causes a conflict with the basic principle that the response model is uniquely determined by the response interaction. The requirement to return a subset of an existing Message Type could be met by defining a new Message Type, and a new interaction that contains the new message type. In recognition of the use-case INM adopted a motion to support it by “introduc[ing] a new blue class, and for the receiver to make the best effort to comply with its values”. (Note that ultimately a new attribute is proposed in the harmonization proposal instead of a new class). Compliance with the requested constraint in scope is considered to be optional in the UV standard, implementation guides could specify the realm- or implementation specific use of this class.

• See the "Nature of ParameterItem" HL7 Wiki page for details of the discussion within the INM committee about the use of ParameterItem.

Recommended Action Items

• Implement the proposed solution