Recently, I helped a team of HIT vendors implement an experiment to study the new HL7 Consolidated CDA (C-CDA) Care Plan Document template. This template includes constraints on a base standard, called HL7 Clinical Document Architecture (CDA), to meet the requirements for care plan information sharing. The CDA standard is a draft standard for trial use (DSTU). DSTU status means the standard is ready for implementers to begin application and testing. The template was first introduced in C-CDA R2.0 and was not changed within C-CDA R2.1. 

To a large extent, this project revealed that the C-CDA Care Plan Document template is useful when exchanging care plan information between systems. It also uncovered serious gaps, and several opportunities to improve the standard in line with its intended purpose.  

Therein lies the problem. Today, the evolutionary path for C-CDA is uncertain at best. 

At the January 2016 HL7 Work Group meeting, the Structure Documents Work Group (SDWG), responsible for maintaining C-CDA, voted to begin generating a monthly errata package. An errata package documents known technical errors and resolutions. The new errata publishing process addresses a tightly defined subset of issue types. For DSTUs, errata packages do not address issues determined to be functional improvements. As the number of interested stakeholders grows, the C-CDA DSTU Comment process is subject to increasing pressure to address the non-errata issues submitted by HL7 Work Groups, large payers, prominent EHR vendors, government agencies, and a host of entrepreneurial players vested in the evolution of C-CDA. Debates over which issues are technical errata or new functionality may intensify, because the answer lies in the eye of the stakeholder.  

Although it’s in this “trial use” status, the C-CDA R2.1 standard is already named in what is commonly referred to as Meaningful Use Stage 3 Regulations. These regulations set functionality requirements for electronic health record systems, which must be used by providers seeking incentive payments associated with the Meaningful Use initiative. By naming release 2.1 of C-CDA, the regulations inadvertently created a catch-22; adding both pressure to adopt this new version and resistance to create newer versions of the draft standard.  

As more EHR implementers begin experimenting with, and adopting, C-CDA R2.1, HL7 will face increasing pressure to develop and release newer versions of C-CDA. What can be done to address this problem? 

A first step would be to adopt a broader model of accountability for C-CDA resource templates. Until now, a small group of individuals within SDWG is primarily responsible for both developing and maintaining C-CDA templates. Funding helped push out C-CDA R1.0 in 2012, an errata package (R1.1) in 2013, a new release (R2.0) in 2014 to add some new document types like the Care Plan document, and the update release (R2.1) in 2015 to address some major rework to support backward compatibility. Responsibility for the structural and semantic specifications of C-CDA templates could be shifted from SDWG to the clinical Work Groups assigned to develop the corresponding FHIR resources. For example, if the HL7 Pharmacy Work Group is responsible for the FHIR Medication resource, then they would also be responsible for the definitions of the C-CDA Medication entry templates.

Aligning CDA template maintenance responsibilities with FHIR resource development responsibilities would create economies of scale. The same analysis used to specify FHIR resources can be used to QA and improve the designs of the CDA entry templates. This approach could reduce differences across the two product families where overlap exists. It could ensure greater interoperability. Shifting responsibility for entry template design to HL7’s clinically focused work groups would permit SDWG to focus on developing the processes by which to maintain and evolve the body of templates. 

Funding the development and execution of a long-term sustainability plan is an important second step in the process. To date, no formal plan addresses the need for continuous incremental improvement for C-CDA. Without such a plan, stability becomes stagnation and change becomes chaos. HL7 must develop a process by which functional changes can predictably be introduced and absorbed into C-CDA.  

The third step is collaborating with regulators to resolve the issue of directly naming a specific version of C-CDA standard. For example, using the phrase “HL7 C-CDA R2.1 or a higher version” opens the possibility for smoother progress. Several sections in the regulations recognize the need for standards to continually release updated versions. For example, the regulations allow for newer versions of code systems (standards which establish the terminologies used by computer systems) to be adopted by reference. Existing regulatory mechanisms could facilitate the evolution of C-CDA. The power of the pen could permit planned progress and fix the current regulatory rigidity impeding C-CDA improvement.  

Ignoring this problem won’t make it go away. The longer this issue is ignored, the bigger the C-CDA usability gap grows and the harder it will be to address these needs in the future. If this problem is not addressed, the valuable insight gained during early use of C-CDA will be lost. The opportunity to make needed refinements and beneficial enhancements will be delayed.  

If implementers, like those who participated in the Care Plan Proof of Concept project, contribute DSTU comments requesting functional improvements needed to make C-CDA implementation viable and the response from HL7’s SDWG is, “good ideas, but no time soon”, what will be the result? Will a battle of wills begin to prove functional limitations are actually technical errata? What will happen when a large number of implementers without prior experience with the DSTU Comment process discover this improvement roadblock exists?  

Isn’t maintenance a basic “cost of ownership” issue for the standards development organization who created C-CDA and the regulators who rely on its use to ensure data interoperability? If the use of C-CDA is integral to meeting long-range goals like the Triple Aim (improve care experience, reduce per capital cost, and improve population health), shouldn’t HL7 and regulators take steps to develop and maintain a more agile yet well controlled processes for managing continuous improvement for C-CDA?