Application Programming Interfaces in Health Care: Findings from a Current-State Sociotechnical Assessment.

OBJECTIVE: Interest in application programming interfaces (APIs) is increasing as key stakeholders look for technical solutions to interoperability challenges. We explored three thematic areas to assess the current state of API use for data access and exchange in health care: (1) API use cases and standards; (2) challenges and facilitators for read and write capabilities; and (3) outlook for development of write capabilities.
METHODS: We employed four methods: (1) literature review; (2) expert interviews with 13 API stakeholders; (3) review of electronic health record (EHR) app galleries; and (4) a technical expert panel. We used an eight-dimension sociotechnical model to organize our findings.
RESULTS: The API ecosystem is complicated and cuts across five of the eight sociotechnical model dimensions: (1) app marketplaces support a range of use cases, the majority of which target providers' needs, with far fewer supporting patient access to data; (2) current focus on read APIs with limited use of write APIs; (3) where standards are used, they are largely Fast Healthcare Interoperability Resources (FHIR); (4) FHIR-based APIs support exchange of electronic health information within the common clinical data set; and (5) validating external data and data sources for clinical decision making creates challenges to provider workflows.
CONCLUSION: While the use of APIs in health care is increasing rapidly, it is still in the pilot stages. We identified five key issues with implications for the continued advancement of API use: (1) a robust normative FHIR standard; (2) expansion of the common clinical data set to other data elements; (3) enhanced support for write implementation; (4) data provenance rules; and (5) data governance rules. Thus, while APIs are being touted as a solution to interoperability challenges, they remain an emerging technology that is only one piece of a multipronged approach to data access and use. Georg Thieme Verlag KG Stuttgart · New York.

Background and Significance

Interest in application programming interfaces (APIs) as a means of increasing the ease of health data access for—and exchange among—patients, health care providers, and payers has been growing, as federal and nonfederal stakeholders look for technical solutions to interoperability challenges.

Stewards of patient health information have long treated patient health information as proprietary data and have been reluctant to share information outside their own health care systems, providers, and business networks for many reasons. APIs are an attractive proposition for health care organizations that want to securely share certain information, for example, from a patient's electronic health record (EHR) without exposing the full dataset and/or unfettered access to the internal functionality of the EHR. Likewise, APIs have the potential to facilitate the sharing and/or aggregation of information from multiple, diverse nodes of the health data system—from EHRs to mobile health applications that collect patient data, remote monitoring devices, registries, and other health data sources. 1 “Read” capable systems allow EHR information to be received, reviewed, and saved by external systems; “write” processes have the additional function of enabling an EHR to process incoming data and incorporate that information into its clinical database.

Vendors (i.e., EHR vendors, middle-wear API management vendors) have used proprietary APIs for some time to support access to data within their own systems. However, as far back as 2014, the JASON Task Force recognized that the lack of standardized APIs was a barrier to achieving interoperability. As part of its effort to increase electronic health information (EHI) sharing, the 21st Century Cures Act requires the U.S. Department of Health and Human Services to implement conditions and maintenance of certification requirements, including that developers of certified health information technology (health IT) implement published APIs and refrain from practices within the definition of “information blocking.” 2 These requirements are reflected in the recently released Proposed Rule to Improve the Interoperability of Health Information. 3

Given the public-sector and industry interest in APIs as a key feature of an interoperable health system, this article elucidates the current state of the field prior to the release of the Office of the National Coordinator for Health Information Technology (ONC) proposed rule with regard to technical and nontechnical considerations associated with APIs. Further ONC rule making will undoubtedly have an impact on the availability of the Fast Healthcare Interoperability Resources (FHIR)-based APIs.

Objective

We explored three thematic areas for this article: (1) use cases and standards for APIs; (2) challenges, technical concerns, and facilitators for both read and write capabilities; and (3) outlook for future development of write capabilities.

Methods

We employed four methods to conduct the current-state assessment: (1) literature review (published and unpublished); (2) key informant interviews; (3) review of application galleries; and (4) a technical expert panel (TEP).

Literature Review

