This post is in response to discussions held recently within the HL7 Structured Documents Work Group (SDWG) on how to treat additions/updates to the HL7 Consolidated Clinical Document Architecture (C-CDA) specification. 

The current Draft Standard for Trial Use (DSTU) originated with a clearly delineated scope – primarily, combine 9 existing CDA Implementation Guides (IGs), updated to support Meaningful Use (MU) Stage 1 references to C32 consistently, and providing a single go-to place that incorporates work referenced by HL7, IHE and HITSP. Mission accomplished!

Today, C-CDA is a work in its own right, cited by the NPRM and anticipated as part of the Final Rule for Stage 2 MU.  Several proposals have come forward to augment C-CDA with additional templates. SDWG has taken the position that new templates supporting long term care will be added in an addendum rather than integrated into a new release of the spec.

I think this position needs to be reconsidered both as a general course and for the specific material. Here’s why:

• Lack of clarity on status: Specs need clear boundaries – something is or is not part of the spec. The status of material balloted as a “DSTU,” but put into addenda is unclear. Is it or isn’t it part of the spec?
• Kicks the can down the road: The material in the addenda will be folded into the spec at a later time. This leaves the work of ensuring consistency to a second, unscheduled stage. It is unclear what value the balloting of this material will provide if it is subject to change during a harmonization/consolidation stage further down the road. This does not provide the stability and consistency that we need to provide to implementers who are looking to use this material now.
• We need to be ahead of the regulatory process, not scrambling to catch up: Regulations will cite a version of the spec providing stability for implementers. That version should be published and available in advance of this citation. Regulations need not cite every version, but the new versions need to be available in advance of the rule making process. The rule making process, as we are learning, has its own timetable and dynamic and can’t flex to wait for ink to dry on a standard. We should be updating this spec continually, and regulation can set its own pace for when it cites a particular version.
• Precedent: There is none that I know of for handling an HL7 spec in this manner. There is plenty of successful precedent for updating the spec through successive ballot cycles – HAI, HL7 v2.x, two of our most widely implemented and cited specifications. In both of these cases, selected releases have been cited by regulation, at stable intervals, less frequently than the evolving specs. In both cases, implementers have the advantage of a look ahead at a stable version that is slated to be cited.
• Power of the ballot: If the process of proposing, reviewing, voting and reconciling doesn’t result in incorporation into a spec, then it loses its relevance.

I will try to summarize the arguments against updating the spec – and how I see them:

• Implementers need stability: Can’t argue with that. Releasing a completely vetted new version gives a better, longer-range look-ahead at what will likely be cited in future regulations than releasing a potentially outdated and incompletely harmonized version with new but unreconciled material in an addendum of unclear status without regard to the spec.
• Releasing new versions forces implementers to upgrade:
  • Since when? There is no onus, requirement, to upgrade to the new release unless it is advantageous to do so.
  • It is advantageous to do so if the new version has new templates that you need – the Long-Term and Post-Acute Care community needs this, and that’s why we are doing it.
  • It is advantageous to do so when cited by regulation, however, that is on a different, longer, timetable.
• It is more work to incorporate into the spec than to add as an addendum:
  • If the issues are in the time required for publication, we need to put more effort into the tools and processes, not bend our specs to fit our publishing infrastructure.
  • If the issues are that incorporation will force a more rigorous look at consistency, etc., all the more reason to do it now (see the can kicked down the road above).
• The spec would grow uncontrollably. A true danger. To address this, we need to:
  • Work at the Project Scope Statement approval process and not approve things for C-CDA that we don’t feel should be added
  • Craft a scope statement that lays out the vision, path for C-CDA’s evolution over time, beyond “it was nine things, now it is one”
• [fill in your points here!]

I have tried to lay out the issues as I see them. I hope we can get some further discussion here and again on upcoming calls.