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.

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 the above description is regarded by some to be ambiguous.

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.

Position 1: ParameterItem can be used to constrain scope

The description in the RIM is such that ParameterItem can be used to convey any piece of information that the responding system should use to determine what it should respond with. The RIM description of ParameterItem should be changed to 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 x,y,z ,a and b are parameterItems.

Position 2: ParameterItem can’t be used to constrain scope

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 use-case

If we agree that Position 2 is the correct interpretation of the (intent) of the RIM class, the there are (at least) 2 possible ways to deal with the use-case of wanting to constrain the scope of the response model in a query:

1. 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.
   1. 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.
   2. Creating a separate class has a precedent in v2: the RDF segment is used by the sender to control the scope of the response
2. Committees creating queries should specify a minimum number of attributes that must be supported in the query response R-MIM and possibly allow for a reasonable set of others that are optional. A query-interaction has a Receiver Responsibility associated with it, which is an interaction containing the query response R-MIM. A receiving system must indicate in their conformance profile which of the "optional" query response R-MIM attributes they'll return.

Option 2 can be implemented today, and is in line with the way queries have been used in HL7 v2.

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