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 contains 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

Fuzzy Parameter Matching

How does one search with information that is known to be "fuzzy" or incomplete, e.g. because one used wildcards, or a phonetic approximation of someones family name? The issue is wider in scope than just in parameters: it may also apply to updates of a registry, if the name is known to be fuzzy and incorrect.

There are 2 possible approaches to this:

1. Add a "match type" attribute to ParameterItem. Then we could say things like "exactMatch", "specialization", "exactOrSpecialization", "wildcard", "regex", or other things. This option has two disadvantages:
   1. It does not solve the use-case related to fuzzy names in registries, it only solves the query parameter use-case
   2. It would increase the complexity of the interpretation of queries, and it may encourage bad behaviour like searching for "a phonetic root OID", "a regexp for a code starting with a certain chacter" - at the same time we're telling people that OIDs and codes are meaningless numbers.
2. Define a use-code for those data types where there are known use-cases for (a) fuzzy searches, or (b) fuzzy data storage requirements (like registering a person using a name that is known to be phonetic). *IF* there is a use case for it, it should be determined on a datatype-by-datatype basis how we deal with search/wildcard/phonetic values.
   1. Names: There are existing use-codes for names that should be used when searching on names (part of the EN data type specification): SRCH search A name intended for use in searching or matching, PHON phonetic A name spelled phonetically. This means that we can cover use-cases related to name searches of entities. (SRCH uses wildcards, PHON can be used when one knows the spelling of the name is approximate, i.e. "virhogen" instead of "Verheugen" - as phonetically understood by the person responsible for data entry)
   2. Addresses: To have the same capability for addresses (one of the other data types where there is a known use-case for phonetic and wildcard searches) we'd need to add new use codes to the AD datatype.
   3. Codes: Wilcard searches for code values have not been discussed before; although one could create a parameter called "codeSystem" to convey the codeSystem without a code extension. (this would be like searching for a "*" code from that codeSystem)

Interpretation of omitted data type parts

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

Link between parameterItem and RIM attributes

1. 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.
2. Should a parameter always map to 1 single attribute?
3. How does one value semantcsText in case of multiple matching attributes?

From the RIM:

• ParameterItem.value :: ANY (0..1) - Definition:Provides the value for the valued element structure (name-value pair) for the element specified in the query response.
• ParameterItem.semanticsText :: ST (0..1) - Definition:Provides a unique identification (the name of the name-value pair) to an element within a specified query response structure.

The QUQI D-MIM walkthrough states: Query definitions in the application domains state how the value and semanticsText attributes are to be populated. The following is the description and use of the attributes for this class.

• id: can assist in tracing problems with implementing the query-by-parameter mechanism
• value: represents a valued element structure for the element specified in the query response
• semanticsText: provides a unique identification to an element within a specified query response structure

Question 1: Yes, you can define a "name" parameter, as long as you define clearly in the query interaction what the intended behaviour 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.

Question 2: There is no requirement that a parameter matches a single attribute as contained in the static model of the response. It may be true for most use-cases, but there is no such requirement. A parameter does NOT have to match 1 individual D-MIM attribute, as long as the relationship can be defined in a computational manner.

• an example from PA: mothersMaidenName. This is a parameter in one of PA's queries, although (as a concept) is it pretty difficult (but not impossible) to state where its value is located in v3 models, and it is actually not contained in the response to the query where the parameter is used.
• another example from PA, based on Patient Registries: the static model contains a LivingSubject entity, the Patient role played by the living subject, and other roles played by the LivingSubject (the OtherIDs class). A parameter could be created that maps to the set of {Patient.id, OtherIDs.id} which is a computable an exhaustive set, and both of which are Role.IDs.

Question 3: Although it is a well established best practice to use the attribute name a parameter is linked to as a value for semanticsText, there is no requirement to do so. Any string which identifies this particular type of parameterItem class is a valid one. Each ParemeterItem class contains a key/value pair, whereby the key is semanticsText. (and not as some assume: the name of the class).

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" then 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 (which has no HL7 v2 precendent) for it to be considered in earnest.