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.