To address the three thematic areas, we conducted our search within three domains: interoperability; use cases; policy and key words that connect these domains with discussions of technical considerations like privacy and security. Searches of the published literature were conducted in PubMed in July 2018. Given that much of the innovative work in this area is emergent and has not necessarily been published in scientific journals, the peer-reviewed literature was complemented by reviews of the gray literature, which was obtained from well-known federal reports, 4 industry Web sites, 5 6 7 8 and Google searches. We generated and refined a set of medical subject heading terms and related keywords to initiate the literature scan. We then assessed the relevance of results and effectiveness of the search strings with a multipart process. First, we reviewed the title and summary of the top-20 results. Then, we reviewed any “phrase not found” errors; if a phrase was not found, we searched the results for keywords from the phrase to determine if they returned relevant or irrelevant results. Finally, the results from the new search were compared with results from the previous search to ensure that no relevant articles were lost and to assess the quality of those that were gained.

Table 1 presents successful search terms for the domains and use cases of interest. The gray literature (Google) search used the same search term domains, combining “APIs” with the other search term cells ( Table 2 ). To supplement our peer-reviewed literature findings, we focused specifically on domains not well represented in that literature. We assessed the relevance of results and effectiveness of the search strings by reviewing the title and summary of the top-20 results.

Table 1

PubMed search terms

Domains	Selected search terms
Interoperability	“application programming interfaces,” ”APIs,” “interoperability,” “FHIR,” “SMART on FHIR,” “data access,” “data exchange,” “common clinical data set,” “2015 Edition,” “ONC certification criteria,” “Argonaut Project,” “US Core”	and	“authentication,” “authorization,” “privacy,” “data privacy,” “security,” “consent” “OAuth 2.0,” “OpenID Connect,” “data de-identification,” “patient choice,” “patient consent”
API use cases	“patient-generated health data,” “patient-reported outcomes,” “electronic health record,” “longitudinal health record,” “clinical workflow,” “registry/registries” ; “patient-mediated exchange,” “data donation,” “view, download, transmit (VDT),” “shared decision-making,” “research”
Policy	“21st Century Cures,” “Blue Button,” “VA Open API pledge,” “Promoting Interoperability Programs”

Abbreviations: API, application programming interface; FHIR, Fast Healthcare Interoperability Resources; ONC, , Office of the National Coordinator for Health Information Technology.

Table 2

Gray literature search terms

Domains	Selected search terms
Interoperability	“application programming interfaces,” ”APIs,” “interoperability,” “FHIR”	and	Economic variables: “costs,” “fee,” “efficiency”
API use cases	“patient-generated health data,”“patient-reported outcomes.” “electronic health record,” “longitudinal health record,” “clinical workflow,” “registry/registries”		Privacy and security: “authentication,” “authorization,” “privacy,” “data privacy,” “security,” “consent”

Abbreviations: API, application programming interface; FHIR, Fast Healthcare Interoperability Resources.

After the optimal search string was determined and run, we downloaded all citations into Mendeley reference manager to review them for possible inclusion. The abstracts from the initial searches were reviewed against inclusion and exclusion criteria ( Table 3 ); potentially relevant articles were exported for full-text review.

Table 3

Inclusion and exclusion criteria

Inclusion

Exclusion

• Relevance to the three thematic areas for this paper: (1) use cases and standards for APIs; (2) challenges, technical concerns, and facilitators for both read and write capabilities; and (3) outlook for future development of write capabilities.• Specific to EHRs and APIs• Relevant to one or more domains of the sociotechnical model

• Solutions that were not specific to EHRs (e.g., focus only on a registry)• Articles about the efficacy of apps for disease self-management• Articles on privacy and security requirements for apps (rather than API access specifically)• Integration of PROs or PGHD not accomplished via an API• Clinician and patient perspectives on the clinical, technical, and logistical integration PRO/PGHD integration

Abbreviations: API, application programming interface; EHR, electronic health record; PGHD, patient-generated health data; PROs, patient-reported outcomes.

We identified 390 peer-reviewed articles and over 100 resources from the gray literature, the majority of which were then excluded based on a title and abstract review. Throughout the process, we applied a “snowballing” approach, examining article bibliographies to identify additional sources for possible inclusion and screening them using the aforementioned approach. We conducted full-text reviews of 39 peer-reviewed articles and 90 additional articles and reports identified through a Google search. In total, we included 20 peer-reviewed articles and 41 articles from the gray literature ( Fig. 1 ; see Supplementary Material S1 for a complete citation list [available in the online version]).

Fig. 1

PRISMA flowchart.

Key Informant Interviews

