Balancing Functionality versus Portability for SMART on FHIR Applications: Case Study for a Neonatal Bilirubin Management Application

Abstract

SMART on FHIR applications are standards-based tools integrated with electronic health record (EHR) systems and intended for dissemination across EHR platforms. A key challenge for disseminating many apps is that EHR vendors provide different levels of support for FHIR. Thus, app developers must balance functionality versus portability. In this case study, a feature-rich app for neonatal bilirubin management was developed prioritizing physician-requested functionality, with custom FHIR interfaces implemented within the EHR as needed. Following wide intra-institutional use, several approaches are being pursued for adapting the app for cross-institutional dissemination: user surveys and interviews to identify least-valued app features which could potentially be omitted; enabling the application to provide differential features depending on available EHR FHIR capabilities; replacing custom FHIR interfaces with native EHR FHIR interfaces as they became available; and using a canonical logical data model known as QUICK that can be mapped to different FHIR versions and profiles.

Introduction

SMART on FHIR applications

The Health Level Seven International (HL7) Fast Healthcare Interoperability Resources (FHIR)¹ data interface standard is used by the Substitutable Medical Applications and Reusable Technologies (SMART) platform launched in 2010 for clinical app integration into electronic health record (EHR) systems.² SMART on FHIR applications retrieve relevant data through application programming interfaces (APIs) and are integrated with EHR authorization mechanisms so that they can be embedded within EHR systems with single sign-on capabilities.³ Apps can be authored by third parties or by internal app development groups. One of the main promises of SMART on FHIR is its potential for “plug-and-play” interoperability, which could allow an organization to import an app developed elsewhere and utilize it with ease.⁴ Consequently, it has been proposed that SMART on FHIR applications could enable advanced functionality to be cost-effectively disseminated, even to health systems with limited information technology resources.⁵ Every year, more and more SMART on FHIR applications are being developed: the SMART on FHIR app gallery contains 69 SMART on FHIR applications as of March 2019.⁶ Duke Health shared their SMART on FHIR platform information and demonstrated feasibility of deploying 5 apps.⁷ However, the healthcare community is still early in its adoption, implementation, and evaluation of SMART on FHIR applications. Clinical outcomes have not been evaluated yet for most apps and many published reports have focused only on implementation feasibility.^8,9 Only a few apps have been reported to be used by multiple healthcare systems successfully.¹⁰

Key challenge to dissemination: limitations in EHR-supported FHIR capabilities

Dissemination is the process of spreading an application from the organization where it was developed to multiple EHRs. We define portability in this context as how easily an application can be disseminated. EHRs are generally compliant with the US Core FHIR profiles,¹¹ which define a minimum set of data interfaces using the FHIR standard. However, these FHIR profiles have limitations. For example, the official version of these profiles as of March 2019 (version 1.0.1) does not include support for the FHIR Encounter and ServiceRequest resources, retrieval of clinical notes, or filtering a search for past medications based on a date. Even in the most current draft version of these profiles (version 2.1.0)¹², there is no support provided for writing data into the EHR, placing orders, or retrieving relevant clinical data such as family health history, baby’s birth time, or detailed information on a patient’s smoking history (e.g., packs per day). Moreover, even when included in the US Core FHIR profiles, terminologies may not be standardized in the profiles (e.g., medication routes are not required to use a standard terminology), and EHRs may differ in their interpretation and implementations of the profiles. Differences may also exist at the level of healthcare systems using the same EHR platform, providing further challenges to dissemination. Thus, to maximize the potential for dissemination, SMART on FHIR applications must constrain their data requirements to those supported by US Core FHIR profiles, and in particular to those profiles that are most uniformly implemented by EHR vendors. While such an approach may not be an issue in some cases (e.g., when developing an application for demonstration or proof-of-concept purposes, or if a use case can be fully satisfied using available data interfaces), in many cases the desired user functionality may not be supportable using existing EHR FHIR interfaces. This situation is expected to improve in future years as the US Core FHIR profiles continue to evolve, and as EHR vendors continue to increase their FHIR capabilities. However, for the foreseeable future, the need to balance portability with functionality will be a real concern for SMART on FHIR app developers.

At the University of Utah, a number of SMART on FHIR applications have been developed and implemented for operational clinical use since 2017. The first of these applications to be deployed for production clinical use was a neonatal bilirubin application. This application is in near-universal clinical use in the newborn nursery, and it is being prepared for external dissemination. Here, we use this neonatal bilirubin application as a case study for examining potential approaches to balancing functionality versus portability of SMART on FHIR applications which can often pose competing demands. The objective of this paper is to assist others developing SMART on FHIR applications to make more informed decisions on how to best achieve the right balance between functionality and portability.

