SMART Part 1: Sneaking Innovation into Care Delivery

There’s no shortage of innovation in Healthcare… sort of. Better to say that there’s no shortage of innovation in diagnosis and treatment. The drugs and tests and equipment coming to market these days are stunning. But “Health IT” — the software and systems that coordinate and manage the delivery of care — not so much.

Which isn’t to say that there aren’t good ideas — it’s just super-hard to actually get them implemented and into use. Enormously complex “Electronic Health Records” from companies like Epic and Cerner rule the roost, and don’t generally make it easy to share the sandbox. I have some sympathy for the challenges they face. Healthcare is a weird confluence of science and art and building software to support it efficiently and accurately is just a hard job. Love them or hate them, EHRs are where healthcare workflow happens, period, full stop. When you spend up to $1B to install software (usually less, but looking at you, Mayo) … you’re gonna use it.

All of this makes it really tough to introduce new software into a healthcare environment. IT departments visibly pale at the suggestion. Users are rightfully resistant to logging into yet another app with yet another interface. Even getting over all that, data integrations are insanely expensive and difficult, so double-entry of information (and the mistakes that come with it) are rampant.

The Big Idea

So how do you impact care with software? Don’t fight city hall — instead, find a way to wedge into the EHR, where folks live and breathe. Of course, that’s historically been much easier said than done, thanks to a lack of integration standards and enthusiasm for the concept amongst EHR vendors. (This “lack of enthusiasm” has been so problematic that language in the federal Cures Act actually calls it out!)

Viva the Revolution! Back in 2009, Zak Kohane and Ken Mandl wrote a landmark article in the NEJM titled “No small change for the health information economy.” The full text is behind the journalwall, but in short they said, “We need an iPhone App Store for Health IT and we’re going to figure out how to make it happen.” This kicked off a series of events that ultimately have come together as SMART on FHIR.

SMART on FHIR

At its core, SMART on FHIR (I’m just going to call it SMART from now on) provides a way to embed your own application into the context of an EHR experience. It’s a combination of technologies that let you:

  • Share the EHR’s login context, avoiding extra passwords and double-login.
  • Exchange data (read and write) with the EHR, avoiding duplicative data entry or storage.
  • Appear within the EHR user interface, providing a comfortable look-and-feel for users.
  • (Not strictly part of FHIR but key) Publish your applications in EHR “app stores” so users can find and, more importantly, install them without a heavy IT lift.

Sounds awesome. And it is, but fair warning: over the course of these articles I’m going to complain a lot about how SMART works. I mean, A LOT. So let me reinforce that I truly believe that it can and should be “the” transformative technology that breaks the juggernaut on Health IT innovation. I love it. I love the people who thought of it. I love the developers I know who have worked on it. I love that ONC has embraced it. It is awesome. OK.

That’s a good setup for the first big challenge. SMART is SUPER-broad — provider and patient apps, online and offline access, real-time and batch data, all served up with a big helping of optionality and vendor-specific noise that can make it hard to see what I believe is the much more targeted but revolutionary opportunity:  Get third-party, real-time workflow innovation for caregivers into the EHR.

Seriously, every single company trying to impact care delivery needs to start thinking about SMART as their primary user interface. Sure, you’ll probably need to have a “lowest common denominator” version that stands alone — but treat that as a backup, not your lead. I promise that if you demo your solution embedded with shared login and no separate UX, you’ll get farther faster every time.

How Can I Help?

Lack of awareness is not the only thing hampering SMART adoption. The excessive optionality that dogs pretty much every healthcare standard is an anchor around SMART’s neck as well, making it unreasonably hard to do simple things like access a moderately clean list of a patient’s current health conditions, or even their preferred name (!!!).

