CCD: Show me the codes!

In my 7/24/2012 post, I observed that exchanging uncoded lab results is the state of the art.

Why worry? SMART is pushing to enable third-party apps on disparate health IT systems, and codes are the glue holding meaning together. Without coded data, apps can’t tell a Hemoglobin A1c measurement from a monocyte percentage!

In the USA we have substantial infrastructure to promote the flow of coded data. So where do things break down?

Understanding coding requirements: cast of characters

In practice, enabling the exchange of clinical data requires more than just data standards like CCD (Continuity of Care Document). Indeed, we have a complex interplay among legislation, certification, software configuration, and attestation:

  1. ONC defines “certification criteria“: capabilities that EHRs must have to support meaningful use. For example, EHRs must support standards such as the C32 flavor of CCD, and RxNorm Codes for medications.
  2. NIST uses ONC’s MU requirements to define testing procedures that ensure vendor products have these capabilities. These procedures are a series of cookbook steps like “Tester shall select patient summary record data from Vendor-supplied test data.”
  3. CMS defines meaningful use measures (core measures + menu options). For example, eligible providers must store certain lab results as “structured data”.
  4. Eligible providers and hospitals attest to meeting CMS’s meaningful use measures.

Coded data evaporate at each step!

There are several opportunities for disconnects here. Here’s an exploration of how these disconnects permit missing LOINC codes in real-world exchange.

ONC’s Certification Requirements
We glibly say that MU Stage 1 “requires LOINC codes for labs,” but in fact the requirement is weaker: EHRs must apply LOINC codes “when such codes were received within an electronic transaction from a laboratory.” So in practice, EHRs needn’t (read: don’t) use LOINC much internally.

But ONC’s requirement for patient record summary exports as C32-flavored CCD exports does (transitively) require LOINC. ONC’s explanatory text clarifies the requirement in two ways:

  • “we expect the [CCD] to include health information that is coded, where applicable, in accordance with adopted vocabulary standards.”
  • “eligible professional (or eligible hospital) would be permitted to map or crosswalk local/proprietary codes to the adopted vocabulary standards”

In other words, ONC recognizes that local codes are used under the hood, and the complex practice of on-the-fly mapping is expected.

NIST’s Testing Plan
NIST designs a test to ensure that vendor products have “the capability to use specified vocabularies” (emphasis added: it’s often the case that customers don’t, or even can’t, take advantage of these capabilities owing to issues of vocabulary licensing, software configuration difficulty, etc.)

NIST’s certification requirements are like a cookbook. To paraphrase:

  1. use the EHR to find a patient;
  2. insert the following medications;
  3. insert the following labs;
  4. generate a CCD containing a patient summary.

The generated CCD is then evaluated by a combination of automated tools (supplied by NIST) and a manual inspection. The automated tools focus on document structure (syntax), not meaning, so if an element has a nonsense code or non-LOINC coding system, the validator may give a warning but will not give an error. Furthermore, NIST’s automated Web-based tool silences warnings by default, so only hard errors are reported. Manual inspection is designed to address this gap. But wading through dense, two-thousand-line XML files by hand is perilous.

(From NIST’s perspective, the question from last blog post — “how does end-user choose what goes in the CCD” — is irrelevant: as long as all the data in the NIST recipe show up, the testing procedure green-lights.)

CMS’s Meaningful Use Measures
CMS’s MU Stage 1 only requires that an eligible provider keep 40% of simple lab results as “structured data.” First off: there are no guarantees about which 40%, meaning that an arbitrary majority of simple lab data can still be stored as free text, TIFF images, etc. And even for the minority of lab results that are stored as structured data, there’s no requirement that LOINC codes are used in practice, at all.

With respect to data exchange, MU requires only that the eligible provider perform “one test” of data exchange by CCD or CCR export. Or if the data aren’t available in a structured format, then unstructured exchange is okay too. And the test doesn’t even need to succeed.

So providers might export coded data; but meaningful use can also be achieved sans lab codes.

Individual Providers’ (or Hospitals’) attestation
At the final stage of the data generation pipeline, eligible providers or hospitals perform their “one test” of data exchange according. In many cases they’ll simply follow a set of instructions provided by their EHR vendor (but there is no strong guidance here; providers are ultimately responsible for the accuracy of their own attestations). For a sobering example of how rough the testing process can be, see The Indian Health Services’ attestation instructions, which require installation of new software modules, execution of SQL database queries, and snapping a screenshot of the result.

Getting to codes: closing gaps

At the end of the day, a wide gap stands between abstract product capabilities and the results that individual end-users can in fact hope to achieve by using “capable” products. In particular, getting certified EHR products to produce LOINC-coded lab exports involves substantial configuration including the licensing of vocabularies; creation of mapping tables; and installation of specialized vendor-supplied extensions. And in practice, this isn’t happening nearly often enough.

If we expect to see codes in real-world data, this expectation needs to be clear in the regulatory process. A good start would be to recognize that coding data is an incremental process. If the prospect of coding everything, all at once, is paralyzing, then let’s start with the most common use cases.

Empirical reports show better than an 80/20 rule at play: 20% of LOINC codes (400 codes!) cover more like 95% of test volume.

So let’s make codes part of meaningful use: in other words, let’s get beyond abstract capabilities and require the export of coded data in clinical practice.