Query ERRORs in Normative Editions

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.

A bit of history: InM has accepted motions to discourage the use of the ParameterList stub, and to encourage the use of the QueryByParemeter stub. We didn't want to have two ways of binding query parameters. We met some resistance at the time, which is the sole reason why the ParameterList stub did end up in the standard anyway. Rene spronk 00:50, 19 July 2007 (CDT)

Alternative Strategies

The following alternatives have been suggested. They are listed here with their pros and cons.

1. 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.
2. 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.
3. Require CR to define a query structure that combines the ParameterList content of each of their domain queries with an empty QueryByParameter root and then refer to these queries in the Query response wrappers.
   • CON: This an ugly work-around that requires the committee to maintain duplicate content in two different queries.
4. Define and publish a non-normative solution that can be used by implementers until that solution is adopted, and thereby made normative.
   • PRO: This is a proactive solution that allows implementers to use the Normative content that has been carefully constructed by CR.
   • PRO: This solution can be defined by either I&M or FM since it would be a proper sub-set of the QUQI DMIM.
   • PRO: The solution will provide correctly assembled schemas for the implementer to use.
   • CON: The proposed solution will be "rushed" and therefore cannot receive full committee review.
5. Require CR to extend their current query R-MIMs with a QueryByParameter class, and to use the query wrappers based on the QueryByParameter stub.
   • PRO: The solution will provide correctly assembled schemas for the implementer to use.
   • PRO: This is a fully backwards compatible change with regard to the current CR material, it doesn't change the format on the wire in any way, no ballot required.
   • CON: This is not "backwards" compatible. The existing queries are defined message types with a root class of ParameterList. It is not backward compatible for two reasons: (a) because "extending" the message type is not a constraint and therefore requires a new query message type to be defined, and (b) because they must re-define their Query Request interactions to use the QBP request instead of the PL query request.
     • (Rene) I'd challenge that. The overall "composite message model" doesn't change at all. The only thing that changes are the places where the various bits of modeling are strung together. If I were to replace a bunch of classes in an R-MIM with a CMET that contains the exact same classes, does that constiture a compatibility issue? At the end of the day the composite abstract model is one and the same, and the format on the wire (regardless of ITS) will be one and the same.

Candidate design for Final Alternative

A candidate design has been created for the last alternative. The design uses a QUQI identifier and is derived directly from the RMIM used to create the original Query response.

This is the candidate design. Click on the diagram for the full image.

This design places the current QueryByParameter "stub" in a choice box (see DesignNote below). along with another QueryByParameter clone that links to a ParameterList stub.

Current testing is creating three different message types from this RMIM:

• QUQI_MT121000UV01 - leaves the choice in place. (Am unsure whether the Generator will produce the correct schema bindings this way.)
• QUQI_MT121001UV01 - Excludes the QueryParameterList choice, and thus is functionally identical to the current query response wrapper
• QUQI_MT121002UV01 - Excludes the QueryByParameter choice, and thus is provides a wrapper for use with the ParameterList interactions of CR.

DesignNote

Although the Visio diagram shows a choice box, the current RMIM Designer Tool will not properly process the association from the ControlAct to the choice box. Therefore the actual HMD is manually constructed in the design repository using RoseTree.