Why APIs? Anticipated value, barriers, and opportunities for standards-based application programming interfaces in healthcare: perspectives of US thought leaders

Abstract

Objective

Improving health data interoperability through application programming interfaces (APIs) is a focus of US policy initiatives and could have tremendous impact on many aspects of care delivery, such as innovation, operational efficiency, and patient-centered care. To better understand the landscape of API use cases, we interviewed US thought leaders involved in developing and implementing standard-based APIs.

Materials and Methods

We conducted semi-structured virtual interviews with US subject matter experts (SMEs) on APIs. SMEs were asked to describe API use cases along with value and barriers for each use case. Written summaries were checked by the SME and analyzed by the study team to identify findings and themes.

Results

We interviewed 12 SMEs representing diverse sectors of the US healthcare system, including academia, industry, public health agencies, electronic health record vendors, government, and standards organizations. Use cases for standards-based APIs fell into six categories: patient-facing, clinician-facing, population health and value-based care, public health, administrative, and social services. The value across use cases was viewed as unrealized to date, and barriers to the use of APIs varied by use case.

Conclusions

SMEs identified a diverse set of API use cases where standard-based APIs had the potential to generate value. As policy efforts seek to increase API adoption, our work provides an early look at the landscape of API use cases, value propositions, and barriers. Additional effort is needed to better understand the barriers and how to overcome them to create value, such as through demonstration projects and rigorous evaluations for specific use cases.

Lay Summary

Application programming interfaces (“APIs”) are a technical way of getting data out of a computer system. Recently, the United States passed legislation (the 21st Century Cures Act) requiring the use of APIs for electronic health record systems, which are where most healthcare providers document clinical encounters with patients and where other clinical data is held. In this article, we asked national experts in health information technology to describe some of the ways in which APIs could be used, how they are valuable, and what some barriers may be to broader use. We found 6 main categories, or “use cases,” for APIs in healthcare—patients, providers, administrative, public health, social services, and population-health. We also describe why these use cases are important, as well as barriers within each use case. As more and more health data are made available via APIs, these use cases will drive the success of these technological innovations.

INTRODUCTION

Application programming interfaces (APIs)—a technology which allow disparate systems to exchange information and functionality in a discrete and computable fashion—have had tremendous impact on growth, efficiency, and innovation across numerous industries, such as banking, automotive, and retail.^1,2 Recognizing the potential for APIs to improve healthcare delivery, the 21st Century Cures Act (Cures Act), and the Office of the National Coordinator for Health IT (ONC)’s associated Final Rule require that health information technology developers such as electronic health record (EHR) vendors make standards-based APIs available.³ These policies build on a decade of federal incentives to increase the electronic accessibility of data to patients.⁴ As a result, nearly all hospitals in the US have capabilities for patients to electronically view their electronic health information (EHI),⁵ including the US Veterans Health Administration,⁶ and as the Final Rule implementation period begins, it is expected that nearly all patients will be able to access their EHI through APIs, with specific data requirements driven by the US Core Data for Interoperability (USCDI) standard.⁷ Although early work has emphasized patient access to their data, the promise of APIs in healthcare extend to other contexts and is the focus of other federal, state, and private efforts. For example, APIs are expected to facilitate data sharing between different healthcare organizations⁸ and streamline electronic case reporting (ECR) to state or federal agencies.⁹

The success of APIs in healthcare is not a foregone conclusion. For patient-facing use cases, early results show increasing but modest usage, with one study demonstrating around 1% of eligible patients using APIs.^10,11 For other use cases, results are not yet available. The impact of APIs will depend on multiple factors beyond technology, such as the value propositions, stakeholder incentives, implementation complexity, and priorities of healthcare organizations and vendors. These factors may vary by use case. To better understand the current state and potential of APIs in healthcare, we interviewed a sample of thought leaders actively involved in developing and implementing APIs in the US healthcare system. We sought to identify as many use cases as possible in which standards-based APIs are used, understand the value of the APIs, and identify key barriers and opportunities to make APIs achieve their value.

METHODS