Methods

Implementation Setting

Development of SMART on FHIR applications was performed by the Knowledge Management and Mobilization (KMM) group at University of Utah Health, an academic health system, as part of the ReImagine EHR initiative.¹³ University of Utah Health uses the Epic EHR. The KMM team consists of 9 clinical informaticists with expertise in areas including software development, software architecture, standards-based interoperability, and biostatistics. Two of the team members are physicians, 4 are PhDs, 2 are co-chairs of HL7 Work Groups, and 7 are certified to make custom Epic Web Services in the Epic EHR. Team members meet regularly with EHR vendor colleagues to help ensure that any custom interfaces developed are aligned with the vendor’s approach to FHIR. Team members gained expertise in making FHIR extensions to the EHR through the development and implementation of a number of SMART on FHIR apps for clinical use at University of Utah Health, engagement in the standards development process, and technical validations of cross-institutional app deployments in different EHR platforms through inter-institutional collaborations as well as HL7 FHIR Connect-a-thons. The Department of Biomedical Informatics at the University of Utah also has a sociotechnical team which provides evaluation services.

Preparing for Cross-institutional Dissemination

We considered the following approaches for adapting the app for cross-institutional dissemination: (1) initial implementation based on clinician needs, with custom FHIR services implemented as needed, (2) gathering feedback from app users to identify least-valued app features which could potentially be omitted if difficult to disseminate, (3) enabling differential features based on EHR FHIR capabilities, (4) progressive replacement of custom FHIR services with native EHR FHIR APIs, and (5) use of a canonical logical data model known as QUICK that can be mapped to different FHIR versions and profiles.

Initial Implementation Based on Clinician Needs

In 2016, a SMART on FHIR app for neonatal bilirubin management, which we call the Bili App, was requested by pediatric physicians. The KMM team evaluated whether it would be possible to simply use the SMART on FHIR bilirubin app available in the SMART on FHIR gallery as a demonstration application.¹⁴ However, the physicians determined that the original app would not meet their clinical needs and would not be useful to them, due to inadequate support for key recommendations in the underlying clinical guideline from the American Academy of Pediatrics.¹⁵ While the demonstration application required only limited data, such as laboratory data conformant with US Core FHIR profiles, it did not provide sufficient perceived utility for the end users. Thus, the KMM team decided to enhance the app to support the requested functionality. These enhancements impacted portability of the application by requiring data APIs that are not currently supported by US Core FHIR profiles.

Following significant enhancements by University of Utah Health, the Bili App was released for clinical use on April 12, 2017. The app uses FHIR version STU3 (3.0.1), US Core FHIR profiles version 1.0.1 and QI-Core FHIR profiles version 2.1.0.¹⁶ The app was recognized with several awards in the Department of Health and Human Services’ Provider User Experience Challenge.¹⁷ The app is in near-universal use for babies born in the University of Utah newborn nursery.

Gathering Feedback from App Users

As some of the features were known to be potentially difficult to disseminate on other EHR platforms due to the lack of needed FHIR interfaces in these platforms, we gathered user feedback to determine the most valuable features. Gathering feedback from the users included interviews and surveys conducted by the KMM team’s Director of Evaluation (PK) and a member of the Department of Biomedical Informatics’ Sociotechnical Service Line (HK). We asked medical directors of the newborn nursery and outpatient clinics to invite attending and resident physicians to participate in in-person sessions that included a survey and a semi-structured interview. Three residents and 4 attending physicians agreed to participate, representing both inpatient and outpatient settings. Usability assessment was approved by the Institutional Review Board (IRB).

During the in-person sessions, we showed participants a de-identified screenshot of the Bili App (Figure 1) with 16 screen components: 1) patient bilirubin test results, 2) phototherapy thresholds (green lines), 3) exchange transfusion thresholds (red lines), 4) phototherapy administration (yellow bar), 5) discharge from the hospital (light blue bar), 6) outpatient phototherapy order (orange bar), 7) gestational age, 8) direct Coombs results, 9) mother’s lab results, 10) other neurotoxicity risk factors, 11) albumin > 3.0 g/dL, 12) recommendations (blue box), 13) rebound hyperbilirubinemia risk (green box), 14) table of bilirubin measurements, 15) table of albumin measurements, and 16) hyperbilirubinemia risk tab. First, we asked users to assess the value of all 16 features. Second, we asked whether the providers would still use the app if it no longer included any one of 8 features deemed to be most difficult to disseminate. Responses were arranged according to the median value and visualized using box-plots. Interview times averaged 20 minutes and included screen recordings of clinicians using the app for the assessment of bilirubin levels for providers’ recent actual patients. The semi-structured interviews included the following questions: What decisions are supported by the app? What works well in the Bili App? What are issues and/or limitations? Can you think of any enhancements that would help you?

