Clinical summary export: What is a CCD for?

At last week’s Redwood MedNet HIE Conference, I had the chance to attend an “Interoperability Exhibition” demonstrating the data exchange capabilities of several EHRs. Two themes emerged around clinical summary export. I’ll focus on CCDs (Continuity of Care Documents), but the themes apply to CCRs (Continuity of Care Records) as well:

  1. “What is a CCD for?” Providers use EHRs to generate the patient summary records they share with patients and other providers. But it’s unclear what (exactly) should go into these documents, and whether/how the provider should have a say.
  2. “Where are the codes?” Even though certified EHR products are capable of generating CCDs with appropriate codes (LOINC-encoded labs, for instance), this doesn’t mean that providers’ systems are configured to do so. The demonstrations I saw exchanged CCDs with uncoded labs!

Today’s post focuses on #1. In a future post, I’ll investigate the interplay between certification and meaningful use to understand where LOINC codes disappear to.

What is a CCD for?

CCD is just a format to represent clinical information. If you’re making a CCD, you can include whatever data you want (provided it fits into CCD’s framework). But according to ONC’s Meaningful Use Stage 1 certification requirements, EHRs must be able to generate a C32-flavored CCD including at least “diagnostic test results, problem list, medication list, and medication allergy list.”

Well and good! But how does the provider decide what goes into a summary document? Should it summarize an episode of care? An encounter? A time interval? Details relating to a specific medical concern? Can the summary include longitudinal data to convey trends? Can it include every hemoglobin A1c ever recorded for a patient? And how, mechanically, does the provider actually pick?

Different EHR products offer very different solutions.

One product I saw pushes all the work onto the provider by providing a tree-view that appeared to include every result in the system, with checkboxes at each level to determine which information to include in the summary:

[✓] Medications
[ ✓ ] ASA 1/2/2012
[ ✓ ] Lisinopril 3/2/2012
[✓] Results
[ ✓ ] CBC 1/2/2012
[ ✓ ] BMP 3/2/2012

… very flexible, but very tedious! And how does it scale to large data sets?

Another system I saw provided no user-configuration at all to determine which lab results are included. Instead, this system applies a fixed set of rules (which I learned cornering a software engineer familiar with the product). In short, the rules for including laboratory results were:

  • Start with all lab results from the past 3 months
  • Group results by lab test (HbA1c, WBC, cholesterol, etc)
  • Include the single most recent value from each group

…very simple for the user (no choices!) but very rigid. There’s no way to include longitudinal data (for example, to demonstrate a patient’s weight gain over time).

Presently deciding “what goes in a CCD” is a matter of opinion (or expedience). This problem isn’t new. But if we’re going to enable robust exchange of computable clinical data, we need more than complex user interactions and ad-hoc, unwritten rules. We need EHRs to explicitly (and consistently!) support key use cases. Such as…

Using CCD for automated EHR data extraction!

A common “wish” is to use CCDs as a vendor-neutral way of extracting structured data from an EHR. But making this work requires capabilities beyond Meaningful Use Stage 1. Specifically, data extraction requires:

  • Automated (API-driven) access to data export functionality without user interaction
  • A way to request documents that include all clinical data (or all data within a date range)
  • Guarantees that the bulk of exported data will be coded (“can be coded” is not enough).

Some missing codes are okay; this is an incremental process! But at minimum (and as a pragmatic matter), meaningful use should require mapping the most commonly used LOINC and most commonly used SNOMED CT codes.