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
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.
Security
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.
UX integration
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:
- OAuth
- OpenID
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.
Implementation discrepancies
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
SMART on FHIR offers free tools to speed up SMART on FHIR app development. We can use their libraries for JavaScript, Swift, Python, Ruby, and other popular programming languages.
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].
Related: HIPAA Compliant Video Conferencing and Messaging
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.
Related: Should I buy or build a telehealth solution?
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
One of the most exciting experiences Topflight had with the technology is when we were building a practice management solution integrated with EHRs. Our engineers opted for SmartJS, a JavaScript client for FHIR integrations, which saved us a ton of development time as we were able to integrate the practice management system with Epic and AllScripts EHRs in a matter of weeks (rather than months).
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.
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.
Related Articles:
- 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?
You will need to make a couple of tweaks, adding SMART on FHIR specific parameters, and they cover that here in detail.
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.