Difference between revisions of "Add attribute to QueryByParameter class"
| Line 8: | Line 8: | ||
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. | 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 | + | ==Use case== |
| − | [[AORTA]], the Dutch national infrastructure for the exchange of | + | [[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 | + | 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 the data that was authored or generated by X) or should it be ''exclusive'' (excluding the data that was authored or generated by X)? |
| − | The default | + | 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: | |
| − | |||
| − | |||
| − | Note that the ''exclusion'' | + | * 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== | ==Proposal== | ||
Revision as of 14:27, 22 August 2008
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
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) 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 the data that was authored or generated by X) or should it be exclusive (excluding the 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.
- 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.