My goal is to eliminate as much of that complexity as I can, so that building a SMART app is trivial. “ShutdownTrials” is a complete, standalone, 99% dependency-free (it does use Gson) project that tries to do this in three acts:

  1. SmartEhr: a headless Java-based library for implementing SMART in any JVM-based application environment with minimal effort.
  2. SmartServer: building on SmartEhr, an extensible, secure web server that handles all of the HTTPS interactions required to launch and authenticate an application.  
  3. ClinicalTrialsServer: building on SmartServer, a working, turnkey demo application that embeds contextual search for clinical trials into an EHR.

These can be used independently, so you don’t have to buy into my web server to use the backend. All have been tested with the Epic and Cerner sandboxes, and the Clinical Trials search application could be installed into production EHRs today (drop me a note if you’re interested, I’d be happy to help get it running at your site as a SMART proof-of-concept).

The code is all available, license-free, on Github. Over the course of this series I’ll dive into the implementation: first the basics and auth sequence, then a deep look into the data model and how I’ve tried to make the information there easier to consume. I’ve tried to optimize for time-to-production in my specific scenario, so the code looks a little different than other libraries. There’s a lot of it; we’ll take a few rounds to cover it all!

Enough Talk – try it live!

Point your browser at https://shutdowntrials.duckdns.org:7071/ to get started. This is just a landing page with a bunch of links that launch into the experience. For now, click on the one that says “DSTU2 with patient/doc pre-selected” (or click the link in this sentence I guess, doh).  

You should see something that looks like the screenshot to the right — a “Simulated EHR” that shows potential clinical trials for imaginary patient Phillip Jones. If you want to fine-tune the search, edit the demographics or use the checkboxes, then click “refresh list”. For example, the EHR doesn’t provide an address for Phillip, so you can fill in the country “US” to see only trials in the United States.

These results come from http://clinicaltrials.gov, a public repository of clinical trials maintained by the NIH. Beware that choosing multiple conditions will often lead to empty results; just aren’t a lot of combo trials for sinusitis, ED and rosacea!

Next, try going back to the launch page and clicking on “DSTU2 with patient/doc picker”. This time, before you see results, you’ll have the option to “log in” to the EHR and select a test patient. This will land on a search experience where the demographics and conditions are appropriate for that patient. Nice!

Here’s what is going on behind the scenes:

  1. Your browser starts at the SMART App Launcher, a development sandbox maintained by the good folks at smarthealthit.org. While vendors like Epic and Cerner have quite serviceable development environments, SMART is nice because it’s completely open and has a solid selection of test patients to work with out of the box.
  2. Once the provider is logged in and the patient is selected, a negotiation sends your browser back and forth between the EHR and ShutdownTrials a couple of times. The end result is that we prove to each other that we’re legitimate, and the application receives a token that can be used to read and write EHR data.
  3. The application requests demographics and condition data for the patient, converts them into an API request at clinicaltrials.gov, and displays the results in the embedded iframe.

Tada! If it all seems very simple in practice, then at least I’ve gotten something right — because it’s anything but simple in execution. Buckle up friends, because the deep dive is going to be a great ride.

*** A last note and request (this will show up at the bottom of each article in the series). I’ve spent a lot of time in this industry, and the systemic impediments to progress and innovation can make even good folks feel hopeless sometimes. I really, truly believe that SMART is one of those rare technologies that has matured at exactly the right time to change the game. But there’s no guarantee — not enough folks know about it, and it’s too hard to use. If you swim in this pool, please help me fix that:

  1. Share these articles with folks that use and implement EHRs. Tell them to look at the “app store” for their system and add an app to their test system. Tell them to ask vendors if they have a SMART interface for their solution.
  2. Share these articles with folks that build care delivery solutions. Explain how they can use SMART to add functionality for customers without a custom login and without having to do an integration project with custom IT teams.
  3. Contact me if I can help. There’s a form here on the website, and I’m @seanno on Twitter, or use LinkedIn, or whatever. I’m happy to answer questions, make some connections, and heck I might even write some code for you if it makes a difference.