Nature of ParameterItem

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.

See Harmonization: create new Scope related parameter class.

Background Documentation

The RIM states for Parameter: "The Parameter class is an implementation class that represents the structure of parameters that may be specified with the Query-by-parameter mechanisms of the V3 query framework.", and for ParameterItem: "Represents a valued element structure (name-value pair) for the element specified in the query response." The interpretation of this description is regarded by some to be ambiguous.

Conclusion (after discussion and motions): The description in the RIM is such (valued element .. [as] specified in the query response) that one can not use a parameterItem class to limit the scope of the response message. The RIM description of ParameterItem should be changed to explicitely reflect this. If we regard a query as the equivalent of a "SELECT x,y,z FROM database WHERE a=1 and b=2" then all parameterItems are the equivalent of the WHERE clause.

Solution for the underlying use-case (which as concluded by the committee can't be covered by pareneterItem):

• Define a new blue class (a RIM change), and to associate it with QueryByParameter, much akin to the sortControl class, to allow the sender of a query to specify what parts of the response model it would like to receive. (e.g. values like: mimimal, default, maximum). The receiver (if it supports this new functionality) will make an effort to respond with the requested level of detail, but does not have to do so if it doesn’t support that level of detail. Realm or interaction profiles may specify that the support for certain values is mandatory, but the universal standard won't.
  • Note that the current thinking is not to support a detailed list of attributes the querying system would like to see in the response. This would drive the implementers of the system that have to respond to the query absolutely nuts (way too many combinatorial optionalities) and therefore seems impractical.

Discussion

My reason for supporting the creation of a new class is a) conceptually the SELECT and the WHERE parts of a query are quite different things, b) from an implementation perspective I don't like SELECT clauses: they needlessly complicate things for the system responding to queries (its easier to just respond with the full scope, the querying system can make its own selection) c) from a dynamic perspective a SELECT clause is problematic: the interaction determines as part of its receiver responsibilities what the response interaction (and therefore response static model) is. A SELECT statement effectively changes the receiver responsibilities in that it forces the receiver to use a different static model. I can live with a new SELECT type query class. Rene spronk 13:39, 13 Jun 2006 (CDT)

We have a strong requirement to be able to toggle on and off certain pieces of a response. This does *not* involve changing the message type. The message type remains identical. The sending application simply chooses to filter different parts of the response based on the query parameters. This filtering of data needs to happen even in the absence of query parameters because of the need to filter what type of data is exposed based on what the receiving application is authorized to look at. If the parameters indicate that filtering need to occur, then conformant applications are obligated to do the filtering. If they're in the spec as optional parameters, you can choose whether to support. If they're in as required, you must support them or not support the interaction. In general, if a committee chooses to include parameters like this, they should be 'required' because making a request to exclude data when that request might be ignored isn't terribly useful. Lloyd McKenzie

This scenario sounds a bit like anonymization or de-identification for research purposes? Even though the sender is entitled to view the data (security and privacy are normally the receiver's responsibility), it nevertheless requests that portions of the response should be filtered out. I disagree that the new SELECT type query class must be 'required' for all conformant receivers, in order to support this use case. Consider a sender A that requires a filtered message, and a receiver B that lacks the necessary sophistication to perform filtering on the requested attributes. Surely the filtering could be performed by an intermediary or gateway server C? Matt Moores 20:11, 10 Aug 2006 (CDT)

v2 notes

HL7 version 2 supports multiple styles of queries. The use of queries in v2 is relevant to this discussion; the use-cases and solutions used in v2 have been used as a basis for the creation of the query RIM classes in v3.

• Parameters in Query by Example and Virtual Table queries are uniquely linked to elements contained in the response message. For example (HL7 2.5), see section 5.10.5.8.5: "This field conveys the same information as the "WHERE" clause in the corresponding SQL expression of the query, but is formatted differently"
• The QPD segment and queries that use embedded SQL statements allow for all kinds of parameters.
• Next to the query parameter segment (e.g. QBP, VTQ) v2 queries have a separate segment which limits the number of 'columns' in the response (HL7 2.5, section 5.5.7) [RDF is] an optional segment in a query [..snip..], this segment can be used to limit the number of columns returned and to specify what column positions the fields occupy (where supported, these features can be used to override the defaults for the particular query). If omitted, all fields defined for the query are returned in their default column order.