The history of shared clinical documents is marked by decades of industry-wide deliberation. In recent years, catalyzed by ONC Certification, there has been widespread adoption and refinement of the standard.
Data EHRs were required to record and share under ONC Certification were originally called Meaningful Use Data and represented a list of basic chart elements. These were later reformulated as the more expansive Common Clinical Data Set (CCDS) in 2015 Edition Certification. The emergence of 2015 Edition criteria also removed the requirement for the encounter-based document previously required in 2014 Edition – the ambulatory Clinical Summary – making the test data for the latest edition of Health IT certification effectively patient-based.
The current ONC-sanctioned R2.1 version of the C-CDA document, upon which the sharing of these minimum data elements is based, includes long-discussed enhancements that have lead to much greater clarity. But there remain issues of reliability, relevance and provenance surrounding the standard and its implementation, particularly at the encounter level. Some of these issues, particularly with respect to provenance, are being addressed in the underlying data with the Draft U.S. Core Data for Interoperability (USCDI), which is slated to replace the Common Clinical Data Set (CCDS).
There have also been efforts provide constructive recommendations on the structure of the document itself. Earlier this year, Carequality and CommonWell Content Work Groups released a white paper, using the C-CDA R2.1 Companion Guide as a baseline to provide “complementary, not conflicting guidance.” CommonWell is a not-for-profit trade association focused on interoperability, while Carequality represents a similar industry-wide collaborative, convening healthcare stakeholders on interoperability issues.
The goal of the collaboration was a more clinically-relevant and parsimonious C-CDA. The collaborative work group tackled the following issues:
- “Unacceptably large” C-CDA documents
- A general absence of clinical notes
- Need for encounter summary support
- Need for version management
 |
| Clinical Notes should follow the encounter. (Credit: Max Pixel) |
The white paper has a wide range of common-sense recommendations, but we’ll discuss some of the recommendations most relevant to implementing CCDA R2.1 under 2015 Edition Certification and USCDI (which is slated to replace CCDS).
- Problems – only those addressed during the encounter
- Allergies – “only if the system can recreate the active Allergy list at the time of encounter”
- Medications – “only if the system can recreate Medications at time of encounter”
- Immunizations – those given during the encounter
While conditionality in general can get thorny, these recommendations make a good deal of clinical sense. If events are not touched by the encounter, updating and sending them makes little sense.
Specific to the USCDI, the work group judged the data set to contain “valuable data elements and should be exchanged to improve patient care.” But they go on to say that Clinical Notes should not simply be a data dump: when they are supported, support for Encounter Summary documents should be added to ensure the note follows the encounter.
The recommendations focus on Encounter Summary documents (Progress Note Document and Discharge Summary) and preserve all sections required in the base C-CDA document template. After setting that foundation, they map out a “priority subset” of clinical data from the ONC Common Clinical Data Set (CCDS) and draft US Core Data for Interoperability (USCDI). The idea is to weed out data that is stale or irrelevant to the clinical encounter.
The prioritized sections for ‘always include’ have data within them that should appear conditional based on the events of the encounter:
In theory at least, the C-CDA as tested under 2015 Edition would become easier to interpret and implement. There also a few general guidelines for non-priority elements:
Systems SHOULD send a ‘No information’ assertion template if nothing is available for one of the priority subset data elements.
Systems MAY send additional data elements, beyond the priority subset, if relevant to the encounter. For these additional data elements, systems should not send a ‘No information’ template if nothing is available.
The concept of ‘no information,’ while ostensibly straightforward, is crucial here. It’s the “known unknown,” that provides more certainly to the receiver of the C-CDA that in fact nothing clinically relevant appears under that section, as opposed to having been omitted for an unknown reason.
The recommendations also touch the world of Fast Healthcare Interoperability Resources (FHIR), which implications for how its resources are used. The CommonWell-Carequality alliance is deeply involved in FHIR workgroups and its recommendations may, through governance of the standard, help shape efforts to ensure C-CDA and FHIR resource play more nicely together. Currently, there is a significant amount of subjectivity in getting the sections of a C-CDA in and out of FHIR.
Dynamic Health IT has been reviewing its C-CDA practices and guidance to make sure we help our clients send and receive documents that are clinically-relevant and readable. True interoperability requires nothing less.
We’re looking forward to seeing you at the C-CDA IAT meeting. You can find the Track Agenda here.
