This is the third in a series of articles on the dramatic transformation taking place in health informatics in large part because of the new Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) standard. The first article provided the background on healthcare, electronic health record systems for physicians, and the challenges they both face along with the potential of interoperability to help overcome them. The second introduced the basics of the FHIR standard and some suggested resources for those who are interested in its further exploration. In this article, we explore SMART on FHIR which has become the default standard FHIR app platform based on its wide adoption. The articles in this series are intended to introduce researchers from other fields to this one and assume no prior knowledge of healthcare or health informatics. They are abstracted from the author’s book Health Informatics on FHIR: How HL7’s New API is Transforming Healthcare (Springer International Publishing).
A universal health app platform to support informatics-based innovations in care delivery, no matter what the underlying EMR, was a long-held goal of the academic health informatics community. In 2010, the federal government awarded U.S. $15 million to the Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics to create and initially develop just such an app platform.
The result was SMART, an acronym for “Substitutable Medical Apps, Reusable Technology,” that was intended to be an open, standards-based technology with a robust community of app developers. The SMART effort developed an API that leveraged web standards and widely adopted health data standards to present “predictable data payloads,” thus obviating the need for apps to deal with the details of the underlying health information system’s data structures and representations. As Health Level 7’s (HL7’s) Fast Healthcare Interoperability Resources (FHIR) effort gained momentum, the SMART project shifted its strategy to the development of a technology layer that builds on the FHIR API and resource definitions. The project team uses SMART to refer to their overall effort and SMART on FHIR apps are now widely adopted by many major EHR vendors, Medicare, the Veteran’s Administration, Apple, and others.
SMART on FHIR technology stack
As we discussed in the second article (published in the November/December 2018 issue of IEEE Pulse), many FHIR fields and value sets may not be constrained to support specific requirements across varied regions and use cases. To enable substitutable health apps as well as third-party application services, SMART on FHIR applies a set of “profiles” that provide developers with expectations about the vocabularies they should use to represent medications, problems, labs, and other clinical data.
In the United States, SMART on FHIR has adopted the profiles outlined in the Argonaut Implementation Guide. The guide was developed by a broad industry coalition to define a standard way EHRs could use FHIR to meet a set of federal requirements for reporting by their clients under the Meaningful Use program. A FHIR implementation guide is a set of rules about how FHIR resources are used (or should be used) to solve a particular problem, with associated documentation to support and clarify the usage. This approach takes advantage of the broad adoption of Argonaut by the EHR vendor community. Also, as part of the Argonaut Project, the five largest EHR vendors either have or will build SMART on FHIR into current or future releases of their products. The vendors, the SMART on FHIR team, and HL7, are working together to standardize the SMART on FHIR API in HL7 specifications.
Clearly, third-party apps must not access protected health information without first establishing trust in who is using those apps, their right to access the requested data, and respecting patient privacy choices for data sharing. To facilitate this, SMART on FHIR provides login and data access authorization models based on the OpenID Connect and OAuth2 standards that are widely used on the Internet and elsewhere.
Through the SMART on FHIR Genomics and SMART CDS Hooks efforts, the SMART on FHIR project is helping define the next generation of FHIR-based standards for the clinical use of genomic data and the integration of clinical decision support into provider workflows.
Developer support
To support running apps within the EHR’s user interface, SMART on FHIR allows web apps to run inside browser widgets or inline frames. It also supports native and mobile apps. In addition, to make it easier for developers to get started building apps, the SMART on FHIR project offers a set of open source libraries for HTML5/JavaScript, Apple’s iOS, and Python.
Figure 1 shows the free, web-based SMART on FHIR “sandbox” developers use to test their apps. They have the option of doing this locally using an installable version. It includes an extensive set of vital signs data for use in testing. Developers can also create patient and practitioner “personas” and use them in “Launch Scenarios” to test their app. A Launch Scenario is a particular clinical situation in which an app is initiated. It automatically provides the data the app needs to fulfill its purpose and to minimize (or eliminate) data entry by the user (http://www.hl7.org/fhir/smart-app-launch/).
Projects often have specific data requirements so SMART also offers FRED, an open web-based, interactive FHIR resource editor to help developers create sample data for their apps. FRED is easy to use so you may wish to use it to build a FHIR Resource of your choice. Figure 2 illustrates this using a FHIR patient resource that can then be exported in FHIR JSON format. FRED code and more information about the tool are available on GitHub (https://github.com/smart-on-fhir/fred).
SMART’s C3-PRO is a software library that integrates the SMART on FHIR platform with ResearchKit, Apple’s open-source framework to enable iOS apps to become tools for medical research. Finally, the SMART site offers extensive documentation.
Integration into EHRs
In the first article of this series (published in the September/October 2018 issue of IEEE Pulse), we said that “Historically CDS tools were not widely used because they have been stand-alone operating outside of the EHR environment, thus requiring duplicate entry of data already recorded in the EHR and were not well integrated into the physician’s workflow and clinical processes.” When SMART on FHIR is properly integrated into an EHR, these problems are largely overcome. Figure 3 shows the RIMIDI SMART on FHIR app platform for chronic disease management running within Cerner’s PowerChart EHR. As you can see at the lower left, the app is accessed from an entry in the same menu physicians use to do other charting. It appears in the same area that Cerner uses for other data entry and visualization. For all practical purposes, it appears to the physician to be part of their EHR, even though it is actually a web app running on separate servers. When it is launched, launch parameters autopopulate the app with the relevant data since they know the clinician, the patient, and the context in which the app is being used.
Despite everything we have discussed, there is still the potential problem of a physician remembering that there is an app that could be beneficial in the care of a particular patient. The new CDS Hooks component of SMART is designed to allow “clinical logic” to be embedded in the EHR such that the physician is notified, based on the data about their patient, of information that should be of particular interest, given their current charting task. This might be opening a chart, prescribing medication, or signing an order for a test or procedure. The notification might be information—such as how much could be saved if a generic medication was substituted for the brand name drug being prescribed—or it might be a reminder that a SMART on FHIR app is available that could help select the appropriate medication where that choice is complex. The latter reminder would normally include a button that can be used to launch the app, if desired.
SMART on FHIR app galleries
With many commercial and noncommercial organizations now developing SMART on FHIR apps, the SMART on FHIR app gallery is a great place to visit to get a feel for what is being done with FHIR. Some commercial EHR vendors (including Cerner and Epic, the two largest) have opened their own app galleries that offer SMART on FHIR apps that have gone through a certification process developed by that vendor. In the second article of this series, we discussed SMART on FHIR app platforms being offered by the U.S. Medicare program’s Blue Button 2 and the U.S. Veteran’s Administration’s Lighthouse API. We also mentioned that Apple Healthcare is using FHIR and supporting SMART on FHIR apps. In the final three articles, we will take a closer look at how FHIR apps are being used to solve real-world problems in healthcare delivery.
Web Resources
- “SMART FRED resource editor,” 2018. [Online].
- “SMART app gallery,” 2018. [Online].
- “CDS hooks sandbox,” 2018. [Online].
- “Cerner’s FHIR app gallery,” 2018. [Online].
- “Epic’s FHIR app gallery,” 2018. [Online].
- “Medicare’s blue button 2,” 2018. [Online].
- “VA’s lighthouse API,” 2018. [Online].
- “Apple healthcare,” 2018. [Online].