Query Parameters

generic description to be added..

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?

(Rene) 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."

In other words: if we see 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.

What you're talking about is having the option of specifiying a SELECT clause. That's fine, but you can't use parameterItem for it (Canadian and UK projects use parameterItem - but that's not a valid usage of the class).

This use-case (which probably has to result in a new blue class associated with QueryByParameter) is known and on the to-do list of INM. See Open_Control_Act_Issues: "Add a new RIM class (associated with QueryByParemeter, akin to sortControl) to allow the sender of a query to specify what parts of the response model it would like to receive. Possible values: identified, identified/confirmable, universal (default). 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.