We recruited a convenience sample of 13 key informants who provided additional perspective and helped fill gaps we found in the literature. The informant group consisted of representatives from the three API stakeholder types identified in the “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule” 4 : API Technology Supplier, API Data Provider, and API User. We interviewed representatives from academic institutions and health care delivery organizations known to be at the forefront of API implementation and use ( n  = 5); EHR vendors with predominant U.S. market share in the inpatient setting ( n  = 2); and app developers and third-party API management and data sharing platform providers ( n  = 6). Only one API User (app developer) specifically represented the patient perspective. We developed discussion guides based on our research questions—expanding them into several core themes to discuss with the experts. These included an exploration of current API use cases, the use of read and write capabilities, challenges related to advancing write capabilities, and the characteristics of “open” APIs. The discussion guides were then tailored to the expertise of each of the three informant types to best elicit feedback in their professional capacity (see Supplementary Material S2 [available in the online version]). We reviewed the notes, synthesizing the responses across interviews, and within informant types to identify common factors that influence API development and use. Findings from the thematic analysis were organized by the sociotechnical dimension they addressed. The interviews allowed us to further clarify and deepen our understanding of the core themes, issues, and gaps that emerged in the literature review.

EHR Vendor App Gallery Reviews

The aim of the app gallery review was to determine the type of functionality and use cases supported by apps available in the marketplace. A comparison of functionality between apps was outside the scope of our review. We performed an environmental scan of the top-three EHR vendor app galleries and the SMART app gallery. We selected three vendors who represent the largest market share of 2015 Edition certified products in the inpatient setting, and are all within the top-10 vendors with respect to market share in the U.S. ambulatory and inpatient setting. 6

Our team reviewed each of the EHR vendors' application galleries 5 6 7 8 and the SMART App Gallery 9 and identified 271 available applications as of October 25, 2018. As a first step, we categorized the applications based on whether they were primarily provider-facing, patient-facing, or both. We then assigned each application an “intended purpose,” which included patient education and engagement, population health analytics, clinical decision support and patient safety, care coordination, administration, and financial (apps could have more than one intended purpose). Our categorization was limited to the information presented in the online description of the apps; we did not perform a review of available API documentation. To the extent that information on the type of standards supported by the app was provided in the description, this information was collected.

Technical Expert Panel

The TEP convened in December 2018 to discuss technical and policy considerations for advancing the use of write APIs. The TEP consisted of representatives from the following API stakeholders: academic medical institutions and health care delivery organizations ( n  = 2); EHR vendors ( n  = 3); health information exchange organizations ( n  = 3); and app developers and third-party API management and data sharing platform providers ( n  = 4). The stakeholder perspectives included those of clinicians, informaticists, software developers, executive leadership, and the patient. The role of the TEP was fourfold: (1) discuss findings from the results of the literature review, key informant interviews, and EHR app gallery review; (2) identify near-term opportunities to advance API development and use with a focus on write APIs; (3) identify challenges to the development of patient-facing apps; and (4) discuss considerations related to the costs associated with API development, implementation, and use.

Sociotechnical Model

We used the eight-dimension sociotechnical model developed by Sittig and Singh to assess key dimensions of health IT to organize our findings from the literature review, key informant interviews, and the TEP. 10 The model accounts for technical aspects (e.g., hardware, software, and standards) and nontechnical aspects (e.g., clinical workflows, internal policies, procedures, and work environment) involved in the design, development, implementation, use, and evaluation of safe and effective health IT. 10 In Table 4 , we list the model dimensions and relevance to APIs.

Table 4

Sociotechnical model dimensions and relevance to APIs