We conducted semistructured virtual interviews with US subject matter experts (SMEs) on APIs. SMEs were identified from study team knowledge and personal networks. Snowball sampling (recruiting through recommendations from study participants) was used to identify subsequent participants. Recruitment continued until saturation of key concepts (API use cases categories and anticipated types of value for each category) was achieved. Interviews were audio recorded and key points were summarized by 1 member of the study team (WJG) with a second team member reviewing and verifying (RSR). Because of the complex nature of the topic, we verified accuracy using “member checking,” in which the SMEs reviewed and approved the summaries and provided additional clarification when needed.¹² Interviews were conducted between December 2020 and May 2021. Each interview lasted at least 1 h, but not longer than 2 h.

SMEs were each asked to identify and describe all API use cases they were familiar with. For each use case, SMEs were subsequently asked to discuss the anticipated value of APIs within those use cases and barriers to usage. To analyze the data, 2 research team members (WJG and RSR) independently reviewed all summaries and inductively identified key points and categories of unique use cases, types of value, barriers, and suggested opportunities to overcome barriers and realize value, which were aggregated and summarized below.¹³ The study team discussed the data and achieved consensus on findings and cross-cutting themes. Institutional Review Boards at RAND and Mass General Brigham approved this study.

RESULTS

We interviewed 12 SMEs representing diverse sectors of the US healthcare system, including academia, industry, public health agencies, EHR vendors, government, and standards organizations (see Acknowledgments for a list of interviewees). Although some participants noted that APIs have been present in healthcare for decades (eg, HL7-V2 for immunization data, or X12 for billing transactions), SMEs emphasized a recent surge in API interest, capabilities, and implementations. Use cases for standards-based APIs fell into 6 categories described below and in Table 1. SMEs also identified barriers and opportunities for progress. Of note, the 6 use cases had some overlap (eg, a patient receiving immunization data from a public health agency could be both patient-facing and/or public health).

Table 1.

Categories of use cases for standards-based APIs, with examples, anticipated value, and barriers

Use case category	Example use case	Value of APIs	Barriers to API adoption
Patient-facing	Patients access EHR data using third-party app Patients download and use claims data from health plan in third-party app Patients use single app to schedule appointments across all their providers	EHR data are easier for patients to review, aggregate, share, or use for health-related decisions and activities Payer data can help patients make decisions that take costs into account	Business model for patient-facing apps are lacking Value to patients of aggregating EHR data or claims data alone may be limited Variable workflows (eg, for scheduling) present challenges for write-based use cases EHR vendors do not always publish endpoints or make it easy to register apps EHR data may be missing or incomplete Patients may not trust app companies with their data
Clinician-facing	CDS apps extend EHR functionality, allowing customizations not natively supported by EHR App is developed at 1 institution and easily installed at a different system Clinicians can access data from another healthcare system	Facilitates innovation in EHR-based functionality by extending core capabilities; new features can improve care in myriad ways (eg, clinical decision support, workflow improvement) Improves clinician professional satisfaction through more usable tools	Fee structures for app developers may limit innovation Data elements available via API vary by vendor so proprietary APIs are still needed Surfacing apps in workflows is challenging (low adoption of CDS hooks) Writing back to APIs is complicated by downstream business logic
Population health and value-based care	Provider accesses claims data submitted by other providers Quality measures are retrieved from EHR data and reported to payer	Makes more data available for clinical decisions, reduces data collection burden, allows for tracking follow-up visits, enables standardization and reuse of analytic tools Standardizes chart abstraction to enable automation and replace expensive, manual, error-prone processes	Lack of trust among providers with sharing data with other providers and with payers FHIR endpoints not established among most providers Integration of data in workflow is challenging
Public health	Provider sends and receives immunization data to public health reporting agencies Public health agency receives reportable electronic case data from provider EHR Patient accesses immunization data through app (through EHR or from registry directly)	Improves accuracy, quality, completeness, and timeliness of data for public health decisions, forecasting needs, and use in clinical care More efficient data exchange to meet regional and federal reporting requirements	Public health agencies lack IT infrastructure and money Federal and regional reporting requirements vary substantially
Administrative	Prior Authorization determinations—bidirectional exchange between provider and payer Eligibility checking—bidirectional exchange between provider and payer Payer exchange (of claims data when patients switch plans)	Standardizes payer–provider interaction to improve efficiency and accuracy of payment-related determinations Makes it easier for new payer to access claims history for coverage decisions, especially valuable for patients with multiple chronic conditions	Lack of trust between payers and providers with exchanging data (value-based contracts better align payer–provider incentives when both parties bear risk) Payers lack experience and work processes for giving real-time responses to prior authorization determinations
Integrating clinical and social services	Screening for social risk Closed-loop referrals to social services	Facilitates integration of standards-based social risk assessment questionnaires into EHR Enables clinicians to query social services for capabilities/availability, and execute/track referrals	Social services lack IT infrastructure and money Capture of social data is unreliable in EHRs and would require workflow changes Unclear financial incentives for data sharing