Figure 1.

Screenshot of Neonatal Bilirubin Application for a Synthetic Patient

Enabling Differential Features Based on EHR FHIR capabilities

In the course of other projects that involved integration of FHIR applications across institutions and EHR vendor platforms, the project team came to realize that other EHR vendors may simply not enable third parties to add extensions to their FHIR interfaces. Moreover, through the review of EHR vendors’ FHIR documentation, as well as actual interaction with them through HL7 FHIR Connect-a-thons, it became quickly apparent that EHR vendors differ in their support for FHIR versions and profiles. Thus, we explored potential options for supporting different levels of data availability.

Progressive Replacement of Custom FHIR Services with Native EHR FHIR APIs

During the course of the project, the EHR vendor incrementally added additional FHIR interfaces. Several of these interfaces were capable of replacing the data pulled by custom FHIR services. Also, in discussions with the EHR vendor, it was learned that some of the data points which had been pulled through custom FHIR services could be pulled instead through vendor-provided FHIR APIs following data mapping that could be configured in the EHR.

Use of a Canonical Logical Data Model

In an effort to extend the expressivity of the US Core FHIR profiles to support clinical quality improvement efforts, the HL7 Clinical Decision Support (CDS) and Clinical Quality Information (CQI) working groups developed QI- Core FHIR profiles.¹⁶ We used a view over the FHIR QI-Core profiles that hides FHIR-specific implementation details, notably FHIR extensions (e.g., birthtime). However, QI-Core profiles cannot shield implementers from other implementation challenges (e.g., FHIR cross-resource inconsistencies) because the QI-Core logical view is a one-to- one view directly based off of a specific version of FHIR. Moreover, because of the evolving nature of FHIR, as well as differences in how FHIR is implemented in EHRs, coupling a SMART on FHIR application with a specific FHIR version or implementation could be costly and potentially not scalable. Just during the course of this project, multiple versions of FHIR were released, with sometimes substantial changes occurring between releases. Use of a more consistent and FHIR-version-independent logical model could mitigate some of these challenges.

Results

Overview of Approaches Taken to Manage Functionality Versus Portability

We applied the following approaches for adapting the app for cross-institutional dissemination with the goal of balancing the functionality of the Bili App with its portability. We aimed to adequately meet the needs of clinician users while also maximizing the Bili App potential reach and impact. As described in detail below, the approaches involve (1) initial implementation based on meeting clinician needs, with custom FHIR APIs implemented as needed, (2) gathering feedback from current users through surveys and interviews about their valuation of specific app features, (3) enabling the application to provide differential features depending on available EHR FHIR capabilities, (4) progressive replacement of custom interfaces with native EHR FHIR interfaces as they became available, and (5) using a canonical logical data model that can be mapped to different FHIR versions and profiles.

Initial Implementation Based on Clinician Needs

We started by developing a fully-featured app based on user needs. To support this application, several custom FHIR APIs were developed to obtain required information not supported by the native EHR FHIR interfaces at the time, including for the patient’s gestational age, the mother’s laboratory data, the patient’s discharge time, and the timing of outpatient phototherapy orders. We developed these required FHIR APIs, leveraging and “wrapping” non- FHIR APIs natively supported by the EHR where possible. These custom FHIR APIs were made available to the Bili App alongside the native EHR FHIR APIs through an intermediate proxy.

Following initial deployment, additional improvements were made based on user feedback. Figure 1 shows the current version of the Bili App for a test patient. Numbers have been added to the screenshot corresponding to the key user interface components enumerated in the Methods.

The Bili App currently requires 15 data elements which are retrieved from the EHR as FHIR resources through native and custom APIs. Data elements and associated dissemination concerns are summarized in Table 1. In other health systems, different coding terminologies might be used to record the same data elements, or some elements might be unavailable.

Table 1.

Bili App Data Elements and Dissemination Concerns