Sociotechnical model dimensions	API considerations and potential issues
Hardware and software	▪ Read/Write capabilities —The ability to access data from an EHR and write data to the EHR database  ▪ System functions— Data harmonization, patient matching functions, and quality controls that ensure high quality, usable data  ▪ Security— Authentication, authorization, and encryption  ▪ API maturity— A need to ensure stability of the API, so it changes minimally between versions and only when necessary, and if a major change is necessary, there is versioning, backward compatibility (if possible), and communication with users about the implications of the changes (e.g., release notes at a minimum, more direct communication ideal). App developers will need methods to upgrade external applications when the EHR developer changes the API, to maintain backward compatibility.  ▪ Software that can handle APIs —Considering operating systems, application servers, database servers, cloud environment, etc.
Clinical content	▪ Standards— Clinical content must be represented through use of a data standard that can be processed (e.g., HL7 v2, FHIR, and DICOM)  ▪ Documentation— IT staff at the clinical setting will need access to robust documentation and tools from the API developers to successfully use the APIs
Human–Computer interface	▪ User interface (UI) facilitators/issues —Health care providers need a usable form (i.e., UI) to interact with outside records, which should conceal the backend work behind the interface  ▪ Ease of determining data provenance and context— Clear designation of source, constraints of data collection methods, and date/time collected  ▪ Business and clinical rules for integrating information— Need methods for integration of outside data (i.e., clinical data models) with existing data
People	▪ User training— Sufficient training and implementation timeline can ease the transition to and understanding of a new technology  ▪ Data volume— Health care providers may be reluctant to participate, fearing a deluge of health data when using an API to incorporate outside information into their records  ▪ Data provenance— Fostering trust in the data through proper sourcing is needed to encourage use of the data versus ignoring it, rerunning a laboratory, etc.  ▪ Data quality— Creating a culture oriented toward capture of high-quality data
Workflow and communication	▪ Use case— Specific clinical content and processes for which APIs can improve patient and clinician access to data  ▪ Workflow improvements— APIs should significantly decrease the difficulty of calling records from different sources, as well as conducting processes like submitting claims and sharing information with other care providers, positively affecting workflow  ▪ Need for an API vendor contact— Direct line for communication and support will be necessary to quickly resolve issues (e.g., network connection is down, data are bad, requesting additional scope/fields)
Internal organizational policies and procedures, and environment	▪ Institutional policies— Organizations must establish who takes responsibility for adverse events precipitated by incorrect information, or misplaced reliance on information obtained from external apps via EHRs  ▪ Safety culture— Fostering a culture of awareness of potential health IT-related errors, shared responsibility for risk reduction, and institution-level self-auditing are all needed  ▪ Leadership and oversight —Health IT planning, implementation, and evaluation must be carefully overseen
External rules, regulations, and pressures	Regulations and policies  ▪ Policy priorities . 21st Century Cures Act and ONC Certification Criteria require API use as a condition of health IT product certification  ▪ Accreditation requirements —App developers may be unfamiliar with the Joint Commission guidance for safe use of health IT and reporting of adverse events  ▪ Data stewardship— Clarifying the responsibilities of all data users and health IT developers will support strong data governance and trust in the system
System measurement and monitoring	▪ Data validation and exception handling —Policies and procedures for validating data and processing exceptions are needed  ▪ Auditing system performance —Feedback on whether the system is functioning as it should, providing the right information to health care providers, is needed.  ▪ Instrumentation— Need to monitor that the API is being used, and how many calls it receives

Abbreviations: API, application programming interface; EHR, electronic health record; FHIR, Fast Healthcare Interoperability Resources; IT, information technology; ONC, Office of the National Coordinator for Health Information Technology.

Results

While the use of APIs in health care delivery and research is increasing rapidly, it is still in the pilot stages. Findings from the key informant interviews revealed a complicated ecosystem that crossed five of the eight sociotechnical model dimensions and included third-party app developers, heath IT developers, health care organizations, third-party platform vendors, patients, and internal and external application providers.

API Use Cases—Workflow and Communication Dimension

Key informant interviews and review of EHR app galleries revealed a wide variety of clinical and nonclinical use cases to which API-enabled apps are being applied. We reviewed all the apps and their core purposes and organized them into six intended purpose categories. Fig. 2 shows the distribution of apps across those six categories.

Fig. 2

Intended purpose of EHR vendor App gallery applications.

The most important distinction that emerged in assessing the API/app landscape was the issue of audience: apps for consumers (i.e., patients) versus apps for providers. Based on our review of the EHR vendor app galleries, the majority (69% of apps, 186 of 271) are provider-facing. Vendors have been using proprietary APIs for some time and these meet a greater range of user needs; however, several unmet needs exist. The provider-facing apps address a variety of clinical use cases with some write capabilities using proprietary APIs. In contrast, the majority of patient-facing apps offer read-only capabilities. In Fig. 3 , we describe the intended users of apps based on our review of the EHR vendor app galleries.

Fig. 3

Intended users of Apps in EHR vendor App galleries.

Given the current focus on provider-facing use cases, there are a range of unmet needs and opportunities for patient-facing apps. TEP participants identified a list of common and important use cases for patient care, for which data could be collected via patient-facing apps and then potentially written into the clinical record. These range from questionnaire-based responses on smoking cessation, social determinants of health, and at-home symptom monitoring to care plan and medication adherence, to allowing price comparisons for common procedures. The TEP discussed the potential to leverage FHIR standards to facilitate access to and aggregation of patient records to increase patient access to health data from multiple sources, and strategies to reduce the patient's burden of logging into multiple systems to gain rightful access to their EHI. At the same time, the TEP reflected on the need to inform patients of the potential risks of sharing or aggregating EHI via entities not covered by the Health Insurance Portability and Accountability Act.

