Add attribute to QueryByParameter class

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

• Working group: InM
• Author: René Spronk, Tom de Jong, on behalf of NICTIZ, the Netherlands.
• Status: DRAFT - subject to changes by the authors

Summary

This proposal seeks to extend the (blue) QueryByParemeter class with a new attribute. The purpose of the attribute is to indicate to the query processor (the responding application) whether or not is should include "data known & authored by 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 medical, just like many other enviroments, offers access to centrally managed collections of data. These collections could be clinical in nature (e.g. EHRs), or administrative (e.g. encounter data, financial data).

Whenever Party X sends a query to a centralized archive it has to make a decision. Given that X is supposed to already know it's own data: should it be inclusive (include the data that was authored or generated by X in it's response) or should it be exclusive (exclude that was authored or generated by X)?

The default behaviour in AORTA has been to exclude the data in responses to all queries (of whatever nature). Originators of queries have access to their own local data store and send query messages to get hold of information created by others.

Use-cases are however coming forward for an inclusive approach:

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

Note that the exclusion behaviour 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: (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)
  • Boolean. Default=True. True = inclusive. False = Exclusive.
  • 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"

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