Current EHRs are among the most complex pieces of software
ever written. They serve a critical role to help standardize clinical workflow,
facilitate billing, and integrate simplistic forms of clinical decision
support, yet tremendous effort is required to customize EHRs to meet
the needs of diverse hospital systems.
In order to have a compelling demo, we wanted to show several types of apps running in multiple environments. We chose:
We felt there had to be a better way.
Starting in 2012 we started investigating ways to create a
framework built on top of our Epic-based EHR that would allow us to access the
EHR in a standard way from any device or platform. By the summer of 2013 we had
a functional proof of concept that allowed us to access patient demographics,
problem lists, medications and more from a simple Android app. Duke Apps
Supporting Healthcare, referred to internally as DASH, was born!
Around this same time, we started learning more about a
similar effort underway at Boston Children’s Hospital called SMART (Substitutable Medical Apps and
Reusable Technologist) that incorporated a new REST-based open API called FHIR (Fast Healthcare Interoperability
Resources, supported by HL7). Since our goal
was general ease of use and interoperability, it made sense to join this
effort, originally funded by the ONC via the SHARP program.
There were already several proof-of-concept apps written to be SMART on FHIR compliant, so from a practical standpoint, this made sense.
We updated our code to be compliant with both SMART and FHIR and as of January 2015 we became the first Epic-based hospital system to run unmodified SMART apps within our EHR (in our proof of concept environment).
We updated our code to be compliant with both SMART and FHIR and as of January 2015 we became the first Epic-based hospital system to run unmodified SMART apps within our EHR (in our proof of concept environment).
We were thrilled to present this work at the HIMSS 2015 national conference, and you can view a sample the demonstration here (UI bits blurred at Epic's request):
In order to have a compelling demo, we wanted to show several types of apps running in multiple environments. We chose:
- Growth Chart, an open-source pediatric growth chart app with an award-winning interface
- Meducation RS, a closed-source app by Polyglot that presents a patient's medication list in simple language translated into 21 languages
- Duke PillBox, a skill-based interactive learning tool to help patients teach themselves how to take their medications as part of the discharge process. This was developed by MedAppTech for a Duke research initiative.
We demonstrated each of these apps running in both the Epic desktop environment as well as the Epic mobile apps for iOS. Once the infrastructure was in place, it took less than 5 minutes to add these SMART apps to our mobile EHR. Playing with FHIR has never been so fun (or easy)!
Finally, we also demonstrated a native iOS app, Pediatric Growth Charts, that we launched with the patient context from the Epic iOS app.
So, we demonstrated an open source app, a closed source app, and an internally-developed app all functional within desktop and mobile EHR environments, plus a native iOS app to boot. And we're just getting warmed up!
Probably the most frequent question I get is: How did you do it?
Answer: Very carefully.
Ok, so the real answer is that this was a development effort in the truest sense of the phrase. Prior to our switch to Epic, Duke had a home-growth EHR, which means we have some seriously talented developers here who know how to write production-grade EHR code. In this case, we were able to use many of the web services already provided by Epic and simply add a FHIR wrapper. Some data elements required a bit more work. To tie it all together, we wrote a rate-limiting and authorization server in Node.js and installed MITREid Connect to handle authentication.
Is this the path we'd recommend for everyone? No, probably not. Fortunately, most hospital systems won't have to write their own SMART on FHIR implementations. Through the Argonaut Project, many major EHR vendors and academic medical centers have committed to FHIR as well as the OAuth profiles needed to make it all work. This includes Epic. So hang tight, and your EHR vendor of choice will likely soon provide you the tools you need to kindle the flame.
Duke is involved in Argonaut as an "Implementer," which means we have real-world experience implementing apps that use the standard, and have provided feedback to improve both SMART and FHIR.
As I've said before, there probably hasn't been a more exciting time to work in healthcare technology. Between novel patient engagement tools such as HealthKit and Google Fit, cutting-edge research platforms such as ResearchKit, and now truly modern APIs that will usher in a new generation of substitutable EHR apps, there's plenty to keep us busy, and most importantly, to help patients take better care of themselves and providers take better care of patients.
And the best part? Things are just starting to heat up ...
