TL;DR: If you’re using XSLT stylesheets to render C-CDAs in your EHR, make sure you understand the security implications. Otherwise you could be vulnerable to a data breach.
This blog post describes security issues that have affected well-known 2014 Certified EHRs.. Please note that I’ve already shared this information privately with the Web-based EHR vendors I could identify, and I’ve waited until they were able to investigate the issues and (if needed) repair their systems.
Last month I observed a set of security vulnerabilities in XSLT “stylesheets” used to display externally-supplied C-CDA documents in many EHRs. To be specific: the CDA.xsl stylesheet provided by HL7 (which has been adopted by many EHR vendors) can leave EHRs vulnerable to attacks by maliciously-composed documents. Continue reading “Security vulnerabilities in C-CDA Display using CDA.xsl”
Last week I received an e-mail asking how FHIR expresses Uncertainty and Negation. It was a general inquiry, but also asked how FHIR might express a specific clinical statement like “Intolerant to opiods, no known other medication ADEs, and no known environmental/food allergens”.
2014 will see wide-scale production and exchange of Consolidated CDA documents among healthcare providers. Indeed, live production of C-CDAs is already underway for anyone using a Meaningful Use 2014 certified EHR. C-CDA documents fuel several aspects of meaningful use, including transitions of care and patient-facing download and transmission.
This impending deluge of documents represents a huge potential for interoperability, but it also presents substantial technical challenges. We forecast these challenges with unusual confidence because of what we learned during the SMART C-CDA Collaborative, an eight-month project conducted with 22 EHR and HIT vendors.
As a follow-on to the last post about Direct messaging, I want to distinguish the Mass Medical Society’s vision of a “whitelist” from another concept that confusingly shares the “whitelist” moniker. Below, I’ll introduce two distinct terms and try to clarify the distinction:
“OR-gate whitelists” expand the communication pool
Mass Medical Society envisions a kind of per-physician “whitelist” that I’ll call an OR-gate whitelist. The basic premise of an OR-gate whitelist is that a physician can add any Direct address to her OR-gate whitelist via a UI in her EHR or HISP. By doing so, she’d be able to send secure e-mail to that address — regardless of CAs, trust bundles, or pre-existing local policy. An OR-gate whitelist acts like a logical “OR gate,” meaning that a message will be sent if institutional policy allows it, or if a physician’s personal OR-gate whitelist allows it. With OR-gate whitelists, physicians can send to any Direct endpoint in the world, full stop.
“AND-gate whitelists” restrict the communication pool
The current Massachusetts HIWay has a deployed a different kind of “whitelist” functionality that I’ll call an AND-gate whitelist. Mass HIWay maintains a state-wide AND-gate whitelist of acceptable Direct addresses to which HIWay users are allowed to send Direct messages. An AND-gate whitelist acts like a logical “AND gate,” meaning that a message will be sent only if institutional trust bundles allow it (i.e. the recipient’s cert is signed by a CA that the organization trusts) and the institution’s AND-gate whitelist allows it. So Mass HIWay’s state-wide AND-gate whitelist is a way to avoid allowing, say, “all eClinicalWorks users across the whole country” into the pool at once. Instead, access can be restricted to the intersection of two sets: “All eClinicalWorks users across the whole country” and “Users on the Mass HIWay AND-gate whitelist.”
As Meaningful Use 2014 EHRs come online this winter, clinicians across the country gain access the host of new features included in the MU 2014 Certification Requirements. In this post, we’ll dig into one of these features: EHR-based secure e-mail capabilities that operate using the “Direct Project” specification. (If you’re new to this world: when you hear “Direct Project,” you should think “secure e-mail for healthcare.”)
Since 2010, the SMART team has been privileged to work on an exciting frontier of health data liberation, exposing structured patient-level data through an open API. We’ve striven for simplicity, with a constrained set of well-described data models, fixed vocabularies, a clean REST API, and Web-based UI integration. And we’ve endeavored to use existing standards where they fit the bill: that is, when existing standards were openly available and met our own subjective criterion of developer-friendliness.
When we launched our first preview of the SMART API back in 2010, there was no structured data content standard that fit the bill, so we rolled our own. We started with simple models for Patient, Medication, and Fulfillment, and over time we’ve expanded the collection to encompass over a dozen top-level clinical statements. Building and maintaining these data models was never our core goal, but until recently, there hasn’t been a suitable alternative on the horizon. Continue reading “SMART, FHIR, and a Plan for Achieving Healthcare IT Interoperability”
Over the past six months, I’ve had the privilege of working with the Automate Blue Button Initiative on BlueButton+ specifications for sharing data with patients. Since ABBI’s core goal of enabling automated patient access to health data is so closely aligned with SMART’s vision, it was exciting to see the initial (Push-based) BlueButton+ specifications implemented at HIMSS 13 this month.
Progress in ABBI’s Pull Workgroup has been slower. We’re hashing out the details of an OAuth2-based framework that puts patients in control over when and how apps can fetch health data. An important question has been: how can we enable an ecosystem where thousands of apps connect to providers across the country in a trusted way?
The SMART team is proud to introduce the C-CDA Scorecard, a web-based tool to help vendors, providers and other health data holders produce high-quality clinical summaries for Meaningful Use Stage 2.
Get ready for Meaningful Use Stage 2
Consolidated Clinical Document Architecture (C-CDA) is the specification cited by Meaningful Use Stage 2 for creating structured clinical summary documents. C-CDA documents are required by MU2 to support transitions of care, to enable patient-driven “view/download/transmit” objectives, and to promote medical record data portability.
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?
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:
“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.
“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.