This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Nature of ParameterItem"

From HL7Wiki
Jump to navigation Jump to search
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{INM Finalized Workitem}}
 +
{{INM Approval|2006-07-21 16:00 US Eastern|ParameterItem cannot.be used to constrain scope by columns. It is noted that this clarification will impact existing normative material. Joann Larson / Sandy Stuart, 5-1-1}}
 +
{{INM Approval|20060807 15:48 US Eastern|Motion to introduce a new blue class, and for the receiver to make the best effort to comply with its values. Matthew Mores/Pete Gilbert 4-0-0}}
 
During the May2006 ballot cycle an issue related to the correct usage of the ParameterItem RIM class came up as part of the ballot reconciliation of a couple of committees.
 
During the May2006 ballot cycle an issue related to the correct usage of the ParameterItem RIM class came up as part of the ballot reconciliation of a couple of committees.
 
Can one use a ParameterItem to define a query that specifies the scope of the response? Example: a committee has defined a query with a 0..* ParameterItem class to identify the classes they’d like to see returned in the response model.
 
Can one use a ParameterItem to define a query that specifies the scope of the response? Example: a committee has defined a query with a 0..* ParameterItem class to identify the classes they’d like to see returned in the response model.
 +
 +
See [[Harmonization: create new Scope related parameter class]].
  
 
== Background Documentation ==
 
== Background Documentation ==
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."  
+
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." The interpretation of this description is regarded by some to be ambiguous.
  
The interpretation of the above description is regarded by some to be ambiguous.
+
Conclusion (after discussion and motions): The description in the RIM is such (valued element .. [as] specified in the query response) that one can not use a parameterItem class to limit the scope of the response message. The RIM description of ParameterItem should be changed to explicitely reflect this. If we regard a query as the equivalent of a "SELECT x,y,z FROM database WHERE a=1 and b=2" then all parameterItems are the equivalent of the WHERE clause.
  
HL7 version 2 supports multiple styles of queries.  
+
Solution for the underlying use-case (which as concluded by the committee can't be covered by pareneterItem):
 +
*Define a new blue class (a RIM change), and to associate it with QueryByParameter, much akin to the sortControl class, to allow the sender of a query to specify what parts of the response model it would like to receive. (e.g. values like: mimimal, default, maximum). The receiver (if it supports this new functionality) will make an effort to respond with the requested level of detail, but does not have to do so if it doesn’t support that level of detail. Realm or interaction profiles may specify that the support for certain values is mandatory, but the universal standard won't.
 +
**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.
 +
 
 +
== Discussion ==
 +
 
 +
:My reason for supporting the creation of a new class is a) conceptually the SELECT and the WHERE parts of a query are quite different things, b)  from an implementation perspective I don't like SELECT clauses: they needlessly complicate things for the system responding to queries (its easier to just respond with the full scope, the querying system can make its own selection) c) from a dynamic perspective a SELECT clause is problematic: the interaction determines as part of its receiver responsibilities what the response interaction (and therefore response static model) is. A SELECT statement effectively changes the receiver responsibilities in that it forces the receiver to use a different static model. I can live with a new SELECT type query class. [[User:Rene spronk|Rene spronk]] 13:39, 13 Jun 2006 (CDT)
 +
 
 +
::We have a strong requirement to be able to toggle on and off certain pieces of a response.  This does *not* involve changing the message type.  The message type remains identical.  The sending application simply chooses to filter different parts of the response based on the query parameters.  This filtering of data needs to happen even in the absence of query parameters because of the need to filter what type of data is exposed based on what the receiving application is authorized to look at.  If the parameters indicate that filtering need to occur, then conformant applications are obligated to do the filtering. If they're in the spec as optional parameters, you can choose whether to support.  If they're in as required, you must support them or not support the interaction.  In general, if a committee chooses to include parameters like this, they should be 'required' because making a request to exclude data when that request might be ignored isn't terribly useful. [[User:Lmckenzi|Lloyd McKenzie]]
 +
 
 +
