Difference between revisions of "Query ERRORs in Normative Editions"
| Line 16: | Line 16: | ||
As noted above, there are 29 query response interactions in the CR domain for which the defined query request was a ParameterList, and for which the domain attempted to bind the query to the QueryByParameter stub in the response (QUQI_MT120001UV01). This binding is not allowed by the generator as the stub and the target root are based on different RIM classes. | As noted above, there are 29 query response interactions in the CR domain for which the defined query request was a ParameterList, and for which the domain attempted to bind the query to the QueryByParameter stub in the response (QUQI_MT120001UV01). This binding is not allowed by the generator as the stub and the target root are based on different RIM classes. | ||
| + | |||
| + | ==Observation & Notes by Beeler== | ||
| + | The lack symmetry between the requests and responses suggests that this was an oversight, but I have been told that this was a conscious decision. To be truthful, I do not see how a rational argument can be made for defining two ways to define a query and only allowing one of those queries to be incorporated in the response. Further, I believe that HL7 Canada has been lobbying I&M to address this, but with limited success. | ||
| + | |||
| + | =Alternative Strategies= | ||
| + | The following alternatives have been suggested. They are listed here with their pros and cons. | ||
| + | # Declare those interactions as invalid and therefore unimplementable | ||
| + | #*'''CON:''' This negates a significant set of Normative content from CR for a flaw that is readily addressable. | ||
| + | # Simply publish a warning and let implementers figure out their own solutions. | ||
| + | #*'''PRO:''' This has the advantage of being what was done in earlier Editions. | ||
| + | #*'''CON:''' Yeah, but .... It provides no guidance to the implementers and makes it likely that each solution will be different. | ||
| + | # Define and publish a non-normative solution that can be used until that solution is adopted, and thereby made normative. | ||
| + | #*'''PRO:''' Proactive solution that allows implementers to use the Normative content that | ||
Revision as of 23:11, 18 July 2007
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.
Contents
Background
HL7 has Normative content (standards or DSTUs) that contain invalid interaction definitions because of the way that the normative Query Infrastructure (QUQI) was published by I&M and used by Financial Management. The content published with Normative Editions 2005 and 2006 contains 29 interactions from the Claims & Reimbursement domain (FICR) that contains these errors. The V3 Project Team Leader (Woody Beeler) does not want to publish Normative Edition 2007 without providing implementers with a solution (schemas) that can actually be used.
The Transitional Technical Task force has asked for solution alternatives to review that have been discussed by the interested parties. The goal is to include these on the I&M call next Monday, July 23. They will be documented here for comment and improvement
Source of the Problem
The core of the problem is the set of ControlAct wrappers that were defined in the QI domain. Specifically, there are two Query Request wrappers:
- Query Control Act Request : Parameter List(QUQI_MT020001UV01) - provides for domain committees to define their queries as a ParameterList
- Query Control Act Request : Query By Parameter(QUQI_MT021001UV01) - provides for domain queries defined from the QueryByParameter class.
The Query response wrapper Query Control Act Response / Acknowledgement(QUQI_MT120001UV01) is used to return the response payload and (optionally) query parameters in a stub whose root is QueryByParameter. (The design note on the RMIM states: "This allows for query parameters sent on a query request to be returned on a query response.")
The problem is that the current Query Response does not allow the response to include (optional) parameters in a structure whose root is ParameterList, even though the request wrappers permit the domains to define their queries as ParameterList.
As noted above, there are 29 query response interactions in the CR domain for which the defined query request was a ParameterList, and for which the domain attempted to bind the query to the QueryByParameter stub in the response (QUQI_MT120001UV01). This binding is not allowed by the generator as the stub and the target root are based on different RIM classes.
Observation & Notes by Beeler
The lack symmetry between the requests and responses suggests that this was an oversight, but I have been told that this was a conscious decision. To be truthful, I do not see how a rational argument can be made for defining two ways to define a query and only allowing one of those queries to be incorporated in the response. Further, I believe that HL7 Canada has been lobbying I&M to address this, but with limited success.
Alternative Strategies
The following alternatives have been suggested. They are listed here with their pros and cons.
- Declare those interactions as invalid and therefore unimplementable
- CON: This negates a significant set of Normative content from CR for a flaw that is readily addressable.
- Simply publish a warning and let implementers figure out their own solutions.
- PRO: This has the advantage of being what was done in earlier Editions.
- CON: Yeah, but .... It provides no guidance to the implementers and makes it likely that each solution will be different.
- Define and publish a non-normative solution that can be used until that solution is adopted, and thereby made normative.
- PRO: Proactive solution that allows implementers to use the Normative content that
