API EHR Integrations Grow, But FHIR Data Exchange Adoption Trails

While the number of application programming interfaces (API) EHR integrations increased from 2019 to 2020, the proportion of APIs that support the FHIR data exchange standard remained relatively the same, according to a study published in JAMIA.

Researchers gathered data from the public app galleries hosted by five of the leading EHR vendors: Allscripts, athenahealth, Cerner Corporation, Epic Systems Corporation, and SMART.

Cerner, Epic, and SMART had a net increase in the total number of apps in their galleries, while athenahealth and Allscripts had a net decrease in apps. The Epic App Orchard saw the largest net increase of 43 percent, adding 169 apps during the study period.

While support for FHIR increased from 19 percent of APIs at the end of 2019 to 22 percent of APIs at the end of 2020, the increase was not statistically significant.

The researchers suggested that the modest growth in FHIR APIs could be because some apps are less likely to use or describe support for the data exchange standard.

For instance, administrative apps for appointment scheduling, patient check-in, or bill pay, were the most common types of apps marketed in 2020. The researchers found that less than 10 percent of these apps described support for FHIR. APIs designed for clinical use or care management supported FHIR at higher rates.

Additionally, FHIR resources only facilitate the exchange of certain data elements, which may have contributed to the variation in FHIR support, the authors noted.

“This is especially true for earlier versions of the FHIR standard,” the authors wrote. “As the number of FHIR resources and supported data elements increases and EHR developers’ support for these FHIR resources grows, so too may the use cases supported by these apps.”

What’s more, the researchers found that applications listed across multiple galleries were more likely to support FHIR. The proportion of apps supporting FHIR was two times greater among APIs that were listed in three or more galleries (46 percent) compared to apps found in one gallery (20 percent) which could suggest that FHIR-based apps can more easily connect to multiple EHR systems compared to proprietary APIs.

“If API standardization makes integrations easier, there will be more interoperable data exchanged and more end users will be able to connect to their data,” the study authors wrote.

However, the authors noted several limitations with their data source that may have underestimated the proportion of FHIR APIs.

First, the apps discoverable in each of the EHR vendors’ galleries may not be representative of all API EHR integrations. Patient-facing applications may be more widely marketed in smartphone app stores. Additionally, personalized API solutions may not be listed in EHR vendor galleries as they only apply to a single healthcare organization.

The number of applications in EHR developer galleries may also reflect unmeasured differences in integration policies, the authors noted. For example, some developers may charge fees to app developers for placement in their gallery. EHR developers may also require that all apps be validated prior to being listed in a public gallery, the study authors added.

Research conducted by the authors in parallel to this study found that while some apps do not specifically describe support for FHIR in their marketing materials, they use FHIR APIs to connect their app to some EHR data systems.

The study authors noted that they may have underestimated the total number of apps that that support FHIR due to their binary definition of FHIR support.

“Although this study estimates FHIR using a binary definition (whether or not a developer describes support in an app’s marketing materials), during real-world implementation the FHIR standard exists on a spectrum with multiple standard versions and API specifications,” they wrote. “This includes whether or not an app that supports FHIR uses an API that conforms to the US Core Data for Interoperability (USCDI) data standard or EHR-specific API capabilities.”

The researchers noted that while this data cannot support conclusive inferences about the overall state of the app ecosystem and the use of FHIR among these apps due to its limitations, the study provides insights that can be monitored over time.

“Now that FHIR is required as part of the ONC Health IT Certification Program, it will be important to measure its use both among EHR developers and third-party apps that integrate with these EHR data systems,” the study authors wrote.

The study provides baseline data in anticipation of the ONC Cures Act Final Rule’s December 2022 compliance date for FHIR API standardization.

“Monitoring the impacts of the rule will be important to providing insights into whether the goals to expand patient access to their electronic health information will be realized,” the study authors concluded.