Data Element	FHIR Resource	Example of Query Parameters	API	Dissemination Concerns
Birth time	Patient	Patient/[id]	Native, custom	An Epic non-FHIR API is used to get the birth time and add it as an extension to the native FHIR resource
Hospitalization	Encounter	Encounter?type=http://snomed.info/sct|32485007	Native	Was not available in Epic 2017; now available
Albumin test	Observation	Observation?code= http://loinc.org|1751-7	Native	Mapping may be required*
Blood type	Observation	Observation?code= http://loinc.org|19057-9	Native	Mapping may be required*
Direct bilirubin test	Observation	Observation?code= http://loinc.org|1968-7	Native	Mapping may be required*
Direct Coombs test	Observation	Observation?code= http://loinc.org|51006-5	Native	Mapping may be required*
Gestational age	Observation	Observation?code= http://loinc.org|18185-9	Custom	Was not available in Epic 2017
Indirect Coombs test	Observation	Observation?code= http://loinc.org|893-8	Native	Mapping may be required*
Total bilirubin test	Observation	Observation?code= http://loinc.org|1975-2	Native	Mapping may be required*
Transcutaneous bilirubin test	Observation	Observation?code= http://loinc.org|58941-6	Native	Mapping may be required*
Inpatient phototherapy procedure	Procedure	Procedure?code=http://snomed.info/sct|31394004	Custom	Initially used custom FHIR service; can be replaced with native EHR Observation interface through LOINC mapping
Outpatient phototherapy procedure request	Procedure Request	ProcedureRequest?code= http://snomed.info/sct|31394004	Custom	Requires custom FHIR service
Natural mother	Related Person	RelatedPerson?code=http://snomed.info/sct|65656005	Custom	Requires custom FHIR service
Mother’s blood type	Observation (Mother)	Observation?code= http://loinc.org|882-1	Custom	Requires custom FHIR service
Mother’s indirect Coombs test	Observation (Mother)	Observation?code= http://loinc.org|893-8	Custom	Requires custom FHIR service

^*Mapping of local codes to LOINC may be required in EHR configuration

Gathering Feedback from App Users

User assessment of the value of app features is summarized in Figure 2. The numbers in the figure correspond to the feature labels included in the screenshot in Figure 1. Surveying for valuable features clearly showed that some features are perceived as more important than others. Two features were perceived as highly important by all participants: bilirubin results and phototherapy thresholds. Most of the users stated that they would still use the app if any one of the 8 difficult-to-disseminate features was omitted. We found that the hyperbilirubinemia risk tab and table of albumin measurements had medium to low value for most users. Auto-population of gestational age was valued highly by most users.

Figure 2.

Participant Survey Responses

Interviews allowed us to get a deeper understanding of why users found some features less valuable than others. For example, users noted:

“I don’t use this tab at all <pointed to Hyperbilirubinemia Risk tab>. I know other people do on the inpatient side, but I’m not very familiar with it and haven’t used it to change my decision one way or another. Kind of redundant with this <main tab>…”

“We hardly ever draw albumin on babies. I feel like maybe for premies we might be looking at that, but we hardly ever have it on record.”

In the interviews, providers tended to report what should be added, not what could be omitted. This is consistent with the psychological literature that users do not like to give away what they already have.¹⁸ Many users asked to add the rate of rise. For example, one user noted the following:

“It would be wonderful if it could automatically calculate rate of rise (the calculation is not hard or time consuming, but an automated value would be helpful for busy clinic days).”

Enabling Differential Features Based on EHR FHIR Capabilities

We are refining the system to be able to adapt to differing levels of data availability (Figure 3). For example, when a mother’s laboratory data cannot be automatically pulled through the FHIR interface, instead of leaving those data elements blank in the app, the app could be configured to not include a placeholder for those data elements in the first place. To an extent, the application is already configured to account for differences in FHIR data availability. For example, for patients who are not born at our healthcare system but are instead transferred in or simply followed up in the outpatient setting, the app prompts the user to enter the missing patient birthtime rather than pulling it from the EHR. We are planning to extend this type of differential functionality based on known and anticipated differences in FHIR capabilities across EHR systems. As an extreme case, we are also considering developing a stand-alone version of the app that can function without the provision of any EHR-provided data.

Figure 3.

Enabling Differential Features Based on EHR FHIR Capabilities

Progressive Replacement of Custom FHIR APIs with Native EHR FHIR APIs