:::This scenario sounds a bit like anonymization or de-identification for research purposes? Even though the sender is entitled to view the data (security and privacy are normally the receiver's responsibility), it nevertheless requests that portions of the response should be filtered out. I disagree that the new SELECT type query class must be 'required' for all conformant receivers, in order to support this use case. Consider a sender '''''A''''' that requires a filtered message, and a receiver '''''B''''' that lacks the necessary sophistication to perform filtering on the requested attributes. Surely the filtering could be performed by an intermediary or gateway server '''''C'''''? [[User:MattM|Matt Moores]] 20:11, 10 Aug 2006 (CDT)
 +
 
 +
==v2 notes==
 +
HL7 version 2 supports multiple styles of queries. The use of queries in v2 is relevant to this discussion; the use-cases and solutions used in v2 have been used as a basis for the creation of the query RIM classes in v3.
 
*Parameters in Query by Example and Virtual Table queries are uniquely linked to elements contained in the response message. For example (HL7 2.5), see section 5.10.5.8.5: "''This field conveys the same information as the "WHERE" clause in the corresponding SQL expression of the query, but is formatted differently''"
 
*Parameters in Query by Example and Virtual Table queries are uniquely linked to elements contained in the response message. For example (HL7 2.5), see section 5.10.5.8.5: "''This field conveys the same information as the "WHERE" clause in the corresponding SQL expression of the query, but is formatted differently''"
 
*The QPD segment and queries that use embedded SQL statements allow for all kinds of parameters.
 
*The QPD segment and queries that use embedded SQL statements allow for all kinds of parameters.
 
*Next to the query parameter segment (e.g. QBP, VTQ) v2 queries have a <u>separate</u> segment which limits the number of 'columns' in the response (HL7 2.5, section 5.5.7) ''[RDF is] an optional segment in a query [..snip..], this segment can be used to limit the number of columns returned and to specify what column positions the fields occupy (where supported, these features can be used to override the defaults for the particular query).  If omitted, all fields defined for the query are returned in their default column order.''
 
*Next to the query parameter segment (e.g. QBP, VTQ) v2 queries have a <u>separate</u> segment which limits the number of 'columns' in the response (HL7 2.5, section 5.5.7) ''[RDF is] an optional segment in a query [..snip..], this segment can be used to limit the number of columns returned and to specify what column positions the fields occupy (where supported, these features can be used to override the defaults for the particular query).  If omitted, all fields defined for the query are returned in their default column order.''
 
==Position 1: ParameterItem can be used to constrain scope==
 
The description in the RIM is such that ParameterItem can be used to convey any piece of information that the responding system should use to determine what it should respond with. The RIM description of ParameterItem should be changed to reflect this.
 
If we regard a query as the equivalent of a "SELECT x,y,z FROM database WHERE a=1 and b=2" then x,y,z ,a and b are parameterItems.
 
 
==Position 2: ParameterItem can’t be used to constrain scope ==
 
The description in the RIM is such (valued element .. [as] specified in the query response) that one can not use a parameterItem class to limit the scope of the response message. The RIM description of ParameterItem should be changed to explicitely reflect this.
 
If we regard a query as the equivalent of a "SELECT x,y,z FROM database WHERE a=1 and b=2" then all parameterItems are the equivalent of the WHERE clause.
 
 
===Solution for the use-case===
 
If we agree that Potion 2 is the correct interpretation of the (intent) of the RIM class, the there are (at least) 2 possible ways to deal with the use-case of wanting to constrain the scope of the response model in a query:
 
#Define a new blue class (a RIM change), and to associate it with QueryByParameter, much akin to the sortControl class, to allow the sender of a query to specify what parts of the response model it would like to receive. (e.g. values like: mimimal, default, maximum). The receiver (if it supports this new functionality) will make an effort to respond with the requested level of detail, but does not have to do so if it doesn’t support that 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.
 
#Committees creating queries should specify a minimum number of attributes that must be supported in the query response R-MIM and possibly allow for a reasonable set of others that are optional. A query-interaction has a Receiver Responsibility associated with it, which is an interaction containing the query response R-MIM. A receiving system must indicate in their conformance profile which of the "optional" query response R-MIM attributes they'll return.
 
Option 2 can be implemented today, and is in line with the way queries have been used in HL7 v2. Comittees would have to bring forward a strong use-case for option 1 (which has no explicitly documented HL7 v2 precendent) for it to be considered in earnest.
 

Latest revision as of 00:15, 15 September 2006

During the May2006 ballot cycle an issue related to the correct usage of the ParameterItem RIM class came up as part of the ballot reconciliation of a couple of committees. Can one use a ParameterItem to define a query that specifies the scope of the response? Example: a committee has defined a query with a 0..* ParameterItem class to identify the classes they’d like to see returned in the response model.

See Harmonization: create new Scope related parameter class.

Background Documentation

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." The interpretation of this description is regarded by some to be ambiguous.

Conclusion (after discussion and motions): The description in the RIM is such (valued element .. [as] specified in the query response) that one can not use a parameterItem class to limit the scope of the response message. The RIM description of ParameterItem should be changed to explicitely reflect this. If we regard a query as the equivalent of a "SELECT x,y,z FROM database WHERE a=1 and b=2" then all parameterItems are the equivalent of the WHERE clause.

Solution for the underlying use-case (which as concluded by the committee can't be covered by pareneterItem):

  • Define a new blue class (a RIM change), and to associate it with QueryByParameter, much akin to the sortControl class, to allow the sender of a query to specify what parts of the response model it would like to receive. (e.g. values like: mimimal, default, maximum). The receiver (if it supports this new functionality) will make an effort to respond with the requested level of detail, but does not have to do so if it doesn’t support that level of detail. Realm or interaction profiles may specify that the support for certain values is mandatory, but the universal standard won't.
    • 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.

Discussion

My reason for supporting the creation of a new class is a) conceptually the SELECT and the WHERE parts of a query are quite different things, b) from an implementation perspective I don't like SELECT clauses: they needlessly complicate things for the system responding to queries (its easier to just respond with the full scope, the querying system can make its own selection) c) from a dynamic perspective a SELECT clause is problematic: the interaction determines as part of its receiver responsibilities what the response interaction (and therefore response static model) is. A SELECT statement effectively changes the receiver responsibilities in that it forces the receiver to use a different static model. I can live with a new SELECT type query class. Rene spronk 13:39, 13 Jun 2006 (CDT)
We have a strong requirement to be able to toggle on and off certain pieces of a response. This does *not* involve changing the message type. The message type remains identical. The sending application simply chooses to filter different parts of the response based on the query parameters. This filtering of data needs to happen even in the absence of query parameters because of the need to filter what type of data is exposed based on what the receiving application is authorized to look at. If the parameters indicate that filtering need to occur, then conformant applications are obligated to do the filtering. If they're in the spec as optional parameters, you can choose whether to support. If they're in as required, you must support them or not support the interaction. In general, if a committee chooses to include parameters like this, they should be 'required' because making a request to exclude data when that request might be ignored isn't terribly useful. Lloyd McKenzie
This scenario sounds a bit like anonymization or de-identification for research purposes? Even though the sender is entitled to view the data (security and privacy are normally the receiver's responsibility), it nevertheless requests that portions of the response should be filtered out. I disagree that the new SELECT type query class must be 'required' for all conformant receivers, in order to support this use case. Consider a sender A that requires a filtered message, and a receiver B that lacks the necessary sophistication to perform filtering on the requested attributes. Surely the filtering could be performed by an intermediary or gateway server C? Matt Moores 20:11, 10 Aug 2006 (CDT)

v2 notes

HL7 version 2 supports multiple styles of queries. The use of queries in v2 is relevant to this discussion; the use-cases and solutions used in v2 have been used as a basis for the creation of the query RIM classes in v3.

  • Parameters in Query by Example and Virtual Table queries are uniquely linked to elements contained in the response message. For example (HL7 2.5), see section 5.10.5.8.5: "This field conveys the same information as the "WHERE" clause in the corresponding SQL expression of the query, but is formatted differently"
  • The QPD segment and queries that use embedded SQL statements allow for all kinds of parameters.
  • Next to the query parameter segment (e.g. QBP, VTQ) v2 queries have a separate segment which limits the number of 'columns' in the response (HL7 2.5, section 5.5.7) [RDF is] an optional segment in a query [..snip..], this segment can be used to limit the number of columns returned and to specify what column positions the fields occupy (where supported, these features can be used to override the defaults for the particular query). If omitted, all fields defined for the query are returned in their default column order.