At yesterday’s Health 2.0 conference, Farzad Mostashari asked why SMART isn’t using CCD export (as specified by Meaningful Use) to extract data from EMR systems. This is a great question, in part because it separates out two important aspects of SMART:
- Getting data out of today’s EHRs
- Presenting those data to apps in a natural, convenient, developer-friendly way.
—and focuses on #1. (I don’t think many would argue that CCD is fit for #2. And to be clear: for developers building a SMART app, the details of #1 are almost irrelevant. SMART app developers get one clear-cut API to work with, and consistent SMART data elements)
Well! ONC is certainly headed in the right direction by requiring more specific, demanding export formats as part of meaningful use. Having a baseline level of consistently structured data is the right aspiration! And MU stage 2 will do better than stage 1. But we’re trying to fuel SMART apps on EHR data today, and that’s tough.
Here are some reasons why we’re still querying database tables and calling vendor-specific web services to extract the data we need to fuel apps:
Theoretical stuff
Many people have described the challenge of interoperability with vanilla CCD and C32. These formats are difficult to work with in a consistent way, to the extent that it’s common for an organization to implement multiple CCD-processing interfaces to exchange data with multiple partners. A symptom is that CCDs are often “imported” whole, so they can only be viewed in one big chunk. Wes Rishel presents a nice description of the issues and how MU Stage 2 helps address them.
Practical issues
These are huge. MU Stage 1 requires that systems be able to export (on demand) a C32 or CCR. But the systems we work with aren’t there:
Not MU certified yet
For example, Children’s Hospital Boston has a Cerner system. But there’s no CCD export functionality yet. (CHB is in the process of testing its own custom-built CCD exporter; they’re not using Cerner’s.)
No API means no automated export
MU stage 1 doesn’t require programmatic access to CCD export functionality, so typically the only way to export data is by having a user log in, select a patient, and click a button. So even if the underlying capability is (theoretically) there, it’s hard to automate export.
Questionable fidelity of exported data
As a test, I just tried exporting a CCR from PracticeFusion, an MU certified EHR. Well, my CCR had patient demographics, medications, and drug alleriges; but omitted immunizations, height measurements, and food allergies. (I’m not trying to single out PracticeFusion here… they’re the only working CCR export I can access!)
Speed, etc.
Even if you can programmatically trigger CCD/CCR generation, the process needs to be fast to support on-the-fly data transformation to fuel apps. Otherwise developers start asking: how do I get at the raw data quickly?
Level of clinical detail
Building clinical applications, we quickly discover aspects of the data that aren’t covered in CCD: for example, recording a patient’s body position and cuff size for a blood pressure measurement. These data typically do live in the source system; they just aren’t exported because CCD doesn’t have a built-in place for them. We want to maintain the flexibility to export more data as we recognize its importance, and that means having access to the underlying vendor system, not just an export.
SMART isn’t just for EMRs.
At the end of the day, SMART is about running apps in a variety of environments. We’re targeting EMRs for sure, but also personal health records, data-mining platforms, and health information exchanges. Meaningful Use provides certain guarantees about what EMRs must support — but these guarantees don’t extend to other components of the Health IT ecosystem.