CCDA Usability and Interoperability

1. CCDA Usability and Interoperability Matt Reid July 28, 2014

2. CCDA in Meaningful Use • CCDA is the core component for data packaging (encoding) and exchange in MU. • Care Coordination • Transitions of Care • Data Portability • Patient Engagement • View/Download/Transmit • Clinical Summary

3. CCDA Structure • Header • Enables clinical document exchange across and within organizations. • Body • Section(s) • Allergies, Meds, Problems, etc. • Narrative • Entries

4. CCDA Interoperability • To what extent are CCDA documents interoperable across systems today? • 9 Document Templates • CCD, Consultation Note, Op Note, Progress note, etc. • No single CCDA document template contains all of the data requirements to sufficiently meet MU2 compliance – CCDA & MU2 guidelines must be implemented together.

5. CCDA Transition of Care • The document templates within CCDA are considered “open” templates, which means in addition to the required and optional sections defined in the template, an implementer can add to the document whatever CCDA sections are necessary for his purposes. • Generating the correct summary documents are left up to the discretion of the EHR vendor. • Implementation Guidance (IG) has been lacking and is too broad.

6. VA Example • Large VA hospital wants to exchange summary of care documents with a large, HIMSS Stage 7 community hospital. • Community hospital is using an EHR product from well known vendor • Exchange is happening through HIE. • Labs, meds, and allergies are exchanged but no physician documentation (office note) is coming across. Therefore, most critical info not coming across in the summary of care.

7. CCDA V/D/T Example • The CCDA IG addresses 9 documents, however, there are three likely candidates for this situation. • Consultation Note • Continuity of Care Document (CCD) • Discharge Summary • Best fit is determined by scenario, which is up to the EHR vendor’s discretion. • Patient wants to transmit to another provider, there is no assurance that the receiving physician can accept, let alone, view data contained in CCDA. • This reduces the utility of exchange, and therefore may require physician to duplicate documentation or order new diagnostic tests.

8. Issues With CCDA Testing and Guidance • MU Stage 2 requires content for 17 different data elements, but it doesn't specifically say what you do when that isn't present. • Certified products have to pass tests which verify that a vendor can create the data elements, but those tests DO NOT verify that EHR correctly produced a CCDA document where there is no data. • NullFlavor fields are available, but good examples and IG are lacking. • Cert testing focuses on creation and transport of CCDA, not intake. • Postel’s Law must be better understood by industry. • CCDA focuses on template definition, not implantation guidance. • MU2 data requirements imperfectly correspond to HL7 CCDA specifications.

9. Future MU issues • CCDA Release 1.1 was named in regulation for MU Stage 2 while still in draft standard for trial use (DSTU). • IG, template structure, and XML may change before normative ballot. • CCDA Release 2.0 • CCDA 2.0 may be named in regulation for MU Stage 3 and is largely backwards compatible, but template versioning still in question.

10. CCDA IG adherence and Semantic Issues • June, 2014 article from the Journal of American Medical Informatics Association • Sample CCDA taken from 21 different EHR vendors • Utilized both NIST testing tools and SMART Scorecard • Over 50% of vendors had IG errors • Vendors averaged a score of 63% in semantic accuracy. • Not every error is life threatening, however, missing or erroneous code could disrupt vital care activities, such as automated surveillance for drug–allergy interactions.

11. How to improve CCDA Interoperability • Because the CCDA includes dozens of reference vocabularies in its implementation, testing for appropriate conformance to common vocabularies, such as SNOMED, LOINC, RxNorm, and UCUM, should be part of certification. • ONC should clarify IG, constrain optionality at a more granular level, and create a site for public samples of CCDA documents, sections, and entries. • CMS and ONC limit future MU Stage requirements to ones that are well tested, understood, and are associated to rich implementation guidance.This may require learning from the current and past Stages and better coordination with standards development organizations before attempting to force the hastily progression to future Stages.

12. References • JAMIA Article • Are Meaningful Use Stage 2 certified EHRs ready for interoperability? Findings from the SMART C-CDA Collaborative • http://jamia.bmj.com/content/early/2014/06/26/amiajnl-2014-002883.full.pdf+html?sid=f9e57baf-2376-42b6-adb8-eee509c88302