API: application programming interface; CDS: clinical decision support; EHR: electronic health record; FHIR: fast healthcare interoperability resources.

Patient-facing

SMEs described how APIs enabled better access to data from EHRs and payers, thereby helping patients make more informed health-related decisions, such as ensuring correct medications were used in health apps and staying current on vaccinations. Even without the ability to support writing back to EHRs, which is not widely implemented, some SMEs believed access to data has the potential to produce substantial value by allowing patients to aggregate the data across multiple providers, share their health data with others such as for second opinions, enable better care management, and share data with research efforts like clinical trial registries. However, some SMEs also acknowledged that the value of these APIs is still “faith-based” (ie, that the potential value hasn’t emerged yet) and that there may be minimal value to patients solely from access to data, which was described by 1 SME as a “building block.”

SMEs also identified substantial barriers to these types of APIs, such as the lack of an established business model: “There hasn’t been a lot of creativity around use cases [for patient-facing APIs]… but a lot of that probably gets back to. … they need a financial use case to support their business and they are trying to work out exactly what that is.” Adding to these business model challenges is that patients may not trust their health data with third-party apps (which may not be covered by the Health Insurance Portability and Accountability Act (HIPAA)), a problem that CARIN alliance is attempting to address by creating a code of conduct for health apps.¹⁴ Providers may also prevent some types of clinical notes from being available via APIs, citing regulatory carve outs for certain types of notes such as psychotherapy notes. Challenges in data availability were also identified as the likely reason for the minimal uptake of some APIs, such as for viewing care plans, which often are not populated in EHRs. Workflow issues created additional challenges, such as for patient scheduling APIs. One SME said that “scheduling is less of a technical challenge and more of a workflow challenge, in terms of how you determine what open slots you have, whether a clinic can even make available slots directly to users… Those workflow challenges weren’t anticipated as much as they should….” Experts said many app developers find challenges working with EHR vendors that do not fully support API standards.

Clinician-facing

SMEs described the value of APIs for clinician users by allowing apps to extend the functionality of the EHR more easily, such as through clinical decision support (eg, making guidelines accessible at point of care, risk calculations) and clinical data exchange among providers. Several SMEs noted that there is a lot of potential functionality that EHR products do not easily support and that EHR vendors are not prioritizing but can improve care as well as improve clinician professional satisfaction. Once built, apps that leverage standards-based APIs would be portable to other institutions, thereby avoiding the need for each institution to develop its own. Experts also noted significant challenges to realizing this potential value: EHR vendors have varied and confusing pricing models for API usage, and some do not support easy deployment of apps; lack of comprehensive data standards (eg, for appointments) result in apps often still requiring proprietary APIs or middleware, restricting portability; surfacing apps in workflows is challenging without introducing friction that imperils the user experience; provenance of external data is not well tracked, necessitating frequent data reconciliation; developing APIs for writing back to the EHR requires accommodating complex downstream business logic (eg, need to check medication interactions for new allergies); and provider organizations lack resources and expertise to evaluate the impact of apps on clinical outcomes or financials to inform their decisions.

Population health and value-based care

SMEs described uses of APIs for population health and value-based care (VBC). For example, payers can use APIs to send claims data to providers in bulk for population analytics and patient care. Providers can make APIs available to improve the accuracy and lower the cost of chart abstraction processes, which are used to adjudicate risk contracts and reimbursement. One participant said that “as people move further and further in their contract relationships to value, that exchange of clinical data becomes critically more important for both parties to really understand what’s happening” and that APIs were a key enabler of that clinical data exchange. Similarly, the Health Level Seven International (HL7) FHIR Accelerator “DaVinci”¹⁵—mentioned by several participants—includes several use cases to support VBC, such as data exchange for quality measures (eg, exchanging quality information from a provider to a payer) and exchanging information to identify patients who are part of a risk contract.

