A clinic decides to build an AI app to detect a rare disease at its early stages by analyzing patient data. They develop the app and connect it to their healthcare systems (including an EHR) to feed patient data into the AI engine. They also loop the AI-processed data back into an EHR.
They’ll soon add an iPhone app that combines the AI output with on-device ML-powered photo recognition to improve disease detection accuracy. How do they manage all of that? They use SMART on FHIR.
So if you think it’s time to get creative with your patient data and start using it to advance to value-based healthcare, you need to know the basics about SMART on FHIR and how it’s used to build advanced healthcare solutions. Welcome to our guide!
- What is FHIR, and Why Does It Matter in Healthcare?
- What is SMART?
- What is SMART on FHIR?
- The Role of SMART on FHIR in Health App Development
- Benefits of SMART on FHIR
- How Does SMART on FHIR Work?
- Challenges with Building Health Apps Using SMART on FHIR
- Steps to Build a SMART on FHIR App
- Our Experience Creating SMART on FHIR Apps
- Case Study: SMART on FHIR App that launches within Epic Hyperspace
What is FHIR, and Why Does It Matter in Healthcare?
Today, siloed healthcare applications don’t cut it anymore unless they integrate with other clinical software, e.g., electronic health record systems or clinical decision support solutions.
Health data needs to flow freely and securely between different digital products to enable better outcomes for patients. That’s where FHIR comes in.
FHIR is a data standard for healthcare data exchange. It defines the type of health data and its format for apps that want to share this data.
For example, when an application needs to fetch patient vitals from an EHR, it needs to know:
- what kind of data is available
- what command it should send to “ask” the EHR for this data
- what responses the app can receive to process them correctly
All of that is handled by the FHIR API, developed under the guidance of HL7, a non-profit organization working on standards for healthcare data interoperability.
Oh, and by the way, FHIR stands for Fast Healthcare Interoperability Resources, if that tells you anything extra, and you pronounce it as “fire.”
What is SMART?
SMART was a similar initiative by healthcare data interoperability advocates who at some point decided to join their efforts with FHIR/HL7.
SMART stands for Substitutable Medical Applications, Reusable Technologies — a specifications framework that lays down the standards for health data interoperability.
The idea sprung in 2010 on the heels of smartphone innovations and presumed there should be a common API for exchanging health data. As a result, healthcare providers could easily swap out different applications by independent vendors to see what’s working best for them.
Before SMART on FHIR, their only option was to turn to their EHR vendors to build necessary applications that could access EHR data because of closed APIs.
What is SMART on FHIR?
The magic really happens when both standards meet together. Smart relies on FHIR data standardization while also providing an additional security layer for authorization and a set of “profiles” that help developers effectively work with clinical data.
In plain English, SMART on FHIR makes it easier for developers to build health apps that integrate with EHR systems and other clinical software:
- developers deal with concrete data objects (like allergy or prescription) as opposed to using abstract data layers (read simpler and faster coding)
- data is always shared in a digestible, predictable format, and there are fewer bugs related to data processing
- widely applicable data-type templates win over interface-specific definitions
If someone asks you, “So what’s this SMART on FHIR thing, again?” tell them it’s a health technology standard we need in our products to enable secure and reliable medical data sharing.
Many healthcare vendors already support SMART on FHIR (through the Argonaut Project initiative):
The Role of SMART on FHIR in Health App Development
When do you need SMART on FHIR? This technology standard comes into play when you develop a health app that uses protected health information (PHI), pulling or sharing it with other external systems. In 99% of cases, that’s a health app integrated with an EHR/EMR system, or a patient app / portal, or a clinical data warehouse.
Building your app using SMART on FHIR, you’re making your health app future-proof as it will be much easier to integrate it with other applications. Let’s briefly review other advantages of SMART on FHIR integration.
Benefits of SMART on FHIR
We already kind of get the main upside of the technology (improved interoperability), but what are some other SMART on FHIR benefits?
Ease of integration for developers
There are hundreds of licensed EHR systems in the U.S., and all of them used to have their own standards (most still do) of exporting and importing PHI data.
With SMART on FHIR, developers no longer need to worry about learning particularities of integrating their health apps with various EHR/EMR systems. Correspondingly, the cost of developing EHR-compliant health apps comes down.
Related: How to Develop EHR/EMR System
Interchangeable apps for providers and patients
If adding interoperability becomes easier and more apps become available as a result, providers and patients find themselves in a situation when they can start trying different apps. Health apps built on the SMART on FHIR principles are easier to switch. So healthcare providers can quickly find an app with the optimal user experience.
How do you ensure that each clinician gets access precisely to what they need, without giving them overly broad access to all patient data in the system? SMART on FHIR gracefully takes care of this issue by adding the authorization and authentication layers to a health app.
In addition, the technology provides support for single sign-on so that users can log in once and then switch between different health apps that share PHI data without signing in individually into every single app.
Finally, some clinicians are reluctant to use a separate standalone app that pulls patient data from their EHR. Ideally, they’d like to access this other health app’s UI right inside their EHR or another clinical system. SMART on FHIR works perfectly for this purpose.
How Does SMART on FHIR Work?
SMART on FHIR developers would need to implement a few industry standards according to the specifications, using the REST-based APIs:
The technology presents two variants of working with health apps that need to integrate with EHR systems:
- standalone apps that launch independently from the EHR
- apps that run right inside the EHR’s interface
Of course, to launch a health app from inside an EHR system, it needs to support SMART on FHIR.
SMART on FHIR API enables the development of various applications:
- iOS, iPadOS, and WatchOS apps
- Android apps
- Epic, Cerner, Allscripts, and other EHR vendors
- Google and Microsoft provide SMART on FHIR-ready cloud services
Challenges with Building Health Apps Using SMART on FHIR
Despite all the SMART on FHIR benefits, developing SMART on FHIR apps poses certain challenges to healthcare app developers.
Not all vendors support the technology
Only a handful of EHR vendors officially support SMART on FHIR. These include Epic, Cerner, Allscripts, Intersystems, and Meditech. Documentation is also somewhat scarce at the moment, and there are not many app developer forums to find answers.
The reality is you can’t write an app once and then integrate it with thousands of EHRs out-of-the-box. Again, not all vendors provide support for this technology, and those few that do, still have specifics about how you should integrate a health app with them.
Steps to Build a SMART on FHIR App
Step 1: Choose the type of the app
The first step when you create a SMART on FHIR app is to define what type of app you’re building:
- provider- or patient-facing apps
- mobile app or web application
- if web app, will it work inside an existing clinical application or as a standalone app
That means we don’t necessarily need to code all interoperability functionality from scratch and instead take a shortcut while focusing on core application features instead.
On the server side, we can pick from Azure and Google cloud services that are SMART on FHIR-ready, but other cloud providers like AWS will work too, maybe requiring slightly more effort. [AWS is actively working on enabling a SMART on FHIR turn-key cloud solution].
Step 2: Implement security
SMART on FHIR handles security by using OAuth 2.0 and OpenID specifications. This approach ensures that providers can switch between integrated apps without entering their credentials each time. They also don’t need to enter their password into third-party solutions because authorization happens via their EHR systems. System owners can define in the EHR system permissions and access levels for different users.
Of course, regular HIPAA compliant app development procedures that include data encryption, use of secure connections, etc., apply here as well.
Step 3: Build the features
The next obvious step is to develop all the required features. When we build a SMART on FHIR app, we pay special attention to daily and weekly meetings to keep our customers on track about current progress.
Step 4: Test using SMART sandboxes
As you can imagine, testing healthcare applications is quite challenging because of the nature of data that they use. For SMART on FHIR implementation, it’s recommended to use a SMART sandbox for testing your app’s features.
EHR vendors like Epic also provide their separate sandboxes for testing your product with their EHR systems.
Besides sandboxes that effectively emulate a working EHR interacting with your health app using SMART on FHIR interfaces, you can use synthetic patient datasets for testing. Synthetic means the data is not real but still realistic. You can also make use of anonymized patient data.
It’s also worth noting that besides SMART on FHIR API, EHR vendors such as Epic try out other FHIR-enabled data sharing models, for example, Epic USCDI API. But that’s an entirely separate topic, and we’ve covered the subject at length in a separate blog.
Step 5: Deploy and add to an app gallery
After you’ve tested the app, it’s time to deploy it to a production server or make it available for your staff and patients via a mobile store. One nuance with SMART on FHIR-enabled applications is that you can also add them to a specialized app gallery where healthcare organizations can discover them.
The app gallery is similar to a mobile store in terms of providing info about the app description, requirements, and the opportunity to test the application.
Our Experience in Creating SMART on FHIR Applications
This project also provided us with the opportunity to hone our cyber-security skills while we implemented EHR OAuth2 authentication server to secure the solution.
Case Study: How to Build and Launch a SMART on FHIR App within Epic Hyperspace/Hyperdrive
Let’s say an Epic-equipped clinic decides to implement a remote patient management program for their elderly patients to prevent falls.
The setup background
A possible setup for implementing this solution may include:
- Patient mobile app with on-device AI/ML data processing
The mobile app gathers from phone sensors all sorts of data, including walking speed, step length, double support time, and walking asymmetry – to measure walking steadiness. We want to keep all this data securely (and quickly) analyzed on the phone so we can calculate a score and send it to a cloud app together with a patient ID.
- Cloud application for providers with aggregated patient health data, dashboard, alerts, and all the data analysis/visualization goodies
Providers access this cloud app via a web browser to view all patients, classified according to their fall risk, data trends, etc. Additionally, they receive notifications about patients with rapidly deteriorating conditions.
What are we solving here?
The only issue is that now providers need to jump between the Epic EHR and this standalone web software. Healthcare app developers would have to set up provisioning and access rights in this application. Providers would need to keep another instance of credentials to log in. This may sound simple to an outsider, but clinicians know it can quickly become a mess.
That’s where SMART on FHIR (and a little bit of digital magic on the Epic side) comes to the rescue. Using this technology, we can seamlessly integrate the web app with the Epic EHR’s main interface called Hyperspace (or Hyperdrive in newer versions) so that it opens the web application right inside Epic – no need to switch the working environments for providers anymore. And the best part? No need for a separate login – because providers are already logged in with the EHR and can rely on single sign-on (SSO) architecture.
Why are we doing this?
SMART on FHIR offers significant advantages by enhancing providers’ workflows within the familiar EHR system. This technology empowers healthcare professionals to seamlessly integrate new functionalities, streamlining their processes and ultimately improving patient care:
- An application opens directly within the EHR and can share patient context so you know what chart the provider is in.
- The application can navigate within the EHR, open a new chart, and link the user to other Epic activities. This adds tremendous benefit to clinicians and allows them to use the app as a “main dashboard” for their work.
- Backend integrations made available by the app can grab fresh data from the EHR on-demand and analyze/display it in the app.
The building part
SMART on FHIR uses the OAuth 2.0 authorization framework at the backbone, which has become the industry standard for implementing authorization/authentication. So, when we are developing a SMART on the FHIR app, we build on top of OAuth 2.0, but with the addition of an FHIR server for defining the data exchange format when syncing medical data between the EHR and our web software.
The SMART App Launch Framework allows us to connect the clinic’s web app to EHR data, supporting the app’s launch from inside or outside Epic Hyperspace/Hyperdrive. The framework provides a reliable, secure authorization protocol for various app architectures:
- apps running on a local machine/device
- apps running in the cloud on a secure server
This is extensively covered in HL7’s FHIR guidelines.
In addition, some configuration within Epic is required, for example, the integration with a standalone app must be enabled and a button must be created and made available to the right users. Fortunately, this button looks and works completely native to the Epic EHR.
Deploying a SMART on FHIR App
Besides configuring Epic to launch an external app inside the EHR and adding the secure authentication layer (with SMART on FHIR), we can also add the app to Epic’s app gallery – what used to be Epic App Orchard and has become Connection Hub.
This is done through a developer account over at fhir.epic.com. That’s also where you “build” SMART on FHIR apps, or rather define the parameters (such as API endpoints, app URL, CDS hooks, etc.) for interconnecting an already built (hosted and running) app with Epic.
However, please note that adding an app to Epic’s Connection Hub is not required. Many application vendors believe they need to pay fees to Epic in order to get their app working with the EHR. This is not actually the case. You can set up an application on fhir.epic.com at no cost, and you do not need to list it in Epic’s Connection Hub in order to integrate with a health system. The hub is where Epic customers and developers can discover your app.
Keep in mind there’s also a listing fee to take care of before finalizing your listing in Connection Hub.
Time to Build Your App
If you’d like to discuss how SMART on FHIR can help you set up interoperability in your family of healthcare apps, reach out today. We’ll be happy to elaborate on how this technology can help you put patient data to use and transition to value-based healthcare.
- How to create a telehealth application
- Hospital Management System Development
- Build a doctor appointment application
- Patient Portal App Development Guide
- Medical Website Development Guide
- Healthcare App Development Guide
- Healthcare Mobile App Design Guide
Frequently Asked Questions
What is the difference between HL7, SMART on FHIR, and FHIR?
FHIR is a standardized API for sharing health data, SMART on FHIR is one of the implementations of FHIR, which is rapidly becoming the standard, and HL7 is the organization that oversees the FHIR standard development. Therefore, SMART and FHIR are standards, while HL7 is an organization.
Do I need to stick with particular EHR systems if I want to build a SMART HL7 backed app?
Epic, Cerner, and Allscripts provide official support for SMART on FHIR. You may need to check with your vendor if they work with SMART on FHIR, but those three — you can count on and use their documentations and sandboxes for testing.
Do all apps need to be added to the SMART on FHIR applications store (apps.smarthealthit.org) at the SMART site?
No it’s not required.
How do you implement a SMART on FHIR authentication protocol if you're adding it to an existing medical system that already uses OAuth 2.0?
What EHR and other clinical systems support SMART on FHIR?
Platforms that fully support the API include Epic, Cerner, Allscripts, Athena Health, and Meditech. There are also a few provider organizations like Mayo Clinic and Intermountain Health.
Written in co-authorship with Scott Rossignol, EHR Integration Lead.