Use of Read and Write APIs—Hardware and Software Dimension

Currently, read-only APIs predominate, particularly for patient-facing apps (with the exception of low risk, tightly constrained write functions like scheduling). Limited examples of write APIs are beginning to emerge, some of which leverage the Health Level Seven (HL7) U.S. Core Implementation Guide profiles and resources developed for the 2015 Edition Common Clinical Data Set. When a FHIR API is being used to read or write data, mapping is needed between the EHI in the native EHR database and FHIR. 11 The required mapping can be accomplished by the EHR vendor who may offer a limited “out of the box” menu or by an institution's local health IT team who often can more rapidly provide the FHIR resources mapped to the use-case critical EHI. In both instances, additional time and resources are required to ensure that the EHI is available for exchange.

API Standards—External Rules and Regulations Dimension

Discussions with EHR vendors and TEP members indicate that many of them have made investments in proprietary APIs over many years, supporting both read and write capabilities. To the extent that standards are being used, they are exclusively based on FHIR. This focus is in part being motivated by the JASON Task Force's recommendations to the ONC identifying FHIR as the best candidate API approach to data-level and document-level access. FHIR R1 achieved Draft Standard for Trial Use (DSTU) status only 5 years ago and is now recognized as an important standard for representing and exchanging EHI. Given the EHR vendors' prior investments in proprietary APIs, and that the standard has multiple versions and is still maturing, FHIR adoption is not widespread. Only an estimated 32% of EHR vendors are currently supporting the FHIR version 2 (DSTU2) released in 2015. 12

Standards for Clinical Content—Clinical Content Dimension

Based on the literature and key informant interviews, the most common use of FHIR-based APIs is to support the exchange of patient EHI contained within the Common Clinical Data Set which includes 21 clinical data elements such as patient problems, procedures, medications, allergies, immunizations, and laboratory tests, along with their associated standard value sets and vocabularies. 13 FHIR profiles and implementation guides are used to describe specific use cases, thus constraining the FHIR standard and supporting interoperability among organizations wishing to exchange and use the information. Consistency in data representation and the use of standard terminologies such as SNOMED CT, LOINC, and ICD-10 among others has significant impact on semantic interoperability and data quality that have the potential to improve patient safety downstream. However, since mapping clinical data elements to FHIR resources is a time- and resource-intensive process, variation across EHRs, local customization, and loosely standardized data adds another layer of complexity to normalizing the data and as a result, FHIR APIs are currently used only to exchange the Common Clinical Data Set. Informants commented that the Common Clinical Data Set is too limited to adequately address their interests and range of use cases.

A similar lack of standards exists for the array of provider-facing use cases key informants and TEP members described, as well as for incorporating new and emerging types of data such as PGHD and PROs. Patient-collected and -reported information can create added technical and implementation barriers for providers interested in writing these data into their EHR systems.

TEP participants also raised the need to expand to payer data sources. Specifically, commercial payers could use the ongoing standards development project by CARIN Alliance to develop the CARIN Common Payer Consumer Data Set, 14 which specifies the data elements and offers an implementation guide, to create a FHIR-based API to develop patient-facing apps. The TEP also discussed standards developed by the HL7 initiative known as The Da Vinci Project, 15 which brings together value-based care stakeholders to advance data standardization and easy information access to facilitate payers' and providers' creation of efficient care delivery solutions and effective care management models.

Current Challenges and Technical Concerns—Internal Organization Policies, Procedures, and Environment Dimension

Both the literature and interviews demonstrated the reluctance of health care providers, health care organizations, and EHR vendors to allow external data, including PGHD, to be fully integrated (i.e., written) into an EHR. Concerns they raised included the volume of data providers would need to review; liability issues, if providers overlooked EHI that was in their systems and in retrospect could have been acted upon if it had at least an arguable potential to improve a clinical outcome; potential for cyber-attacks; potential for information overload from the myriad false positives; and issues around maintenance and display of data provenance.

