SMART Advice on JASON (and PCAST)


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.

JASON, PCAST, and the desire for an architecture

The 2014 JASON report, like the PCAST Health IT Report of 2010, advocates for a broad-reaching Health IT architecture. Such an architecture would expose rich automated data flows, giving client applications nimble, fine-grained access to individual- and population-level patient data through open, predictable (but flexible!), publicly documented, standardized APIs. In short, two groups of experts, separated by four years and a massive national sprint toward EHR adoption, have advocated for a world where health data can flow as needed, but where patients retain control of how their records are used.

Are we there yet?

There’s no doubt that Meaningful Use has spurred rapid adoption of EHRs. And these products come with a few building blocks for interoperability, including the ability to export Consolidated CDA documents that support transitions of care. But in my experience, these documents frequently occupy a no-man’s-land of interoperability. They’re notoriously:

  • too long and detailed for a human to read
  • too semantically imprecise for automated reasoning
  • difficult to decompose into individual discrete “atoms” of meaning
  • inaccessible through any standard API (across Health IT products)

At a high level, we need to recognize that the JASON (or PCAST) vision is not the reality on the ground today. Yes, there are bright spots within individual organizations that have built rich internal architectures; but by and large, today’s Health IT ecosystem falls wildly short of the vision.

What can SMART bring to the table?

Reaching architectural consensus at the national level is a great and worthy challenge. But I think that SMART Platforms can offer some very practical guidance. Over the past four years we’ve iterated on a series of open specifications that support the kind of interoperability that JASON and PCAST envision. Our most recent undertaking, SMART on FHIR, provides an entirely open standards-based technology stack for exposing health data to apps. In a nutshell, SMART on FHIR provides:

  • discrete clinical data exposed through the FHIR REST API
  • Consistent metadata around non-discrete data (e.g. free-text clinical notes)
  • MU-oriented “Profiles” for vocabulary standards (RxNorm, SNOMED CT, and LOINC)
  • Authorization via OAuth2
  • Authentication via OpenID Connect

With these building blocks, SMART on FHIR enables third-party apps that help clinicians, patients, and researchers unlock the power of detailed clinical data.

What does SMART leave out of scope?

SMART’s architecture does not create a centralized repository where clinical data are merged or reconciled across clinical systems. Instead, we focused on allowing individual systems to expose their data and integrate apps. This approach provides critical but parsimonious underpinnings for diverse downstream use.

How much should ONC and CMS regulate?

The SMART Platforms team has focused on build specifications that support clinician-facing apps at the point of care, as well as consumer-facing health apps and health research tools. Working with partner organizations through the SMART Advisory Committee, we’re actively pursuing an “all of the above” strategy. In practice, though, there’s a big difference between “what can be done?” and “what should be regulated?” When it comes to advice for ONC and CMS, our goal is to optimize real-world impact while limiting the cost and effort required for implementation. Where is the right balance?

A brief history lesson: where did “View Download, Transmit” come from?

Back in 2010, ONC convened a “PCAST Workgroup” to respond to the PCAST report, much as they have now convened a “JASON Task force” to respond to the JASON report. Looking back at the PCAST Workgroup’s final report, one of the key insights was: for maximal impact, ONC should focus on making data accessible to patients. These recommendations paved the way for MU2 “View, Download, Transmit” attestation requirements and certification criteria.

How does MU2 “VDT” fall short?

In practice, “View, Download, Transmit” has fallen well short of the promise that Todd Park energetically refers to as “Data Liberación”. To mind, the key limitations have been:

VDT provides access to only a tiny slice of “summary” clinical data known as the “MU2 common data set”. This tiny slice of the record is sterile, failing to capture the rich clinical narrative that today often exists only in free-text clinical notes.

VDT provides no automated way to connect clinical data to downstream apps. Direct messaging was supposed to help here, but in practice there were three key deficiencies: 1) Direct transmission is not actually required for MU attestation to VDT; 2) even for systems that support Direct, the patient-facing sign-up workflow is clunky and real-world trust relationships are rarely in place; 3) VDT portals generally support sending only a single clinical summary or visit summary at a time, with no way to create a persistent or ongoing feed.

Advice to ONC, CMS: embrace JASON’s vision by mandating a well-defined patient-facing API for MU3!

Based on my work with SMART Platforms and the Blue Button community, I’m convinced that patient-facing APIs are the right target for regulation. Why?

