Mapping and Building Clinical Documents to C-CDA | Practice Fusion

This blog post is part of a series that discuss the technology behind Meaningful Use, the Medicare and Medicaid EHR incentive program that provides financial incentives for the “meaningful use” of certified EHR technology to improve patient care. For a high level overview, read “ The quiet digitization of American healthcare,” written by Practice Fusion co-founder/VP of Platform Matt Douglass. If you’re interested in joining our talented technology team, check out our Careers page.

For an overview of C-CDA, read Understanding the C-CDA standard for EHR certification and Meaningful Use.

There is a saying that the devil is in the details, and nothing can be closer to the truth when it comes to mapping and building clinical documents formatted according to the C-CDA standard as part of Meaningful Use 2014 Certification.

Product enhancements: the first step

To become a C-CDA expert, I needed to be a systems analyst, data analyst, business analyst, developer, and architect all at the same time. It was no small task to properly map out and correlate what we had available at Practice Fusion to what was minimally required by the C-CDA standard. Of course, as is usually the case with standard file creation and population, there were gaps between what the standard expected and how Practice Fusion had previously collected and stored the data. So sending out product enhancements and working with the various groups to enhance the application played a critical role in our successful C-CDA delivery. This analysis and reanalysis of capturing the data correctly was a time-consuming effort, but a key requirement in our success, which was ultimately a very rewarding experience.

Once the analysis was at a stage of broad understanding, the follow-up challenge was managing requirements across various certification modules, maintaining and researching cross-references between other HL7standards, and integrating new feature functionality within the EHR application. In addition to all of those tasks, it was also important to complete a thorough impact audit during the design, implementation, and testing phases during the development of the documents.

Meeting the requirements

To meet the requirements of the two clinical documents being created for EHR Certification, Practice Fusion needed to create 14 unique CDA sections, and each section had its own specific nuances of required information. While each section had some similarities, there were plenty of differences; taking the time and effort to go through each detail made the end result worth the effort. This system review proved to be quite useful for truly understanding the system and data flow, which contributed to several new feature enhancements to Practice Fusion’s core EHR.

We also took the time to include sections where we had the data and could incorporate data that may have been deemed optional by the guide, but was significantly relevant to how we capture data in our EHR. For example, with our allergies functionality, we needed to add detailed provider contact information not only at the header, but also to the entry of who recorded the allergy and at which location it was originally recorded. Adding the latter half of data is considered optional, but I made a judgment call to include the data since I thought it would be relevant and beneficial to the recipient of the document. The feedback we have received from vendors who work with our C-CDA has validated this approach, as they consistently tell us that ours is one of the most comprehensive and detailed C-CDA versions being generated by EHRs.

Mapping the data to the HL7 3.0 C-CDA standard

Analyzing what we had and what was required was relatively easy when compared to mapping the data elements to the incredibly complex and hierarchical HL7 3.0 C-CDA standard (https://www.hl7.org/dstucomments/index.cfm). The guide was helpful, but it was also incredibly vague, since it was originally designed to be an outline to fit all possible systems and scenarios. The guide did help at the high level, but at the more detailed level, I surrounded myself with other C-CDA examples (https://github.com/chb/sample_ccdas) that NIST and Drummond produced. Developing and sending sample XML documents through the NIST testing tool also helped me flush out requirements, code standards, and final implementation. The final and easiest trick involved exporting the data out of the Practice Fusion transactional relational data structure and into a form that could easily produce the XML format._ _

Looking forward

Our current implementation is designed for a real-time request for a C-CDA. Our next goal is to improve our framework to handle bulk C-CDA requests in batches without impacting our real time SLA for our physician end-customers, all the while improving performance of the real-time processing where we can. This will no doubt be another herculean task, with many data gaps and roadblocks along the way, but with our initial implementation of C-CDA behind us, this next optimization will certainly go much smoother.