This is a quick description of the minimum requirements to turn patient-mediated “transmit” into a usable system for feeding clinical data to a patient’s preferred endpoints. In my blog post last month, I described a small, incremental “trust tweak” asking ONC and CMS to converge on the Blue Button Patient Trust Bundle, so that any patient anywhere has the capability to send data to any app in the bundle.
This proposal builds on that initial tweak. I should be clear that the ideas here aren’t novel: they borrow very clearly from the Blue Button+ Direct implementation guide (which is not part of certification or MU — but aspects of it ought to be).
As architect for SMART Platforms and community lead for the Blue Button REST API, I’m defining open APIs for health data that spark innovation in patient care, consumer empowerment, clinical research. So I was very pleased last month at an invitation to join a newly-formed Federal Advisory Committee called the JASON Task Force, helping ONC respond to the JASON Report (“A Robust Health Data Infrastructure”).
We’re charged with making recommendations to ONC about how to proceed toward building practical, broad-reaching interoperability in Meaningful Use Stage 3 and beyond. Our committee is still meeting and forming recommendations throughout the summer and into the fall, but I wanted to share my initial thoughts on the scope of the problem; where we are today; and how we can make real progress as we move forward.
But my subsequent journey into the world of EHR vulnerability reporting left me deeply concerned that our EHR vendors do not have mature reporting systems in place. Patient health data are among the most personal, sensitive aspects of our online presence. They offer an increasingly high-value target for identity theft, blackmail, and ransom. It’s time for EHR vendors to take a page from the playbook of consumer tech companies by instituting the same kinds of security vulnerability reporting programs that are ubiquitous on the consumer Web.
HL7 and EHR Vendors must address security reporting
For background, see my previous blog post describing the details of three security vulnerabilities in C-CDA Display using HL7’s CDA.xsl.
Last month I discovered a set of security vulnerabilities in a well-known commercial EHR product that I’ll pseudonymously call “Friendly Web EHR”. Here’s the story…
The story: discovery and reporting
I was poking around my account in Friendly Web EHR, examining MU2 features like C-CDA display and Direct messaging. I used the “document upload” feature to upload some C-CDAs from SMART’s Sample C-CDA Repository. At the time, I was curious about the user experience. (Specifically, I was bemoaning how clunky the standard XSLT-based C-CDA rendering looks.) I wondered how the C-CDA viewer was embedded into the EHR. Was it by direct DOM insertion? Inline frames? I opened up Chrome Developer Tools to take a look. Continue reading “Case study: security vulnerabilities in C-CDA display”
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”
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.
With support from ONC, the SMART Platforms team is working with Lantana Consulting Group to simplify and improve data exchange based on the HL7 Consolidated Clinical Document Architecture (C-CDA) standard for health summary data. We are working to ensure that real-world Health IT software can consistently produce and consume C-CDA documents, which will be a Meaningful Use Stage 2 (MU2) requirement for transitions of care between providers and for patients’ access to their own data. To this end, we’re formulating clear, “fill-in-the-gaps” implementation guidance for MU2 certification and beyond.
We’ve assembled a team of Health IT organizations for lightweight participation in a pioneering interoperability collaboration. We will identify and address “grey areas” in at least seven key domains of the C-CDA specification: demographics, medications, problems, allergies, vital signs, lab results, smoking status. Continue reading “Introducing the SMART C-CDA Collaborative”
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.