Home » Readers Write » Currently Reading:

Readers Write: Data Exchange with C-CDA: Are We There Yet?

July 16, 2014 Readers Write 8 Comments

Data Exchange with C-CDA: Are We There Yet?
By Brian Ahier

image

Do you think you have all the interoperability criteria to meet current and future stages of the EHR Incentive Programs? A new study published in JAMIA found that most providers don’t.

The study concluded that providers likely are lacking critical capabilities. It found that some EHR systems still don’t exchange data correctly using Consolidated Clinical Document Architecture (C-CDA), which may prevent providers from receiving future Meaningful Use (MU) incentives.

After sampling several platforms used to produce Consolidated Clinical Document Architecture (C-CDA) files, the research team from the Substitutable Medical Applications and Reusable Technology (SMART) C-CDA Collaborative — funded by the ONC as part of the SHARP research program — found a number of technical problems and obstacles which prevented accurate data exchange between different EHR systems.

There is already wide-scale production and exchange of C-CDA documents among healthcare providers this year due to the EHR incentive program and for meeting Meaningful Use requirements. Indeed, live production of C-CDAs is already underway for anyone using 2014 Certified EHR Technology (CEHRT). C-CDA documents enable several aspects of Meaningful Use, including transitions of care and patient-facing download and transmission.

Stage 2 Meaningful Use requires that providers be capable of producing C-CDA files, which contain both machine-readable and human-readable templates used to exchange patient data between EHRs during transitions of care. While all 2014 CEHRT must have the ability to create these files, some vendors are unfortunately not using the basic XML and HL7 technology correctly.

To find out how these variations affect providers and their participation in Stage 2, the researchers sampled 107 healthcare organizations using 21 EHR systems. They examined seven important elements of the documents: demographics, problems, allergies, medications, results, vital signs, and smoking status, all of which are required to be included in the C-CDA for Stage 2. They found errors in the XML that conflicted with HL7 standard usages, rendering the document ineligible to meet the Stage 2 rules for interoperability.

One key takeaway from this research is that live exchange of C-CDA documents is likely to omit relevant clinical information and increase the burden of manual review for provider organizations receiving the C-CDA documents. Common challenges included omission or misuse of allergic reactions, omission of dose frequency, and omission of results in interpretation. Unfortunately, only some of these errors can be detected automatically.

image

The team found 615 errors and data expression variation across 11 key areas. The errors included “incorrect data within XML elements, terminology misuse or omission, inappropriate or variable XML organization or identifiers, inclusion versus omission of optional elements, problematic reference to narrative text from structured body, and inconsistent data representation.”

"Although progress has been made since Stage 1 of MU, any expectation that C-CDA documents could provide complete and consistently structured patient data is premature," the researchers warned. The authors also note that more robust CEHRT testing and certification standards could prevent many of these troubling errors and variations in the technology and that the industry may also benefit from the implementation of data quality metrics in the real-world environment.

The researchers recommended several steps to improve interoperability: providing richer, more standardized samples in an online format; requiring EHR certification testing to include validation of codes and vocabulary; reducing the number of data elements that are optional; and improving monitoring to track real-world document quality.

The researchers make the case for using a lightweight, automated reporting mechanism to assess the aggregate quality of clinical documents in real-world use. They recommend starting with an existing assessment tool such as Model-Driven Health Tools or the SMART C-CDA Scorecard. This tool would form the basis of an open-source data quality service that would:

  • Run within a provider firewall or at a trusted cloud provider
  • Automatically process documents posted by an EHR
  • Assess each document to identify errors and yield a summary score
  • Generate interval reports to summarize bulk data coverage and quality
  • Expose reports through an information dashboard
  • Facilitate MU attestation

"However, without timely policy to move these elements forward, semantically robust document exchange will not happen anytime soon," the authors stated. “Future policy, market adoption and availability of widespread terminology validation will determine if C-CDA documents can mature into efficient workhorses of interoperability,” the report concludes. It would seem that if policy changes are not put in place, there could be risk in the Meaningful Use program not actually being all that meaningful.

This month CMS released the proposed 2015 Physician Fee Schedule. Among other things,it includes proposals to revise the physician supervision requirements for Chronic Care Management (CCM) services and proposes to require CCM practitioners to use EHRs certified to meet at least the 2014 Edition Meaningful Use criteria, which require the ability "to capture data and ultimately produce summary records according to the HL7 Consolidated Clinical Document Architecture standard."