During the course of the project, several FHIR APIs were introduced by the EHR vendor, which allowed for replacement of custom FHIR APIs. Data that could now be supported natively through use of the EHR vendor’s FHIR API include the patient’s gestational age and the date and time of the patient’s discharge from the hospital. In addition, we learned that inpatient phototherapy administration times could be pulled through a native EHR FHIR Observation API following configuration in the EHR to map nursing flowsheet data to LOINC. Thus, whereas a custom FHIR Procedure API was originally used to identify when phototherapy was administered in the inpatient setting, this information can now be retrieved using the native EHR FHIR interface for Observations.

Use of a Canonical Logical Data Model

To mitigate dissemination challenges associated with FHIR versioning, we propose using a canonical logical data model which allows the core SMART on FHIR application to be written against one data model rather than many data models, thus decoupling application logic from the FHIR versions used in messages. Currently, one of the authors (CN), who is a co-chair of the HL7 Clinical Information Modeling Initiative (CIMI) Work Group, is developing such a logical data model known as the HL7 Quality Improvement and Clinical Knowledge (QUICK) logical model. The QUICK logical model is based on multiple standards and models including HL7 FHIR,¹ HL7 Virtual Medical Record (vMR),¹⁹ the National Quality Forum Quality Data Model (QDM)²⁰, HL7 US Core FHIR profiles,¹² and HL7 QI-Core FHIR profiles.¹⁶ The scope of the QUICK logical model consists of classes and attributes currently identified as needed for CDS and quality measurement. The QUICK logical model is under development at HL7 and is expected to be balloted as part of the HL7 January 2020 submission cycle.

Discussion

Summary of Findings

While SMART on FHIR provides a promising potential approach for widely disseminating innovative extensions to the EHR, the still evolving nature of EHR vendors’ support for FHIR poses challenges to such widespread dissemination. Specifically, in cases where needed FHIR APIs are not broadly supported across EHR vendors, a SMART on FHIR app developer must consider tradeoffs between functionality and ease of dissemination. In this manuscript, a neonatal bilirubin management SMART on FHIR application was used as a case study of how this tradeoff can be appropriately managed. The approach taken involved the following methods. First, we started by ensuring that user requirements are met in an initial implementation for production clinical use, with custom FHIR service being developed in coordination with the EHR vendor where needed. Second, surveys and interviews were conducted with users of this fully-featured application, with a goal of identifying those features that provide the least perceived value to end users, as those features could potentially be omitted when externally disseminating the tool if they require FHIR interfaces that may not be generally available. Third, we are enhancing the application so that its feature set can adapt to differing levels of data availability. Fourth, custom FHIR APIs were replaced with EHR vendor-provided interfaces as those interfaces became available, so that the need for developing or sharing custom FHIR APIs is reduced. Finally, we are moving towards the use of a canonical logical data model, so that the core logic can remain unchanged while enabling interaction with different FHIR versions as well as profiles supported by EHR vendors. While we have not yet empirically validated that these approaches will enable functionality to be optimized while still supporting widespread dissemination, we believe that these complementary approaches will enable us to achieve these goals moving forward.

Strengths and Limitations

One important strength of this study is that we used several complementary approaches spanning qualitative methods (interviews and surveys) as well as deeply technical approaches (e.g., developing custom FHIR APIs directly into EHRs and using a canonical logical data model). Thus, we were able to expand the potential approaches available to us. For example, if we had not possessed the capability of building custom FHIR APIs directly into the EHR for production clinical use, it is uncertain whether we could have developed a SMART on FHIR application for neonatal bilirubin management that would have adequately met the needs of our clinicians. Indeed, we had started by proposing clinical use of the SMART on FHIR demonstration application for this use case that had been available for some time on the SMART on FHIR app gallery.¹⁴ Despite the fact that this application had been successfully demonstrated across multiple EHR platforms, our clinicians felt that introducing this application into our clinical environment would provide little value without the enhancements we ultimately implemented. As a second strength, this study was conducted by a project team that included national experts on FHIR and its evolution in the standards community (KK and CN). One of the authors (KK) also serves on the Board of Directors of HL7 (the standards development organization that specifies FHIR) and the U.S. Health IT Advisory Committee. As such, the project team is well- positioned to understand the current state and future direction of the FHIR standard and its adoption by the health IT community and is actively contributing to its evolution through our implementation experience. As a final strength, our approach can be applied to a wide range of clinical use cases, as it allows new FHIR interfaces to be developed and used where needed. This approach does not rely solely on FHIR capabilities that are universally supported across EHR vendors, as our experience has indicated that many actual clinical needs cannot currently be adequately met using just these FHIR interfaces.

