SMART apps in the EHR --- this is progress!

Last week I had the opportunity to visit my old hometown while attending the SMART conference at Harvard Medical School (and as a bonus I got to catch up with my dad at the super-yummy Publick House in Brighton). I always have high expectations of the Ken and Zac show, but this one was even more notable than most. It was a bit of a sequel to the 2009 ITdotHealth conference that built on their NEJM article about “substitutable apps” --- since then they’ve received a SHARP grant to make their ideas into something akin to reality, and frankly have done a ton of cool stuff.

The concrete manifestation of this research is the evolving SMART platform --- an open source environment that creates an abstraction between “containers” (data sources like an EHR or clinical data warehouse) and “apps” (bits of end-user functionality) --- so that they can be mixed-and-matched at will, without additional integration or customization (for those of us keeping score, more evidence that every computer science problem is a normalization problem).

The clearest way to get a sense of the benefit here is to check out the Blood Pressure Centiles app that is actually deployed and being used in production at Boston Children’s. Determining “normal” for a child’s BP requires some math, incorporating age, gender, height, weight, etc. as inputs. Not rocket science, but also a somewhat specialized function that has been on the “to do” list for the EHR for years and never quite made the priority list. By conceiving this as a SMART app, they were able to “inject” the functionality directly into the EHR without any custom development. And to drive the point home, we saw the same app running without modification on an i2b2 data warehouse, the MIRTH results HIE client, and maybe another one I can’t remember. Pretty sweet.

Certainly I can quibble with a few choices the team has made, but that’s the point of the research, and the cool thing about the way the SMART team has done it is that, well, they’ve done it --- having a debate with Josh about what works and what doesn’t isn’t an academic exercise, it’s real-world problem solving. Refreshing.

So …. on the plane home I decided to put my IDE where my mouth was and build a SMART app for HealthVault. We spend a lot of time trying to help providers comply with the patient engagement metrics around meaningful use, so that was an obvious place to start. Thus was born the “HealthVault SMART Patient” app … which enables any provider using a SMART-enabled EHR to send their patients a copy of their clinical information as a CCD/C32 document:

The app uses our “drop-off/pick-up” functionality --- patients receive an email containing a URL and “pickup code;” these together with an extra challenge question are used to collect the information in a HealthVault record. Individual items (medications, etc.) in the CCD are extracted to help the user construct a complete and up-to-date health record that they can share with other providers or family members, and/or use with any of the hundreds of web and mobile applications built on top of HealthVault. Sweet!

I was pretty impressed with the SMART development experience … getting started was simple, and while I wouldn’t have chosen RDF/SPARQL, that was just mechanics. Having the object model just “there” on my pages was pretty incredibly awesome. I even hosted my app up in Azure without a hitch.

If you’d like to try the app for yourself, just create an account on the SMART Sandbox EMR, click the “Manage Apps” button at the bottom left, add the “HealthVault SMART Patient” app and you’re off to the races. Note that of course this app is running against the HealthVault partner test environment and should NOT be used with real patient data. It also only includes medication data at the moment and isn’t running on HTTPS … things I’ll fix over time but aren’t super-relevant to the demonstration anyways.

If your EMR is running a SMART container and you’d like to use the app in production with real folks in support of patient engagement and meaningful use, just drop me a note using the contact form on this page (I’m looking at you Children’s) … would love to discuss it.

Congrats to the SMART team --- you’ve done some great work, and it was fun to reconnect in Boston. Looking forward to continued progress over the upcoming months!

Comments

• Anonymous
  September 18, 2012
  Thanks for sharing this Sean. We are evaluating HealthVault to meet our meaningful use requirements and were really impressed by the simplicity of the drop-off/pick-up model. As you know stage 2 requires the providers to track the percentage of patients that actually downloaded the information. Does the drop-off/pick-up provide any way for the provider application to do that? If not, is there any plan to add that? Without that it really wouldn't help meet stage 2.

• Anonymous
  September 18, 2012
  Steve --- thanks for the note! We do have an option for partners to receive quarterly reports that detail how many packages were actually "picked-up" to support the activation metric. Happy to discuss further if useful! ---S

• Anonymous
  September 29, 2012
  Sean, Would this be the PHR equivalent to an ABBI application? Seems from your description this App could be a Patient bridge between an EHR offering an ABBI interface and your HealthVault PHR where you (patient) store the results. How do you  see SMART and ABBI relating? John

• Anonymous
  September 30, 2012
  Hey John! I hadn't really thought about the connection with ABBI, but they could work together really well. As in --- a SMART app could easy (a) manage the 'setup' of an ABBI request, i.e., the association with a target address; and (b) run a background process that sends off CCDs (or whatever) when appropriate. The only trick would be --- the version of the SMART API I currently have been working with doesn't have an efficient way to trigger on updates in teh EHR ... but pretty much every API has to face that eventually so I bet we can get Josh to look at it. Great idea --- and maybe the right way to think about an ABBI reference implementation. Would be SUPER-cool to have a reasonable path to put "ABBI compliance" into an EHR without one-off work beyond the SMART container baseline. I'll share this with the SMART team too and add you to the thread ... sweet! ---S

• Anonymous
  October 23, 2012
  Does the app use the physician-identifying information directly from the EHRs or do you license physician information from a directory? Awesome app!

• Anonymous
  October 26, 2012
  Roman --- thanks for the note! A cool thing about the SMART API is that the context of the physician and patient is available to the app directly from the EHR ... so no new directories or such required. It's really a great model.