First, because JASON and PCAST both envision a future where patients decide whether and how their data can be used downstream (outside of legal obligations like mandatory reporting requirements). Architecturally, exposing data to patient-authorized apps provides an enforceable way to realize that vision of patient control. For example, let’s imagine a research study that wants to recruit patients to share their medication history data. Research investigators can ask for patient authorization to access clinical records using a standard Web-based flow. It’s an entirely familiar pattern, like authorizing Candy Crush to access your Facebook profile.

Next, a patient-facing API is the right regulatory target because organizations will naturally look to leverage the work they’ve invested in supporting patient-facing apps. After all, the very same specifications that enable patient access can be made available to clinicians as well. Once the implementation work is done for patients, organizations will be self-motiv

ated to implement these technologies for clinician-facing apps.

Even if clinician-facing APIs do not organically emerge, a clever set of clinical app developers will discover that they can “exploit” (in the best sense of the word!) patient authorization to retrieve data for downstream display to clinicians. This is how “patient-mediated exchange” plays out in a world where health data are universally exposed to patients.

How can ONC and CMS define APIs?

ONC and CMS should begin the transition to a JASON- or PCAST-like architecture by focusing on patient data access. Build in strong guarantees by requiring provider organizations to support a well-defined patient-facing API based on FHIR, OAuth2, and OpenID Connect. And ensure that patients can run whatever apps they choose by explicitly requiring healthcare provider organizations to allow dynamic app registration.

I should provide an important clarification: all of these technologies need to be “profiled” in order to work together. Just naming the technologies and throwing them into a mix does not solve the interoperability problem. A working system must specify precisely what data, what coding systems, what authorization flows, etc. This means that ONC must take responsibility for defining or adopting a set of well-defined profiles that can be implemented by every participant in MU3. I believe that SMART on FHIR is right place to start, but such details must be determined by the broader community.

A call to action for the Health IT community

I look forward to working with my colleagues in the JASON Task Force to move this debate forward. In the interim, we at SMART are working with a coalition to put these ideas into practice, to iterate on them, and to build real-world implementations that can inform future policy-making. We are specifically focused on extending the SMART on FHIR platform. Join our Google Group, expose some data, try our apps or build a new one, and share your experience with the community.

We’re very fortunate to be working with a diverse and deeply knowledgeable Advisory Committee that includes Hospital Corporation of America, Eli Lilly and Company, SureScripts, and the Advisory Board Company. We will be looking to expand these collaborations and push apps into clinical production — whether for patients, providers, or researchers. Stay tuned.

It’s About Time: Open APIs Finally Burst onto Healthcare’s Sluggish Scene


Nuviun Blog, June 9, 2014 — Sue Montgomery
In the midst of the struggles that we face with interoperability, efforts that support open API use may well hold the keys to the HIT Kingdom…

Advisory Committee Kickoff a Success


The SMART Advisory Committee had a high-energy kickoff meeting on May 15. Below are some scenes from the day, which featured presentations by Joshua Mandel and Clayton Christensen as well as demonstrations of apps to be deployed in the near future.
Read more

Forbes Adds to Advisory Committee News Coverage


Today Forbes published Who’s Who Of Health Care Join Forces For SMART Technology, the latest in recent news coverage of the SMART Advisory Committee launch.


Other pieces include:
Read more

Aneesh Chopra’s New Book Points to Launch of SMART Project


Aneesh Chopra, America’s first Chief Technology Officer and member of the SMART Platforms Advisory Committee, has published a new book called Innovative State: How New Technologies Can Transform Government. The SMART Project’s kickoff ITdotHealth meeting in 2009 is among the formative events he describes in Chapter 4, “Opening the Playbook.” Here he is seen with Ken Mandl at the Harvard Book Store, where he discussed the book on May 21. A video of the talk is provided by WGBH.


Introducing the SMART Advisory Committee


Our new advisory committee, made up of member organizations with strategic interest in transforming how the healthcare enterprise uses data, will play a critical role in guiding the SMART Platform toward broad adoption and use.

Learn more

SMART Advisory Committee

Disturbing state of EHR Security Vulnerability Reporting


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!
Read more

Case study: security vulnerabilities in C-CDA display


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.
Read more

Security vulnerabilities in C-CDA Display using CDA.xsl


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.
Read more

HIMSS14: Health IT’s Next Boom Cycle



InformationWeek Healthcare, February 25, 2014 — Mark Braunstein
We’ve seen health informatics booms and busts before — will this one be different?
I’ve been attending HIMSS for decades, and in my view, the exhibit hall is the place to get a true pulse of the industry and the field in general. Over the years we’ve seen booms and busts. I remember HIMSS in my hometown of Atlanta during the heyday of health information exchange in the 90s, when the regional phone companies (remember them?) had huge exhibits touting their entry into the health informatics space…

Read more