EHR vendors, in particular, expressed concern during our interviews about write capabilities (e.g., in regard to enabling users of external apps to create and submit orders directly into the EHR, potentially bypassing existing proprietary business logic) and the potential for loss of data integrity and system security by their health care clients. When EHR software is used by health care providers, a variety of validation rules, constraints, and business rules are applied before data are committed to the database. To ensure that write APIs work correctly and avoid data corruption, EHR vendors must ensure they are applying the same rules to data written through APIs and mapping the data correctly to the native database structure. In certain cases, EHR vendors may have licensed some of these rules (e.g., from a drug knowledge vendor for medication management) or consider them proprietary, thereby contributing to their concerns about exposing them to third-party app developers. This creates challenges in defining, standardizing, reconciling, and integrating incoming data from external systems into vendor EHRs with years' worth of internal, proprietary information whose meaning, format, and use in context may differ substantially among different EHRs.

Despite the technical challenges and associated concerns, health care organizations are venturing into API write capabilities and reported during interviews that they see tremendous value in doing so. Some leading organizations are exploring a range of use cases around write capabilities, but doing so within secure, highly controlled environments. In these cases, the organizations are developing apps themselves and making them available to their providers on organization-issued and -controlled devices, which can be quickly deactivated in case of loss or theft. These internally developed apps largely use proprietary APIs.

Discussion

The use of standards-based APIs to support information exchange is still very much in its infancy. Based on activities to date, we identified six central issues that have important implications for the continued advancement of API development, implementation, and use in the field. At a high level, these issues reflect a need for the following:

Development of a Robust Normative Standard for FHIR—Hardware and Software Dimension

While significant progress has been made in the evolution of the FHIR standard, multiple FHIR versions are being pursued by vendors and developers. The recent release of a stable normative standard FHIR v4 should help, although the fact that the ONC's recently released notice of rule-making references v2 will continue to be problematic for interoperability among those currently using different versions of the FHIR standard. Significant work is still required in the adoption of the normative standard; however, the existence of a normative standard should be a stabilizing force in the market.

Expansion of the Standardized Data Set for Clinical and Administrative Data—Clinical Content Dimension

EHR vendors we spoke to noted that their focus is on the Common Clinical Data Set because it is a requirement. However, the Common Clinical Data Set represents only a small subset of data available in an EHR. For both provider- and patient-facing data needs, there is clinical interest in supporting standard developments around other data elements (e.g., PGHD, PROs) or expanding the Common Clinical Data Set to include reports and images.

Similarly, there seems to be growing payer interest in improving access to administrative data. Work undertaken by CARIN toward development of the Common Payer Consumer Data Set will support health plan–specific API use cases for patient-facing and business-to-business apps.

Patient-Generated Health Data and Patient-Reported Outcomes—Clinical Content Dimension

Interest in the incorporation of PGHD and PRO information to inform, enable, and recognize better care has grown, but questions remain as to how these data can be best captured and used. Concerns related to these data encompass not only their accuracy and reliability but also their clinical utility. TEP participants expressed concern about the preparedness of providers to manage an influx of raw PGHD/PRO data, and a lack of mechanisms to incorporate these data into their clinical workflows in an efficient and meaningful way. One possibility noted was that apps be developed to filter and summarize raw PGHD/PRO data, before they are transmitted to the provider.

Enhanced Support for Write Implementation—Workflow and Communication Dimension

To advance write capabilities, FHIR implementation guides need to be updated to include write access (currently, it is focused on read access). Some interview and TEP informants argued that, in developing write implementation guides through community stakeholder consensus process, a practical path would involve taking a use case–driven approach—starting with less complicated write functions (e.g., scheduling) and gradually moving to more complicated functions (e.g., medication ordering). This sentiment was echoed by the TEP, who suggested several potential simple applications to demonstrate write functionality that are feasible given the current state of the field that would improve provider clinical decision making and patient contributions to the medical record:

Posting documents: Writing simple documents to the EHR from third-party apps that serve as an information filter.

Questionnaires: Writing questionnaire responses back into the EHR, for example, smoking cessation support and PGHD/PRO data collection questionnaires.

Defining FHIR resources to assist in using PGHD and PROs in the calculation of clinical risk scores.

Innovating on the level of machine learning and predictive analytics so that PGHD and PRO data are presented in an actionable format to providers at the point of care.

Patient data corrections: Developing a patient-facing app that allows patients to contact their providers and request edits to their record (e.g., medication lists).

Leveraging specialized APIs: This includes CDS Hooks and other APIs that process data and provide clinical decision support.

