One of the outstanding questions that the C-CDA project has to address is whether the 2.1 DSTU will require backwards compatibility only, or whether there will be a mode supporting backwards compatibility, and a mode where C-CDA 2.0 constraints are simply adopted. We haven't made a decision yet.
Some would argue that supporting backwards compatibility only will simplify the guide for people. I have argued that will require HL7 to create a new project further down the line, and will not enable C-CDA 2.1 to be used in projects which are presently dependent upon C-CDA 2.0, some of which, like QRDA, also have a regulatory component naming a version of the standard.
To move forward, I will be proposing the following wording be adopted in constraints that are added to support backwards compatibility:
Some would argue that supporting backwards compatibility only will simplify the guide for people. I have argued that will require HL7 to create a new project further down the line, and will not enable C-CDA 2.1 to be used in projects which are presently dependent upon C-CDA 2.0, some of which, like QRDA, also have a regulatory component naming a version of the standard.
To move forward, I will be proposing the following wording be adopted in constraints that are added to support backwards compatibility:
To support backwards compatibility, XXX SHALL/SHOULD/MAY YYYThis highlights the constraints added to support backwards compatibility. Then we add language to the top of the specification depending upon which choice we make:
- If we choose backwards compatibility only, we state:
This specification adds constraints supporting backwards compatibility. These constraints are identified by beginning with the phrase "To support backwards compatibility", and are otherwise equivalent to any other constraint. - If we choose to support both, we state:
This specification adds constraints supporting backwards compatibility. These constraints are identified by beginning with the phrase "To support backwards compatibility." These are conditional constraints. When a document instance declares that it is supporting backwards compatibility by [mechanism to be established], these constraints must also be followed.
This will allow the project team to create the constraints now, and make the choice later about whether these constraints are conditional or not.
HL7 is looking for feedback on this. If you are a member of the Structured Documents mailing list, you can provide your feedback there, or on next weeks Thursday call, or on tomorrows C-CDA 2.1 DSTU Update project call. As always, any feedback you provide in comments here, I will also forward to the workgroup, supporting them as best as I am able even though I have my own preferences.
Personally, I could still be convinced for option 1 by an argument that resonates with my own concerns, but am still strongly leaning towards option 2.
I send the following to the SD list this afternoon after this post generated some great feedback.
ReplyDelete-----------------
I think I’ve worked out another option for downstream dependencies that allays my concerns about option 2 and makes option 1 viable.
Those IG’s with downstream dependencies on C-CDA Release 2.0 that want backwards compatibility can reference templates in C-CDA 2.1. Those that want both can reference C-CDA 2.1 and C-CDA 2.0.
Since we are adding no net new templates, this seems like it should work. As for having to update C-CDA 2.1 when backwards compatibility is not required, it simply means that people can go back to referencing C-CDA 2.0.
I’m not totally happy with this notion, because I think that going backwards is confusing, BUT, I can live with it.
NOTE: I still think it would be valuable to implementers to identify the material that is present to support backwards compatibility. This could just be a simple mark, like an asterisk or dagger, noting that the presence of the template is to support backwards compatibility.
From my perspective, my developers will need to create code that supports both capabilities in any case [because there are other guides that will be calling on C-CDA 2.0], so knowing what code is needed for the backwards compatible stuff lets them manage their implementations better. But it need not be worded in a way that would make it seem like a conditional constraint.
Keith