Query Parameters

Query Parameters may be set of name/value pairs, a named parameter list with a set of name/value pairs or any combination the previous two options. A Query Transmission Zero conains zero or more Query parameters.

The only query mechanism supported by HL7 v3 is Query-By-Parameter, based on a ParameterItem class for each name-value pair. According to the RIM the ParameterItem represents a valued element structure for the element specified in the query response.

FAQ

• When sending a query and one of the parameters has the Person Name datatype and if the sender includes only the LastName part of that Person Name datatype with a value such as "Daoust", should the sender expect to get back: (1) all people whose last names are Daoust, or (2) all people with a last name of Daoust and no recorded value for first name and no recorded value for first name? I believe the correct answer is (1).

(Rene) That is what I would expect as well. The formal answer to your question is however: it depends on how you, as a comittee, define the behaviour to be. As a comittee you are free to define what the non-presence of an attribute means, this could/may differ on a query by query basis.

This is the same issue as the AND/ OR logic between parameterItem classes: in principle it's entirely up to you as a comitte to define the behaviour, the most INM can do is define a rule akin to "unless defined otherwise by the interaction walkthrough, the non-presence of values for parts of datatypes does not indicate a search for a nullflavor value".

• Could a committee design a query where the parameter is "name" (having datatype Person name), and "name" means return all persons who have a matching value in either the RIM Person.name or the RIM Patient.name? I believe the correct answer is "No", a query parameter value should map to a single RIM attribute, not two or more.

(Rene)Yes, you can define a "name" parameter, as long as you define clearly in the query interaction what the intended behavious of the receiver should be. For example, that there is a fall-back mechanism to try and match it with Patient.name, and if that attribute is empty (not valued, not a nullflavor), match it with person.name.

Note: This seemingly clashes with the RIM definition of ParameterItem: "Represents a valued element structure (name-value pair) for the element specified in the query response." - we do however have a precedent form PA: mothersMaidenName. This is a parameter in one of PA's queries, although (as a concept) is it pretty difficult to state where its value is located in v3 models, and it is actually not contained in the response to the query.

SELECT x,y,z use-case

• How does a committee indicate, for example, that the query itself contains two parameter values (e.g. Person.name and Person.birthDate), but that the query response should include Person.name, Person.birthDate, Person.address, Person.genderCode?

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."

If we regard a query as the equivalent of a "SELECT x,y,z FROM database WHERE a=1 and b=2" the all parameterItems are the equivalent of the WHERE clause. The parameterItem class can't be use to specify a SELECT clause (Canadian and UK projects use parameterItem - but that's not a valid usage of the class).

There are (at least) 2 possible ways to deal with the use-case:

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. Possible values: mimimal, default, maximum. The receiver (if it supports this new functionality) will make an effort to respond with the requested 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 attribute that must be supported in the query response and possibly allow for a reasonable set of others that are optional but a receiving system must indicate in their conformance profile which of those "optional" attribute they'll return. This would make implementations easier for both senders and receivers of queries.

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 for it to be considered in earnest.