When considering the future of write APIs, the use cases and utility of pursuing APIs within a given use case will help establish industry standards for write implementation incrementally and in high-value areas. For example, several TEP participants also noted that several write use cases had been recently submitted to the Argonaut Project for consideration in the work to be prioritized for 2019.

Data Provenance Rules—Internal Organization Policies, Procedures, and Environment Dimension

Immature data provenance rules contribute to concern surrounding write APIs and the use of external data. Write issues are complex but not unique to APIs, meaning data written by APIs should generally be subject to the same requirements as data entered through a vendor's native application. There is a need to improve the data provenance rules in the FHIR implementation guides, and outside FHIR, to successfully enable interoperable data exchange. As a part of considering how to capture and how to represent data provenance in the EHR, careful thought should be given to whether external data should be shown separately; seamlessly merged with native data; or combined with native data, but with a distinguishing appearance. Likewise, careful thought should be given to whether and how data from other sources need to be validated, and what the effect of validation is. If there are technical or semantic issues in importing/merging data, any resultant implications should be identified and displayed to EHR users. These types of issues could be surfaced by allowing developers to test apps in a sandbox, ensuring access to transparent and consistent vetting programs and procedures. Another TEP-recommended approach to facilitate source identification is the use of digital signatures to indicate whether data have been edited, and by whom. 16

Data Governance Guidelines and App Vetting—Internal Organization Policies, Procedures, and Environment Dimension

Concerns exist around issues of governance, data security, and integrity of apps. Data governance includes specifying who has the authorization to write data into an EHR. As write APIs are planned and developed, it will be important to have clear guidelines and procedures regarding how health care organizations would evaluate and validate external data, how that information should or would be used, and what new obligations might be placed on organizations or individual clinicians to act upon external data received. TEP participants remarked that not all data are actionable or clinically useful, and therefore suggested that providers should be responsible for approving clinical data before they are written in from outside sources. A potential near-term solution raised in the discussion would be to have bidirectional (e.g., publish/subscribe) data exchange between a provider and a patient—that way, a provider can flag data they want to request or review from their patient (e.g., specific questionnaires) and reject data they do not want sent/written (e.g., pedometer data).

In today's API environment, there is a wide range of app vetting procedures to maintain the safety and security of EHI on a data provider's system, during transmission to duly authorized apps, and (where applicable) while used or managed by the app. In some cases, vendors make available sandboxes for testing apps prior to go-live, and then apply stringent testing procedures prior to app release. The more robust testing is typically reserved for provider apps; less stringent testing seems to be the norm for apps used to facilitate patient data access. Robust and transparent rubrics to app vetting for all apps would be to the benefit of users and developers alike—applying best practices to the review process and ensuring that people know how apps are interacting with and protecting the data. Several federal resources and tools are available to assist app developers to better understand the privacy and security laws that may apply to their apps in various contexts. 17 18 19

The TEP called attention to another gap in vetting: that workflow integration is not addressed by the current EHR vendor app vetting processes. As a result, health care organizations expend significant resources on data and workflow integration—costs that are not borne by the app developer. In addition, current vetting processes do not scale, as a result of the two-tier vetting process where individual apps are vetted by each individual organization. To address the challenge of scalability, TEP participants suggested an external validation process, rather than the current two-tiered vetting process for apps. Validation differs from vetting in that it is the process of checking whether the application satisfies the intended clinical use. The goal of validation would be to set criteria or benchmarks (e.g., a code of conduct) that API Users could use to assess the security and privacy protections of different apps. Some TEP participants also suggested specifying for API Users how a given app has been vetted, for example, whether it has been subject to safety, usability, and/or security assessments.

To help build confidence across the health care market that privacy and security concerns are being taken seriously by those involved in app development and vetting, key informants suggested development of an app developer code of conduct. Similarly, TEP members noted that the adoption of an industry code of conduct among app developers could improve the information available to stakeholders to help inform their decision making around app use and provide a rubric against which apps could be evaluated. This, in turn, could help alleviate privacy and security concerns and increase the efficiency of the app vetting process. For example, such a code of conduct could include a pledge to use the 2018 ONC Model Privacy Notice to ensure users are appropriately informed about privacy and security policies. 20 To address app safety concerns, work is being done by researchers at the University of California San Francisco to develop an assessment program that provides guidance to health care organizations about evaluating digital technologies that interact with the EHR. 21 22 The U.S. Food and Drug Administration is developing the Digital Health Software Precertification Program, which is envisioned as a voluntary pathway to assess the safety and effectiveness of software technologies without inhibiting patient access to these technologies in a more tailored regulatory paradigm than that traditionally used for other types of medical products, such as hardware-based medical devices. 23

