Overcoming CDA and CCD Barriers

Overcoming CCD and CDA Barriers


In the design of Meaningful use, C-CDA – especially CCD – was supposed to solve the pressing issues in healthcare concerning interoperability and data exchange problems. But it’s just not turning out that way.

Emerging Major Data Exchange Problems

One recent study found 11 interoperability barriers relative to C-CDA. This is of concern and it’s a concern that integration analysts and developers will have to address in their work.  How does an organization deal with the mismatch of specific patient information? What about the potential delays in Meaningful Use incentives? How can the risk involved in implementing these new documents be mitigated?

The new Caristix whitepaper, Overcoming CDA and CCD Barriers, takes a look at the key techniques and technology integration analysts and developers can use to overcome these barriers today. Specifically, we’ll investigate the biggest issue with C-CDA implementation, gap analysis, and provide a framework for analysts, developers and their managers to deal with this challenge.

Gap Analysis: Why Is It So Important?

The gap analysis is a critical requirements document. Without one, you won’t uncover your systems’ unique needs before development, so testing and validation will drag on. Every single difference or customization will require extra time, money, and effort to troubleshoot and resolve. The result cascades into extended go-lives, more expensive maintenance, and unhappy end-users.

  • Check out the 8 questions your gap analysis process/software must answer during the gap analysis process.
  • Explore 6 major resources on CDA, CCD, and consolidated CDA that will help you get a handle on the issues.

Download Overcoming CDA and CCD Barriers

 Ocercoming CDA and CCD Barriers



Image credit: Alan Stark under a Creative Commons license

Sneak Peek – New Caristix CDA Functionality

Brian Ahier is right

Before you read any further, please go right now and check out what health data exchange expert Brian Ahier has to say about C-CDA on the HIStalk blog.  He is right on the money about the need to clear up the problems with CDA/C-CDA documents. Once you’ve read his article, come back here and you’ll get exactly why  we’re building our new CDA functionality around gap analysis.

A bit of context. A few weeks back we talked about the need for gap analysis and the Clinical Continuity of Care Document (CCD).  Now we’re advancing on building Clinical Document Architecture (CDA) functionality into the Caristix platform, starting with the XML schema for CCD.

First of all, Caristix software can now get your schemas, messages (or documents), and schematrons set up in our Profile Explorer (click images to enlarge):

Message Editor


CDA Profile Editor
Profile Editor


CDA Schematron Editor
Schematron Editor

De-identify CDA documents

Profile Explorer will allow you to manage custom elements and variations. Next on our list is de-identification, so you can take production CDA documents and remove the PHI. You’ll then be able to share those de-identified documents for testing and troubleshooting.

Creating CDA specs or schemas

We’re also working on reverse engineering. That means you’ll be able to create the schema directly from a single CCD document or batch of documents, saving hours of documentation and schema creation for validation testing.

CDA and gap analysis

Another feature we’re working on is gap analysis specific to CDA. So you’ll be able to compare two schemas and document the differences.
Gap analysis is the core need when it comes to CCD implementation to exchange data between EHRs after episodes of care (in HIEs and other data exchange platforms). To understand why, let’s review what a schema is.

XML schema for CCD

To simplify, the schema is like a specification – it tells you how to organize the document structure and content. The schema and the rest of the standard tells you that a CCD generated by any compliant system should be readable by any other compliant system.

That’s how the standard is meant to work.

But what we’re seeing among our customers is far from full compliance.  (And as Brian Ahier mentions on HIStalk, outright errors are all too common.)

Even though the standard is tightly defined, our customers are seeing major and minor deviations and customizations among vendors. Examples include:

  • Implementing just 6 of the 7 elements to be documented during a transition of care.
  • Constrained terminology, so a vendor doesn’t fully support the mandated vocabulary.
  • Use of incompatible optional elements.

The only way to catch these deviations is to run a gap analysis – either manually by comparing documents or specs side by side, or through software such as the Caristix platform. Gap analysis is a must-do  to gather implementation requirements and to ensure that you’re capturing the right use cases for validation before go-live.