An important limitation of the study is that we are still in the process of disseminating the SMART on FHIR Bili App. Thus, we do not yet have empirical evidence that the approach used will be successful in balancing functionality with portability. A second limitation is that this approach involves making enhancements to the FHIR interfaces natively provided by the EHR vendor. Such enhancements could become a barrier to dissemination due to the cost of development and integration. For organizations that do not possess this capability, or whose EHR vendors do not permit such extensions, the only option remaining would be to advocate for the needed capabilities to be implemented by the EHR vendor. Finally, a third limitation of this study is that it is technically more complex to implement than an approach focused on using only those FHIR capabilities natively provided across EHR vendors. While this may be functionally adequate in some use cases, in other cases this would significantly hamper the functionality that can be achieved and the degree to which duplicate manual data entry can be avoided.

Lessons Learned and Recommendations

Through this study, several insights were gained on the process of balancing functionality and portability. First, while improving, existing FHIR capabilities provided by EHR providers are often inadequate for meeting the needs of clinical users. Second, the degree to which EHR vendors support and empower their clients to enhance FHIR interfaces is variable. Third, while most EHR vendors provide support for US Core FHIR profiles, these profiles still provide optionality for EHR vendor implementation, leading to vendor differences in implementation. Fourth, mapping of local codes to standard codes is still oftentimes required. Finally, while promising, enabling widespread dissemination of functionally rich SMART on FHIR applications can still present significant challenges.

Based on our study findings and lessons learned, we recommend that stakeholders in the healthcare community cooperate in identifying their most important needs with regard to FHIR and advocate for their universal support in the US Core FHIR profiles and EHR vendor implementations of those profiles. There is substantial ongoing work in this area, for example by the U.S. Core Data for Interoperability and Interoperability Standards Priorities Task Forces of the U.S. Health IT Advisory Committee.²¹ Moreover, given the limitations of US Core FHIR Profiles in addressing end user requirements, we (CN and KK) are currently proposing FHIR Implementation Guides that extend beyond US Core FHIR Profiles for adoption by the Healthcare Services Platform Consortium (HSPC), Clinical Information Interoperability Council (CIIC) and HL7 as part of the ReImagine EHR initiative.22,23 Interested stakeholders are encouraged to engage in these forums, as well as directly through HL7 and other venues to advocate for their priorities. Second, we recommend that SMART on FHIR app developers explicitly consider the tradeoffs between functionality and portability, as well as to use one or more of the approaches described in this study for managing those tradeoffs. Finally, we recommend that end-users be engaged throughout the process to ensure that the approach taken adequately meets their clinical and workflow needs.

Future Directions

In the future, approaches to measuring the cost and utility of providing desired features that extend beyond US Core FHIR profiles should be explored. Such measurement could allow formal evaluation of the extent to which the benefits of adding such features outweigh the costs. Expanding such cost-benefit analysis on the national level could help identify priorities for the development and implementation of standards including the US Core FHIR profiles.

Moving forward, we are continuing to develop new FHIR capabilities in the EHR, including SMART on FHIR applications and CDS Hooks decision support services. Other applications that we have developed or are currently developing for clinical use include a population health management system for individuals at risk of early onset familial cancers, a surgical referral dashboard, a procedure capacity management application, a lung cancer screening shared decision making app, a diabetes treatment outcome prediction app developed in collaboration with Hitachi, opioid-related decision support tools developed with CDC and ONC support, and EHR-integrated medical calculators developed in collaboration with MDCalc. We believe in the potential for SMART on FHIR applications to improve patient care and reduce physician burnout. As one physician noted when interviewed regarding the Bili App:

“We need to be thinking way beyond the bilirubin app. The sky is the limit.”

Conclusion

As leaders in SMART on FHIR application development, we share here our journey in preparing one of our first SMART on FHIR applications intended for wide dissemination. We demonstrated the feasibility of satisfying user requirements through developing custom FHIR APIs not supported natively by our EHR. Unfortunately, this approach would require a significant investment of resources on the part of adopting organizations and thus poses a barrier to dissemination and adoption of the application. To address this challenge, we recommend that such FHIR services be considered as a starting point for the development of future FHIR implementation guides that extend or build upon the US Core FHIR profiles. The implementation of such standards-based APIs by EHRs would reduce the barriers to dissemination. Until such a time, a holistic approach that combines both technical and user-centered qualitative methods is recommended for optimizing functionality versus portability for SMART on FHIR applications.