Further Develop Apps to Support Patient Access to Health Information and Increase Patient Awareness of their Rights—People Dimension

TEP participants emphasized that ensuring patient access to their clinical data is vital for improving patient engagement, and a necessary component of ensuring EHRs provide value to patients. Findings from the TEP indicated there is demand to alleviate patient workflow challenges around longitudinal record aggregation from multiple disparate patient portals; however, the marketplace of patient-facing APIs and apps is far more limited. Participants discussed that it can be challenging for patients to access their health records via existing portals without special effort. Patients typically receive health care from multiple providers working in multiple health systems, which may or may not use the same EHR and may not share this information in an interoperable way. One suggested solution was the use of knowledge-based authentication; another was two-factor authentication. The discussion noted it would be useful to establish a trust framework and technology solution(s), whereby log-in credentials are established by a trusted source that had appropriately verified the identity of the person to whom credentials were issued. This would allow patients to use the same trusted credentials to log into any portal that houses their health data, and therefore substantially reduce the burden of accessing health data. Another suggested solution, where APIs can play a role, was to develop a “catch-all” patient record in which the patient's health data are aggregated from multiple patient portals. This would necessitate the use of standards like FHIR and the sharing of FHIR endpoints among vendors, which would require vendor cooperation and maintenance.

TEP participants raised the potential solution of third-party companies aggregating health data via direct-to-consumer patient-facing apps and/or personal health records. Although these solutions facilitate access, TEP participants were concerned that patients choosing and using these solutions may not have clear and understandable information regarding how the apps will protect the security of their data and how the third party's terms of use or privacy policy might permit the company to use or disclose the patient's information to others without seeking further approval from the patient. It was noted that there is currently a general lack of transparency regarding who will view EHI that is shared with a direct-to-consumer app, and about what uses the app vendor might make of the data beyond delivering the app's functions for the users who share their data with it.

Limitations

The stakeholder perspectives represented in this assessment are predominately those of early adopters, API Technology Suppliers, and API Data Providers. The patient perspective was limited to one API User that represented a patient engagement app. A broader set of key informant interview inclusion criteria that encompassed health care organization end-users who directly use API-enabled applications in their clinical or care delivery workflows was out of scope for this project, but offers great promise for future researchers.

Conclusion

Our findings indicate that the application of APIs to exchange of EHI is a developing area with promising growth—with many issues yet unresolved. A multitude of app marketplaces are becoming available with a variety of health-targeted apps for providers, and a more limited number for patients. There are numerous unmet needs with regard to patient-facing apps, including those that facilitate data access, aggregation of data into a patient-controlled health record, and strategies for the effective capture and use of PGHD and PROs.

Many of the available apps use consensus technical standards, but many others remain proprietary. Where consensus technical standards are being used, they are largely FHIR based, which is a positive indication of the market's shift toward developing interoperable solutions. Most of the activity is focused on read APIs with limited use of write APIs. As the clinical and patient applications for APIs increase, input from both EHR end users and patients will be critical to understanding how these tools are being used to improve clinician workflows, usability, and patient engagement, and are an important area of future exploration.

Thus, while APIs are being touted as a solution to the interoperability challenges within the health system, they remain an emerging technology that is likely to be one piece of a multipronged approach to data exchange, integration, and use.

Clinical Relevance Statement

APIs offer tremendous opportunity for health care organizations that want to securely exchange patient health information. As this article elucidates, continued research and exploration into key sociotechnical issues will have important implications for the advancement of API development and routine use in clinical practice to support health information exchange, clinical decision making, patient empowerment, and population health management.

What are the most common types of apps?

Patient-facing.

Provider-facing.

Both patient- and provider-facing.

Neither.

Correct Answer: The correct answer is option b. Based on our review of the EHR app galleries, the majority (69% of apps, 186 of 271) are provider-facing.

Which of the following technical challenges contributes to the reluctance of health care providers, health care organizations, and EHR vendors to write data into an EHR?

Volume of data.

Liability issues.

Potential for cyber-attacks.

All of the above.

Correct Answer: The correct answer is option d. Both the literature and interviews demonstrated the reluctance of health care providers, heath care organizations, and EHR vendors to allow external data, including PGHD, to be fully integrated (i.e., written) into an EHR due to multiple technical challenges. The volume of data, liability issues, and potential for cyber-attacks are among these concerns.