Add attribute to QueryByParameter class

This is a page of type Category:InM Closed Action Items.

• Working group: InM
• Author: René Spronk, Tom de Jong, on behalf of NICTIZ, the Netherlands.
• Status: Withdrawn per e-mail from René Spronk 20100112 "It was clear from the discussions (as captured on the Wiki page of the proposal) that it wasn't going to go anywhere. The proposal is withdrawn as far as I'm concerned."

Summary

This proposal seeks to extend the (blue) QueryByParameter class with a new attribute. The purpose of the attribute is to indicate to the query processor (the responding application) whether or not it should include "data known to the originator of the query" in the query response. There are use cases for the inclusion as well as the exclusion of this data.

Use case

AORTA, the Dutch national infrastructure for the exchange of health care data, just like many other environments, offers access to centrally managed collections of health care data. In such an environment, most connected systems are both sources of data and senders of queries, so potentially, there can also be situations where a system can retrieve data that original from its own database.

Whenever System X sends a query to a centralized query processor, the query processor has to make a decision. Given that X is supposed to already know its own data: should the response that it sends back to System X be inclusive (including data that was authored or generated by X) or should it be exclusive (excluding data that was authored or generated by X)?

The default behavior in AORTA has been to exclude the data originating from the querying system in all query responses.

However, use cases are coming forward for an inclusive approach:

• In order to synchronize or check the data available in the central archive one has to have the ability to get hold of that data.
• Thin clients (used System X's organization) would like to query for all data, since they don't have access to the local database.

Note that the exclusion behavior as used in AORTA is based on a "query conformance statement" which describes how a receiver of a query processes the query. The HL7 standard itself doesn't make any statements about whether queries should be responded to in an exclusive or inclusive manner.

Proposal

Given that there are use cases for both the inclusive as exclusive behaviour of a responding system, and that the use-cases have a scope that extends to all queries, the following is proposed:

• Add a new attribute to the (blue) QueryByParameter class to indicate to the system that's processing the query whether or not it should return the "data that the sender of the query is already supposed to know".
• The attribute shall have the name: excludedSources (DISCUSSION)
• The attribute shall have a description: "indicates to the query processor whether or not it should include, to the best of the query processors knowledge, any data in the query response already known to the originator of the query. If the query processor isn't aware of the origins of the data it has on file it will return the data in the response".
• The attribute shall have the following data type (DISCUSSION)
  • SET<II>. Each II identifies the "source that is excluded".
  • Boolean. Default=True. True = inclusive. False = Exclusive. This option was rejected because xxxxx
  • Code. Default="All-inclusive". Multiple codes, ranging from "all-inclusive" via"exclusive of data known in originators department" (?) and "exclusive of data known in originators organization" (?) up to "all-exclusive". This option was rejected because xxxxx

Alternatives Considered & Rejected

• Add a new query parameter to all queries where we need to distinguish between inclusive and exclusive.
  • Rejected because this would be a change to almost all queries.

--Lmckenzi 16:53, 14 September 2008 (UTC) If you need it for queries, add it to the queries. Adding it as a generic attribute is a change to all the queries too. The argument would be the same to add patient id to query parameter because it's needed for most queries. The purposes of this new attribute is to filter the result set. The way you filter the result set is with query parameter. The problem with putting filters directly on the QueryByParameter class is that you then need two sets of wrappers - one for queries that need the attribute and one for queries that don't.

(20080917, WGM Vancouver) Mark Tucker agrees with this statement. It's a modifier to the query. Prefers to have explicit parameter. Other comments: used everywehere. It's a control parameter. Mark: things there are lots of queries that don't need such a feature. Gaby: use-case is international, should not require a national extension.

• For each and every query interaction that exists today: define that it should be processed in an inclusive fashion. Create a set of new interactions, with the very same payload models as the existing query interactions, and (in the query conformance statement) define their processing behaviour to be exclusive.
  • Rejected because this would lead to a duplication of all queries.