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):
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.