Query Parameters

to be transformed..

> (a) 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).

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

> (b) 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.

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.

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.

> (c) 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?

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." 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 taling 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 QueryByParemeter) is known and on the to-do list of INM. See http://informatics.mayo.edu/wiki/index.php/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."