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 Potion 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. 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. 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. Comittees would have to bring forward a strong use-case for option 1 (which has no explicitly documented HL7 v2 precendent) for it to be considered in earnest.