One important barrier to the use of APIs for population health is the lack of trust between providers and payers. According to 1 SME, “the providers need to change their trust model and unleash clinical data to the payer in order to make their value-based contract actually work.” Payers must also ensure that the data they send to providers are limited to patients attributed to those providers, which is particularly challenging if there is no risk contract in place and patient attribution mechanisms are less established: “You don’t want to be blasting data out to people who don’t have a right to it.” As with clinician-facing use cases, once the data is available, surfacing it at the right time in the providers’ clinical workflows is also a challenge.

Public health

SMEs also described use cases in which APIs could support public health for improved efficiency in data exchange; producing higher quality, more reliable, and more complete data; and creating opportunities for real-time data availability and reporting. SMEs believed the COVID-19 pandemic highlighted the need to use APIs for reporting and exchanging public health information between different organizations. APIs for immunization data were noted to be a mature use case with significant real-world usage. Efforts to use APIs for ECR, participants believed was largely unidirectional from the EHR—“a lot more focus on getting the data out right now” and that ECR data coming back to providers (eg, write-back APIs) from central sources “is still work to be done.” Numerous challenges were also highlighted—notably, that public health departments lack IT infrastructure and money to take advantage of these APIs, and the large number of requirements around reportable data and rules around sharing which vary considerably by local, regional, and federal jurisdiction—“the pandemic shined a big light on that—we are not very well coordinated and networked to share data cross-jurisdictional.” Ongoing efforts cited by SMEs are attempting to harmonize these rules and requirements.¹⁶

Administrative

Several use cases were identified for APIs supporting healthcare administrative functions, with a strong focus on data exchange between healthcare providers and payers. Prior authorization (eg, for a prescribed medication) was repeatedly brought up as an exemplar way that APIs could improve the experience for all stakeholders—a health plan would provide the data requirements via an API, the healthcare provider then sends those required data elements back to the health plan, and the health plan returns a response, all using APIs. A key point raised for this use case is that APIs would enable real-time data capture as part of clinical workflows, as opposed to retrospective, document-based data capture that is the current standard—“you are removing the need to have to share that structured document to prove the data because you are actually capturing it in workflow.” Insurance member eligibility checking was noted as another use case that APIs can streamline. One participant noted that much of the current effort behind the administrative use cases for APIs is due to guidance and policy set by the Centers for Medicare and Medicaid Services (CMS), specifically the Interoperability and Patient Access rule published in March 2020, which requires that eligible payers create APIs for common administrative workflows (such as prior authorization) following existing implementation guides.¹⁷

Challenges with administrative use cases noted by SMEs included the workflow change required to leverage APIs (“its not just about technology—its about the day-to-day, the people inside those organizations, and how they interact with each other and their members”), as well as more robust trust models so that providers are able to share clinical data with payers. Similar to other use cases, technical infrastructure was also highlighted as a concern—“we are seeing a lot of re-write of really fundamental systems in provider and payor organizations, or re-platforming efforts going on across the industry, to ready themselves to be able to move towards APIs.”

Social services

A final API use-case category involved integration of clinical and social services to address social determinants of health (SDOH). SMEs described how APIs could improve interactions between EHRs and social service organizations by identifying and documenting social risk factors (defined as the adverse social conditions associated with poor health¹⁸) and by streamlining referrals to a social service organization for patients with a social need (eg, close-loop referrals to a food bank)—“the social care referrals are really important…. and where the APIs play a critical role.” SMEs distinguished Social Services from public health based on the actors and information exchanged. A major barrier to progress on this use case was the lack of information technology infrastructure present in social service organizations; unlike hospital systems, social service organizations have not been entitled to federal incentives like Promoting Interoperability. As a result, SMEs said it has been challenging finding organizations with the capability to stand up FHIR endpoints, even for a pilot—“we need to connect with an enterprise that has never connected with a healthcare system.” Social service technical resources may also lack knowledge of health data standards like FHIR, further increasing the cost and complexity of implementation.

