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: Approved (TelCon, 20061211). Approved update (Telcon, 20111024)
Revision (# and date): 20111024	Date submitted:
Editor/Author: Rene Spronk
PROPOSALNAME: add QuerySpec.responseTemplateId attribute

Stewards Position

TC	RECOMMENDATION APPROVAL STATUS	AFFECTED ENTITIES OF INTEREST TO TC (responsibility level: S=Steward; I=Interested)
INM	Approval	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: Remove ResponseElementGroupId from QueryByparameter class) 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

Discussion

MnM, 2010 Oct WGM: Discussion of Query Mechanism to specify a template for the response

• We discussed the use cases for this requirement.
• We discussed the rejected alternatives.
  • interaction per query
  • make the new template ID a parameter

• This is revising a harmonization proposal "Add QuerySpec.responseTemplateid attribute" (also on the Wiki)
  • There was a comment that we do not have a real implementation of "Query By Example" so the argument against ParameterItem due to QBE requirements was not deemed sufficient.
  • The RIM definition of ParameterItem does not preclude sending the templateID as a parameter item.
  • This seems akin to the QueryLimit information.
  • It was deemed that this proposal was the easiest
  • Currently the proposal is suggesting all templates must be satisfied. There appears to be a use case for "one of" the templates to be satisfied.
  • What should the data type be? In R1, SET<II>, in R2, QSET<II>. ACTION: Determine what the data type should be.
  • It appears that we could "undeprecate" the ResponseElementGroupId parameter that had been deprecated.

ACTION: InM will advance the harmonization proposal for the next harmonization meeting.

InM telCon 20111024

• Netherlands harmonization proposal. Motion to approve Andrew/Wendy. Vote 3-0-0