Last week I reported on a set of security vulnerabilities that affected multiple EHR vendors and other Health IT systems.

I initially discovered the vulnerability in a single Web-based EHR system and successfully reported it directly to that vendor.

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

I’ll lead with the key message here, and provide supporting evidence below: HL7 and EHR vendors need to institute security vulnerability reporting programs!
Continue reading “Disturbing state of EHR Security Vulnerability 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”