Avoiding CCD errors

Just remember: if you’re implementing CCD exchange, attestation is one thing. Real-world implementation, especially for HIEs, is another. That gap analysis is the key to making sure data exchange takes place error-free in a production environment.

That’s what we’re delivering with the new CDA functionality.

Resources for CDA, CCD, and Consolidated CDA Documents

In our discussions with vendors and providers on these new standards, we’ve seen a wide range of learning curves. Some people are just getting started, while others are knee-deep in live exchange. What are the tools and resources that are out there? This blog post gives you a handy list  of resources for CDA, CCD and consolidated CDA documents to get started.

Start with HL7 International

HL7 International is the standards developing organization for healthcare data exchange and integration. They provide the fundamental resources you’ll need to implement CDA. One good place to start is the Implementation Guide for CDA R2 CCD.

Another great resource is Keith Boone’s healthcare standards blog, Motorcycle Guy. Keith blogs extensively on how healthcare data standards are developed, and he provides insight into how to implement CDA. In fact, he wrote the book on CDA. Check out his “Great Stuff” column for a list of CDA-related tools.

Meaningful Use Stage 2 Requirements

Go to the source for Meaningful Use Stage 2 requirements.

High-Level Intros

EHR vendor Practice Fusion has two solid introductory articles (first article, second article) on developing the clinical exchange documents to meet MU2. If you’re an analyst or developer, you may already be familiar with the content. But keep in mind that these are good for sharing with people who don’t need the technical implementation details , but who need to understand the why and how of the big picture.

If you need a high-level introduction to Meaningful Use itself, check out out this video from EHR vendor Hello Health.

SMART C-CDA Scorecard

This consolidated CDA tool was developed by Smart Platforms, an ONC-funded project that aims to create a platform architecture for medical apps – one analogy might be iPhone apps or the Salesforce AppExchange. They see CDA as a key component of the architecture. The Scorecard helps you evaluate the quality of the clinical summaries relative to Meaningful Use Stage 2 requirements and the consolidated CDA specification.

Also check out the blog posts on the Smart Platforms site. Start with the C-CDA posts here: http://smartplatforms.org/interoperability/

Frameworks and Tools

Don’t forget about the S&I framework and NIST tools. These are essential for understanding how your work is going to meet MU2 and CDA requirements. A bonus: CDA Guideline Validation from NIST.

What Caristix is Working On

We see a need to address gap analysis in order to ensure that best practices are followed, and the structure and content meet standards. David Kreda and Joshua Mandel on the Smart Platforms site summarized the issues well; here’s an excerpt:

  • material ambiguities in the C-CDA specification
  • accidental misinterpretations of the C-CDA specification
  • lack of authoritative “best practice” examples for C-CDA generation
  • errors generated by certification itself, i.e., vendors are incentivised to produce documents that set off no warnings in the official validator (rather than documents that correctly convey the underlying data)
  • data coding errors that reflect specific mapping and translation decisions that hospitals and providers may make independent of EHR vendors

Other Resources

What other CDA, CCD and consolidated CDA document resources should we list? Leave a suggestion in the comments below.

Gap Analysis and CCD Document Specification

Bridging the Gaps

CCD document specification gap analysis

In a previous post on CCD, C-CDA, and CDA, we compared HL7 v2 messaging to CCD development. This week’s article is about the biggest roadblock with CCD document specification: gap analysis.

What is Gap Analysis?

Simply put, gap analysis is about understanding the differences in the data between two systems. The output of a gap analysis process is a list of all the differences between two systems charted in a requirements document. With HL7 v2 messaging, many organizations create their own gap analysis templates and include items such as field mapping tables, the development work involved with bridging a gap, and an issue tracker. To fill in the template, they do a spec cross-walk, look at messages with text or HL7 editors, run queries using messaging tools, and manually document their findings. Some use Caristix software to automate this process.

What about the CCD Document Specification and Gap Analysis?

