The Continuity of Care Document, or CCD, is a healthcare standard EHRs will use to exchange data per the HITECH Act’s Meaningful Use Requirements. However, it goes beyond just being a spec, so to speak.
But CCDs are more than just technical details behind another electronic health record standard. These technical details need to translate logically for those not entrenched in standards creation, so they can effectively manage and transmit data. In reality, most physicians would rather simply hear what a CCD can do for them, without having to digest some of the technical details.
So how can you manage data with CCDs?
Exchangeable Patient Summary Records
At its core, a CCD denotes clinical information. According to Meaningful Use Stage 1 requirements, EHRs need to generate a C32-flavored CCD that includes diagnostic test results and several lists, such as problems, medications and medication allergies.
A CCD is a type of Clinical Document Architecture (CDA) document, so it’s meant to be exchangeable. This is especially useful when a patient is transferred from one healthcare facility to another.
The Direct Project and NwHIM Exchange have drafted guidelines to streamline the exchange process and define what mechanisms to use, and CCDs are required to be human-readable using a standard web browser.
Also, you can include the data you think is important when creating a CCD, provided it fits into the CCD’s structure. But how do providers decide what goes into the CCD? Should providers parse out information by timer intervals, dates or encounters? Perhaps it can be symptomatic. And how does a provider decide?
Include Data You Want
Perhaps an even more integral question is what kind of mechanics do providers need to actually choose what goes into a CCD, and whether this summary can include longitudinal data to convey trends the physician can analyze.
So while you can include much of the data you want, the way it’s organized is dictated by the EHR you select. Some EHRs force the provider to do most of the work to create the CCD, providing access to every result in the system. This gives the healthcare provider much flexibility, but it’s tedious and abnormally time consuming.
Some EHRs do the opposite, ignoring user configuration altogether and instead applying a fixed set of rules to automatically determine the results the system includes. So while this can be very simple for the provider, there are no choices, meaning your system isn’t very flexible.
So deciding what goes in a CCD is mostly left to the provider’s judgment, but it’s up to EHR developers to create a middle ground that allows for some flexibility as well as expedience by supporting key use cases. CCDs need to allow providers to include the data they want and need, namely because these documents are meant to serve as a snapshot of critical information apt to effectively continue care.
Automated Data Extraction
Though not an oft-cited capability just yet, many in the industry are hopeful that CCDs can be used as a vendor-neutral form of extracting structured EHR data. Making this work is a bit more challenging, seeing as it requires faculties that go beyond Meaningful Use requirements.
In order to extract structured data successfully, CCDs must have automated, API-driven access to data export functionality, the capacity to request documents that include all clinical data within a specified date range, and there should exist some surety that the mass of exported data will be coded.
Even if some codes are missing, CCDs will work best for data extraction if Meaningful Use requires mapping the most commonly used LOINC and SNOMED CT codes.
What do you know about CCDs? Would you like to know more? Feel free to leave us a comment!Tweet