What is SMART on FHIR?
May 19, 2017
One of the most common questions we get after, “what is FHIR?” is, “what is SMART?” followed closely by, “What is SMART on FHIR?”
This article aims to clear those questions up.
SMART, which is an acronym for “Substitutable Medical Applications, Reusable Technologies”, was born in 2010 and is run out of the Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics.
SMART started with a $15M grant from the ONC with the purpose of building a standard framework that allows the development of “interchangeable healthcare applications”.
The original goal was to enable any developer to create a healthcare application that would work at any healthcare organization, regardless of EHR. A huge focus was placed on the “substitutable” aspect—SMART wanted it to be very easy for providers to try new applications (ie., substitute) so they could easily try multiple solutions and pick what worked best for them.
The vision was for providers at an individual level to have the power to select and use the applications best suited to their needs without forcing every provider in the healthcare organization to use the same apps:
The goal of SMART is audacious and can be expressed concisely: an innovative app developer can write an app once, and expect that it will run anywhere in the health care system. Further, that app should be readily substitutable for another.”
Kenneth Mandl, MD, MPH Chair, SMART Advisory Committee
Sound familiar? If you’re asking yourself, “wait, isn’t that just like FHIR? Or Redox for that matter?”, the answer to both of those questions is, “in spirit, yes”.
Making an interoperable reality
As it turns out, the need to build solutions that work for providers and patients no matter the software system in place is a big enough problem that a lot of people are working to fix it.
When SMART first started, the objective was to define a data standard that would make this type of “build once, go anywhere” model possible. Before finding too much traction, FHIR, the new health information exchange standard being developed by Health Level Seven International, began gaining support from the healthcare community. FHIR was negotiating and defining the standard so in late 2013 that SMART pivoted to what it is today, which is a standard that works in conjunction with and on top of FHIR. This is why people commonly refer to it as “SMART on FHIR”.
SMART moved away from developing the standard and instead focused on formalizing the process for interacting with FHIR interfaces, outlining how the apps will be “launched” from the EHR, and standardizing the security protocols used by third-parties to exchange data with healthcare organization’s EHR systems.
SMART is also very committed to producing “how-to documentation” designed to help developers get up to speed on what FHIR makes available and how to build alongside SMART for future roll outs to live healthcare settings. They have also collaborated closely with EHR vendors like Cerner to build out sandbox environments where applications can simulate their workflow and even show off their product to prospective customers in the SMART Gallery.
Understanding SMART
One of the best examples to help understand SMART is to think about authorizing apps via Facebook works. In this scenario, Facebook is the EHR: it stores all the personal information about the patient/person. The data format and standard which Facebook uses to store this data is the equivalent of FHIR. When people use Facebook, rather than creating a new login for every new application they want to authorize, they can grant the app access to specific pieces of information (FHIR resources) stored on Facebook (EHR). The mechanism that handles approving this authorization – the thing that outlines what this needs to happen pre and post clicking accept – in the healthcare world will be SMART.
To break it down in healthcare terms:
FHIR defines the structure of where data should live and how it should look.
The EHRs are responsible for filling that structure with actual patient data.
SMART defines how third-party apps launch within an EHR, how to determine which EHR user is interacting with the app, and what patient’s data is being accessed.
What is it like to implement a SMART on FHIR app?
The process of implementation happens in the following steps:
The specification is developed.
EHR vendors implement the standards and specifications, albeit differently.
The health systems - the customer of EHR vendors - install, update, and configure their systems to incorporate the standards.
Applications are built on top of the health system’s specifications.
While seemingly simple, it’s important to note why this process makes the final step exceptionally difficult.
HL7 creates the specification. FHIR and SMART are not platforms; they’re guidelines on how to implement a certain technology. After designing the standard, it’s in the hands of the EHR vendors to implement, and they all implement somewhat differently.
Once the vendor implements, we’re onto step three—the health systems have to install, update, and configure their systems to incorporate the standards. Many health systems use multiple EMRs. Take, for example, a health system which uses both Epic and Cerner; their data center has to install software to support FHIR and SMART on FHIR for both vendors. During installation, the health system can decide which pieces of FHIR they want to implement, and more importantly, which pieces they do not want.
The final step is apps building on top. By the time the apps start building, there’s been a lot of opportunity for deviation from the standard. An example where one can see this deviation is code sets for medications. When using the FHIR medication resource, Epic sites implement with the RXNorm standard; however, a Cerner implementation would use an internal Cerner ID. Moreover, it’s highly likely that two Cerner sites wouldn’t even be compatible with each other.
While it’s possible to implement an app using FHIR and SMART, there are still a lot of variations that need to be taken into consideration.
How is SMART different from Redox?
Both Redox and SMART authorize apps to achieve EHR integration, but it’s done slightly differently. The way Redox operates, the authorization layer happens at the system level through interactions with the businesses involved. Redox completes the setup process and verifies who is authorized to receive data. For example, if Redox has a set of subscriptions set up which say application X is allowed to get scheduling info from UPMC, they will not receive scheduling info from any other health systems unless authorized through our system. In an ideal state, SMART would happen at the user level (patient or provider), but right now it's also at the system level.
Our subscriptions are effectively what’s happening in SMART on FHIR. Because there’s a platform behind Redox’s authorization, it’s more scalable than the way SMART is implemented. Here are a few other key differences:
For more information on SMART, check out their website or read this great blog post from David Hay titled “What is SMART and why should you care.”