Since this new proposed rule includes expanding the use of the certification program beyond Meaningful Use and specifically mentions the C-CDA standard, I thought I would ask Joshua Mandel, one of the authors of the study, for his thoughts.

"It’s not too surprising that CMS’s efforts to improve chronic care management would build on Meaningful Use requirements," he said. "In the section you’ve quoted, CMS, is simply saying that Eligible Providers would need to use MU-certified systems (just as they must use MU-certified systems to attest for MU incentive payments). And so C-CDA capabilities come along for the ride in that decision. I can certainly say C-CDA is better than nothing; and C-CDA 1.1 is a specification that exists and has been implemented today, so it’s a natural choice here."

While there are challenges in implementing and making good use of C-CDA documents, there is little doubt that HHS is continuing to drive the use of these standards forward through various policy levers. The ability to exchange relevant clinical information for transitions of care is a key enabler in transforming our healthcare system to paying for quality instead of quantity.

Despite these challenges, we are beginning to see success in the marketplace. Building on this success and continuing to improve content standards is critical if true interoperability is to become a reality.

Brian Ahier is director of standards and government affairs for Medicity, A Healthagen Business of Salt Lake City, UT.



HIStalk Featured Sponsors

     

Currently there are "8 comments" on this Article:

  1. Brian nice write up. This is a real patient safety issue. This needs to be addressed by the health care IT industry ASAP.

    I am not surprised this is the case given the complexity of C-CDA for developers and the fact that the narrative section is considered the normative section of a CDA document.

  2. Steve- agree with your point, and Brian, a nice post, and a nice update to many of us who still have a bloodied forehead from working on this long enough.

    The article does not consider a weighted average for market share, and I point this out not as a criticism, but as an opportunity. If ONC as a convener or a market-based network (CommonWell, are the there?) could truly solve the quality and willingness problem amongst even the top 5 or 6 vendors, most others would follow, and very quickly we could be staring at 80%+ success. If not, this will just get punted to the next version of the ecosystem, which will be entirely API driven, likely with entirely new winners.

    Until then, we’ll all just continue to read about this ecosystem dysfunction on one hand, and large and becoming humongous Epic – Epic volumes on the other.

    Scott Barclay

  3. Data Quality – a maturing of our interoperability

    It’s very encouraging that this research happened and that there are now enough C-CDA-capable systems that it is possible to take this look at the data quality. While the study highlightes important areas for improvement, having the assessment of the data quality is a key step toward getting better. Knowing were we are is essential to the journey toward ever better interoperability.

  4. re: “…the narrative section is considered the normative section of a CDA document.”

    C-CDA implemented according to MU2 requires both narrative and discrete data.

  5. Brian,

    Most of the existing assessment tools approach to testing rely on testing structure of the C-CDA only, we need to test clinical systems and EHR Vendors with semantically robust document exchange test cases, where bi-directional (sender and receiver) tests include complex clincal events and episodes which put systems through their paces as would occur in a production HIE and/or Clincial Exchange using NwHIN, HL7, DIRECT and IHE Profiles in mind. Simply stated going beyond the current “Happy Path” approach of Conformance and Interopability Testing, and yes let’s do throw an exception test case or two in there for some extra points.

  6. I still maintain that the C-CDA developer’s tool is too difficult and complex for users to create, maintain, and exchange patient medical record documents.

  7. Great write-up, glad to see progress being made. As developers come up the skill curve (health care is a little late to the game, after all), we’ll see an explosion of implementations. As for data quality, don’t we see those issues everywhere in the EHR space? Daylight is the best disinfectant, I think Justice Cardozo once said. Now that we can see them, we can tackle the root causes of data problems.

  8. Brian, nice writeup. Integrating of any protocol is difficult however it can be done. However, the C-CDA is very complex and costly in integration, support and bandwidth. The CCD CDA and then C-CDA are organic transformations of legacy system and forced into a newer model of com and use. One of the issues is none standardized EHR database schema, this needs to be addressed if we are going to make integration easier. As with any system at some point it must go through a refractor process in order to make the system more efficient. I think the time is now.

Text Ads


RECENT COMMENTS

  1. Well that's a bad look as the Senators contemplate filling in the House gaps in the VA Bill

  2. Fear of scorn from Mr HIStalk is so great at Oracle Towers that the webinar recording linked to in the…

  3. House lawmakers should have bought a squirrel ;-)

  4. Poor portal design has lots to blame for messaging issues. In the portals that I have used, the patient can…

  5. Thanks, appreciate these insights. I've been contemplating VA's Oracle / Cerner implementation and wondered if implementing the same systems across…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.