The goal of the original SMART on FHIR API 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 one app should be readily substitutable for another. When apps are substitutable, they compete with each other which drives quality up and price down. SMART supports an “app store for health” model.
A platform with substitutable apps constructed around core services is a promising approach to driving down healthcare technology costs, supporting standards evolution, accommodating differences in care workflow, fostering competition in the market, and accelerating innovation. With the cost of switching kept low, the platform enables a physician using an electronic health record, a chief information officer running a hospital IT infrastructure, or a patient using a personally controlled health record to readily discard an under-performing app and install a better one. Competition on quality, cost, and usability is enabled, and the pace of innovation increases.
Importantly, as demonstrated by the Apple and Android platforms, a well-defined interface for substitutable apps excites and activates hundreds of thousands of software developers.
In practical terms, substitutability is a high bar because it imposes a need for ‘semantic interoperability’ between apps and the health IT systems on which they run. To achieve this interoperability, SMART provides a full stack of open specifications that enable a medical apps platform. These specifications include a highly-normalized set of clinical data models based on FHIR, designed to be intuitive and easy for developers to learn.
A key innovation in the SMART on FHIR platform is the use of a standards-based data layer building on the emerging FHIR API and resource definitions. SMART on FHIR, provides a health app interface based on open standards including HL7’s FHIR, OAuth2, and OpenID Connect. FHIR provides a detailed set of “core” data models, but leaves many fields optional and vocabularies under-constrained, in order to support diverse requirements across varied regions and use cases. But to enable substitutable health apps as well as third-party application services, developers need stronger contracts. To this end, SMART on FHIR applies a set of “profiles” that provide developers with expectations about the vocabularies that will be used to express medications, problems, labs, and other clinical data.
Key features include:
- Developers work directly with concrete data types such as allergy, prescription, or condition, not abstract types such as entity, actor, or role
- SMART specifications are ‘opinionated,’ making up-front choices about how data are represented so that developers know what to expect. For instance, every problem in a SMART record is associated with a SNOMED CT disorder code
- SMART defines a limited set of broadly applicable data types, rather than permitting a proliferation of interface-specific definitions
We take this approach because poorly normalized data require developers and apps to expend tremendous effort just ‘making sense’ of the payloads they receive. For example, consider an app that obtains a list of medications from a container to assess for polypharmacy. If some of the medications are coded with National Drug Codes (NDC), others with RxNorm codes, and still others with codes from a local dictionary, the app must first go through the considerable effort of re-mapping these codes into some common vocabulary, reducing the integrity of the medication list while creating additional work for an app developer.
Today, the SMART on FHIR API is built into major EHR products, has been used by Apple to connect its Health App to hundreds of healthcare systems, and is used for apps launch on the Microsoft Azure product.