You’ll need to apply the same process with CCD document specifications and messages. The manual gap analysis process can be onerous with HL7 v2.x messaging. That doesn’t change with CCD.

Gap Analysis Questions

With CCD document specifications, you’ll need to answer the following questions during the gap analysis process:

  • Built into the standard is the ability for both source and destination systems to handle all tags. How does each system handle extra tags built for special needs?
  • Are the systems using the same version of the standard? The standard is evolving, so systems might be on different versions.
  • Are there any differences between the format or structure in each system? If so, what are they? 
  • Are there any optional data elements that are required in one system?
  • Do both systems use the same content? They may use the same code sets, but they may be using slightly different sets of constraints. For instance, take LOINC or SNOMED. It’s all well and good to say these are specified in the standard, but these are vast data sets. Is there a perfect match in all fields/tags? You need to check during gap analysis.
  • What about data attributes like length or optionality?
  • Is there any custom information that must be documented or explained?
  • Is the data semantically consistent? In other words, does the data mean the same thing in both systems?

Why You Need to Do the Gap Analysis

The gap analysis is a critical requirements document. Without one, you won’t uncover your systems’ unique needs before development, so testing and validation will drag on. Every single difference or customization will require extra time, money, and effort to troubleshoot and resolve. The result cascades into extended go-lives, more expensive maintenance, and unhappy end-users.

Our two cents: do the gap analysis. It’ll save time, money, and headaches down the road. 

HL7v2 to CCD

Confused? Start with What You Know

CCD-HL7-get-startedOver the past few months, we’ve heard a lot from our hospital-based customers about CCD and C-CDA readiness. There’s more urgency with Meaningful Use Stage 2 deadlines, even with the extension.

But the funny thing is: hardly anyone ever says, darn, but this is confusing.

Sometimes people express their frustration. “What the heck are those regulators doing? Why are they pushing more stuff at us, when we’re barely able to keep up as it is?”

Others bury their heads in the sand. “We’ll get to it. It can’t be that hard. Just go download a few Implementation Guides and we’ll get it done.”

And few and far between, there are the rare people who say, “This is hard. This is confusing. How do we start?” This post is for those folks who find it confusing. Here are some suggestions for getting started.

For starters, you’re an interface expert – either an analyst or developer. You’ve already got an extensive body of knowledge in HL7 v2.x messaging.

How do you add CCD to your toolkit? Simple. Start with what you know: HL7 v2.x. Here are some answers to the questions we’ve often come across.

With HL7 2.x interfacing, scoping and validation is a big part of the work. Will this volume of work be reduced with CCD?

No. And here’s why. CCD, which is based on Clinical Document Architecture (CDA), is an evolving standard and it parses a number of discrete elements. And as an implementer (either as a vendor or a provider), you can define or tweak your own templates.

Sure, there are specific templates that are prescribed by Meaningful Use. And these are publicly available, with a full set of schemas (which define the structure or format), content, and of course use cases.

The validation or conformance templates are also available, so it’s easy to define the rules they have to conform to.

The danger here is that implementers still have to meet their organization’s own needs, therefore they will need to define custom formats – similar to z-segment in HL7 v2.x. They’ll meet their immediate needs.

If the CCD spec or schema is more constrained, shouldn’t the interoperability work be easier?

You would expect that to be the case. The CCD specification is more constrained than the HL7 v2.x standard from a structure or format point of view. But keep in mind that the CCD spec (because it is based on on XML) is huge. And the content is varied. One analyst said, “it’s all over the map. I have no idea where to start.” So the idea of creating profiles – what Caristix Workgroup software enables — is attractive, since it facilitates the gap analysis process. (More on gap analysis and CCD next week.)

How do I manage custom elements and variations?

Documentation is important. An XML schema, while complete, is hard to read and represent easily. They are self-referring. You’re going to scroll a lot. Our goal, with our profile approach, is to makes this process easier. Coming soon: another article on the biggest roadblock with CCD: gap analysis.

Stay tuned. Tell us: What else would you like us to cover? Leave a comment.