SMART on FHIR
Image credit: Computational Health Informatics Program, Boston Children’s Hospital
The SMART Health IT Project was launched with an idea. The idea was to have a universal API (application programming interface) transform electronic health records (EHRs) into platforms for substitutable applications.
You can’t expect every provider at every healthcare organization to use the same apps. Substituting applications gives providers the freedom to try out different technology solutions to pick what works best for them.
SMART stands for “Substitutable Medical Applications, Reusable Technologies.”
Remember, medical applications are built on top of a health system’s specifications, and many health systems use multiple systems for keeping health records. To address this, the SMART on FHIR API was developed as an open standards-based API that allows developers to create an app that runs anywhere in the healthcare system.
“FHIR is all about APIs and interoperability from a data and API point of view,” explains Greg Hodgkinson, Prolifics chief technology officer. “If I’m sharing patient data with one data consumer today and I need to share it with someone else tomorrow, I don’t have to change the format that I exchange it in because they’re all subscribing to FHIR base formats. Everyone’s speaking the same language.”
“The big EHR systems used by providers, there are standard package applications that support the use cases providers need around scheduling appointments, capturing services offered, all kinds of things,” Hodgkinson explains. “That application will have a user interface. What they’d like to be able to do is have a user experience widget to plug into that reusable user experience. Underneath it will be using interface components/FHIR APIs, but what we’d also like to be able to reuse is that little application component itself, because it’s going to be doing all kinds of groovy things with the data.”
What sort of groovy things? Graphing a patients’ health data and correlating it with other data, for example. Or adding it to larger data sets to predict outcomes and train AI/machine learning models.
“What SMART on FHIR adds, from an interoperability point of view, is taking it to the next level by allowing us to reuse the user interface components that do interesting things with this data.”
The Beginning of SMART on FHIR
Let’s go back to the beginning. SMART stands for “Substitutable Medical Applications, Reusable Technologies,” and it began as a standard framework to facilitate the development of interchangeable healthcare applications. These applications should be interchangeable and compatible with any healthcare organization, regardless of EHR.
The U.S. government funded the creation and initial development of SMART in 2010 with a four-year $15M grant from the ONC. The project was originally a partnership between Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics.
Since then, The SMART Health IT Project has attracted the collaboration of many organizations committed to the transformation of healthcare (the SMART Advisory Committee). Today, SMART is a standard that works in conjunction with and on top of FHIR; literally “SMART ON FHIR.”
Today, The SMART Health IT Project is focused on:
- defining the process for interacting with FHIR interfaces;
- outlining how the apps will be “launched” from the EHR;
- standardizing 3rd-party security protocols used to exchange data with EHR systems.
Today, EHR vendors built support for SMART into their products. Hundreds of other tech companies, including Google, Microsoft and Apple, use SMART to make health records accessible. The SMART framework supports apps used by by clinicians, patients, and others via a PHR or Patient Portal or any FHIR system. An app developer can create a SMART on FHIR app and expect it to be compatible with every health care system
Through a project called Argonaut, several EHR vendors have partnered with the SMART team and the HL7 organization to build SMART into the releases of their products, and to standardize the SMART API in HL7 specifications.
Technical Considerations
Taking interoperability to the next level and reusing the user interface components that do interesting things with patient data requires addressing technical issues. How do you make a reusable user experience component? How do you make sure that whoever is using the system doesn’t need to separately authenticate to that user experience component?
SMART on FHIR provides a standard for that level of interoperability.
“In other words, it can do it as part of the overall application, i.e. I log on to the EHR application, and if I click on that little widget, I don’t need to log in separately—I’ve already logged in, so we have shared our authentication.”
Quick FHIR and SMART
FHIR and SMART are not platforms; they’re guidelines on how to implement a certain technology. EHR vendors all implement the standards in different ways. It’s up to the health systems to install, update and configure their systems to incorporate the standards.
The majority of the SMART access is limited to research-based applications. For a SMART app to work, it requires that the app is built on top of an EHR that supports SMART. Access is currently limited to Epic, Cerner and Allscripts sites.
Remember: applications are built on top of a health system’s specifications, and many health systems use multiple EMRs. So when a health system that uses Epic and Cerner; their data center has to install software to support FHIR and SMART on FHIR for both vendors. By the time the apps start building on top, there’s been a lot of opportunity for deviation from the standard.
Many organizations are finding it difficult to implement FHIR and take advantage of its benefits while addressing these deviations and other potential issues. The Prolifics Innovation Center has developed a FHIR solution called Prolifics Quick FHIR to help them build out their own system and get connected quickly and easily.
Quick FHIR handles the concerns about what needs to be done around APIs and data operations, and opportunities around AI/machine learning when you implement FHIR and how you can employ those three things to drive value.
FHIR services hosted in Quick FHIR can be included in a user experience component. But much of SMART on FHIR is about interoperability of UI (user interface) components that can be plugged into an EHR. SMART defines how third-party apps launch within the EHR, how to determine which EHR user is interacting with the app, and what patient’s data is being accessed.
“For any customer looking to implement FHIR, Quick FHIR handles the concerns around APIs, data operations, and the opportunities they have around AI/ML,” Hodgkinson says.