Opportunities for standards-based APIs

Many participants discussed ongoing and possible future work needed to advance standards-based APIs to achieve their potential value. The HL7 accelerator program, which includes several efforts targeting specific content areas, was highlighted as promising for advancing API use cases in different domains. For novel API use cases with limited examples in operational use, participants suggested different approaches to defining API requirements. Some believed API use cases should emerge from only real-world implementations and then be standardized. Others thought waiting for real-world implementations would be too slow, and the standards community should push forward with implementation guides even before there were substantial operational examples. In either case, several participants said that real-world demonstrations are critical to realizing the value of APIs and recommended they be expanded.

DISCUSSION

SMEs identified a wide range of types of value that could be created from standards-based APIs across 6 use case categories—patient-facing, clinician-facing, population health and VBC, public health, administrative, and social services. SMEs also identified numerous barriers to implementation and broader use of APIs which varied across use cases and included issues related to technology, incentives, trust among stakeholders, workflows, and fee structures. This work shows the significant potential value and existing efforts underway to advance standards-based APIs in healthcare, but it also highlights the substantial challenges to realizing their potential value.

It was evident from our interviews that some of the use cases have better incentives and stakeholder alignment than others for longer-term sustainability. The administrative use cases in particular—interactions between providers and payers such as for prior authorization and eligibility checking—had seemingly strong alignment, with clear, demonstrable return-on-investment for adopting APIs, especially under VBC contracts.¹⁹ Other use cases, like social services, had less obvious financial alignment and may benefit from additional policy intervention to achieve broader use. There was also an interesting tension around how to best increase API use in healthcare, with some SMEs arguing for implementation guidance ahead of operational examples in the interest of more rapid advancement, and others suggesting that real-world examples should drive standardization efforts to ensure they are anchored in on-the-ground reality. Best practices may emerge for getting APIs into routine use over the next few years and resolve this tension.

Our study provides an early assessment of the current state of APIs in healthcare. Though other work has tended to focus on patient-facing use cases,^{6,10,11,20–22} our work demonstrates the myriad use cases of APIs beyond patient access to their health records, with tremendous potential to create value. Notably, we found that much of the potential for APIs is unrealized—SMEs repeatedly expressed that APIs are in an early stage of maturity across most use cases. Many SMEs highlighted substantial organizing efforts (such as the HL7 FHIR Accelerators²³) to convene multiple stakeholders and advance API use cases, but these were also considered to be early stage.

US policy has attempted to enable the exchange of EHI for more than a decade,⁴ including several recent efforts: the Cures Act requires APIs to be made available “without special effort”³; the 2020 Cares Act includes funding for public health information system modernization including interoperability expected to use APIs²⁴; and the second version of the US Core Data for Interoperability recently standardized numerous additional data elements including demographic data and SDOH.⁷ Although these policies provide a foundation for making standards-based APIs available, significant additional effort, such as demonstration projects to assess feasibility and evaluations to assess impact, are likely needed to ensure APIs are used and create value across diverse use cases.

Our study has several limitations. Our participant interview size was modest, though it did represent SMEs from a range of stakeholders, and SMEs were selected based on author’s existing networks and snowball sampling, which could have biased towards specific use cases. Future work would benefit from an analysis of how stakeholder perspectives vary by sector. We did not objectively measure API usage across use cases, work that is ongoing in other areas.²⁵ Finally, we focused primarily on APIs that facilitate data exchange with the EHR; other API use-cases (eg, payer-to-payer data exchange) could also drive value and improve care delivery.

CONCLUSION

To our knowledge, this is the first study to examine the range of potential ways APIs can create value across myriad healthcare use cases. We provide a framework of 6 categories for describing these use cases. As policy efforts attempt to increase API adoption and use, our work provides an early look at how APIs can add value and the range of barriers, which vary by use case. Across all use cases, additional effort is needed to better understand the barriers in each use case and how to overcome them to create value, such as through demonstration projects and rigorous evaluations for specific use cases.

FUNDING

This work was funded by The Pew Charitable Trusts.

AUTHOR CONTRIBUTIONS

WJG and RSR conceived the study, conducted the analysis, and drafted the article.