January 26, 2021
Source: PEW
Photo / Image Source: Unsplash,
Documentation review and interviews highlight API value and promise
The documentation review and interviews revealed that APIs that are currently available and those that will be developed in the future have the potential to improve interoperability in health care, yet obstacles remain to broader use. Specifically, the research found that decision support tools remained an area of interest for both EHR developers and providers; patient access was the most common use case; provider-to-provider exchange is not widely implemented, despite few technical barriers; and, there exists wide variability in what data and capabilities are available across systems.
Clinical decision support tools build value for clinicians
CDS tools are applications that use data from health records to help providers make clinical care decisions. Applications in use cited by interviewees helped with pediatric growth monitoring, diagnosing and managing pulmonary emboli, and forecasting for immunizations. These applications can synthesize years of patient data in useful ways, transforming the health record from simply an information repository into a dynamic technology that offers benefits beyond the base system. Many decision support tools today use both proprietary and FHIR-based APIs to access data. Providers still use proprietary APIs because some data may not yet be accessible via widely adopted standards. As more data becomes standardized and integrated into FHIR in accordance with the new federal regulations, these APIs will be able to replicate the functions of proprietary tools and may become more widely implemented.
Both hospitals and vendors stressed the importance of APIs to further the functionality and usefulness of decision support tools. Those hospitals with APIs in use for decision support confirmed that APIs can aid clinicians through access to better data; however, the apps’ usefulness depended on how easily they were incorporated into the provider’s workflow. These apps become less usable when they require providers to click multiple windows to review data. For example, if clinicians need to manually launch an antibiotic recommendation app, input relevant data, and then return to the patient record to enter the suggested medication and dosage, they are less likely to use the application in the first place, and more likely to make a mistake along the way. APIs can make it easier for decision support tools to be embedded in the EHR, launch when needed, and potentially input the selected medication for the clinician.
Vendors are currently focused on building out both proprietary and FHIR-based decision support, and plan to continue that investment. The regulations scheduled to take effect in 2022 will accelerate use of decision support tools by opening APIs to this use case and offering greater standardization in the data.
Patient access
"There are no HIPAA requirements with these apps. [Apps] can do whatever they want with that data. And so we have not encouraged apps almost to the point of discouraging [them] until we can get some assurance of privacy and security, that [apps are] following the HIPAA standards. No app will give us that."Hospital quote
Regulations implementing the Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandate that patients have a right to access their health information in the format of their choosing from organizations covered by the law, such as health care providers and health plans.4 As a result of the 2015 requirements, EHRs have been able to allow patients to access and download a subset of their data via a patient portal or API, though hospitals were required to adopt EHRs with these capabilities only in 2019.5 Recent rule-making will increase the information patients can access, including their clinical notes. Access to data allows patients to digest information outside the doctor’s office, aggregate their records across different sites of care, and manage their own health.
For example, research has demonstrated that when patients received access to their physician’s clinical notes, some individuals—particularly those who are older, less educated, non-English speaking, and non-White— reported the greatest benefit.6 Access to data about their own care allows patients time to digest and process information, discuss options and next steps with family members, and potentially ask their providers questions. Facilitating access to more data, such as clinical notes, may improve engagement in care for some vulnerable populations who have historically been more challenging to reach. As a result, putting patients in control of their information has the potential to help reduce disparities.
Given the requirements from government, APIs to support patient access of data are the most widely adopted API-based use cases examined. Hospitals confirmed that Apple’s Health app, MyLinks, and Medlio are three commonly used third-party vendors that allow patients to aggregate their personal health data. Interviewees cited Apple as a major driving force in increasing the use of patient access APIs. As of July 2020, 516 health care institutions, many representing multiple hospitals and clinics, enabled patients to access their records through Apple’s Health app.7
All hospitals interviewed noted that they have implemented patient access to EHR data, but some expressed reluctance to inform patients that they could download their records via APIs. Many hospital executive respondents did not perceive a benefit to patients and were wary of patients accessing their health records directly via APIs and third-party apps. Some interviewees expressed concerns about both the security of patient data and the lack of a patient market for this functionality.
The typical absence of HIPAA protections of third-party applications heightened hospitals’ concerns that patient data may be exposed or used in inappropriate ways once patients’ information has left the hospital, for which the hospital might then be held responsible.
Hospital interviewees expressed concern that patients run the risk of not understanding what a third-party vendor can do with their data, such as selling their information or using it to market to them. Staff at one hospital commented that they do not encourage the use of apps and will continue using their patient portal until they can get improved assurances about privacy and security from third-party developers.
Despite hospital concerns, patients have an existing right to their data, in the form of their choosing, because of HIPAA. Although HIPAA protections typically don’t pertain to these kinds of applications, consumer protections via the Federal Trade Commission apply. In addition, some consumer technology companies include privacy provisions—such as banning the sale of information gathered by applications—as part of their terms of use.
These findings align with recent research suggesting that only 10% of patients with a web portal are accessing their information, and 1% via API to a personal device.8 Research from ONC found that as of 2017, more than half of individuals in the United States had been offered online access to their medical record, and approximately half of those, or 28% of patients nationwide, did go on to access their information.9
Another study found that barriers to the increased use of patient-facing APIs included security concerns, lack of business drivers, vendor hesitation, and an immature app ecosystem, data standards, and technology.10
Several reasons exist for slow patient uptake, including access challenges, clunky technology, and poor marketing.11 Although patient access to data remains nascent, hospital reluctance—not technology—contributes in part to the limited uptake.
The new federal regulations will further spur patient access to data via personal devices, as additional data—such as clinical notes—will offer individuals key information they need and use of standards will accelerate exchange among more hospitals and apps.
Provider-to-provider exchange
Today, EHR-based APIs are mainly used for patient access and CDS, yet they also offer promise in the exchange of records among providers. Currently, when multiple providers care for one patient, if they share information at all, they often exchange full and unwieldy clinical documents that may contain decades of unnecessary data for treating that individual. This lack of care coordination can be especially detrimental for communities of color, where rates of screening for many diseases are lower than for White communities.12 Properly sharing the appropriate health data improves the delivery of preventative services.13
Interviewees identified several benefits to using APIs for care coordination. Through FHIR, health care providers could send individual—or modular—pieces of data to one another. For example, providers could send patients’ medication lists or their most recent care plans, instead of a broader document containing more data, some of which might be unnecessary or sensitive. Allowing providers to move away from sharing long documents to pulling out only the necessary information can reduce provider burden by making important data easier to find and use. This can also improve care coordination by making it easier for clinicians to communicate about a shared patient as well as protect privacy by exchanging the minimum necessary information.
"There’s nothing that precludes [provider-to-provider exchange] from recurring. We haven’t seen it in the wild … but at least in our implementation of our APIs, there’s really nothing that prevents that from occurring."Vendor quote
Yet despite those potential benefits, providers have not largely exchanged data with one another using FHIR-based APIs. Some hospitals noted resistance to exploring the use of FHIR-based approaches given challenges they are experiencing with current, non-API-related data exchange processes, such as when they send direct messages to other facilities. Interviewees mentioned difficulties sending information to more than one clinician simultaneously—for example, a specialist and a primary care doctor—and dealing with physicians who work in two or more locations. These challenges, which are unrelated to APIs, led to hesitation on implementing new methods of exchange before resolving issues with current processes.
When discussing provider-to-provider exchange, EHR developers confirmed that existing FHIR APIs could support this use case but stated that they have not implemented or integrated this functionality into workflows because of a lack of request from their customers: health care providers. One vendor discussed using an FHIR to send data to a national network that supports data exchange. Two prominent networks, CommonWell and Carequality, have started testing provider-to-provider exchange using FHIR APIs.14
Because few technical barriers to implementing APIs for provider exchange exist, once the recent ONC regulations are implemented, these tools can be leveraged for data exchange among clinicians with limited changes to the technology. The pilots from CommonWell and Carequality under development to enable provider communication via APIs will shed light on how quickly clinicians will see this use case in practice, and whether other changes, such as updates to workflows, are needed.
The regulations finalized in 2020 may increase provider-to-provider exchange via APIs, though only if this approach is demonstrated to be seamless and will offer benefits to clinicians, such as ease to better parse and locate the information they need.
Data exchange capabilities of APIs
Use of APIs to extract data from medical records could mark a turning point for interoperability. Yet, the vendor documentation exposed wide variability in what data is available across systems and what capabilities these tools have.
Entering data with write access unlocks API potential
For the most part, APIs in use today have only the ability to read—or extract—information from EHRs. However, some applications—such as decision support tools—may also be able to provide additional benefits to clinicians by entering, or writing, data into EHRs.
Although the majority of hospitals confirmed that they do not use write capabilities because of concerns around data provenance and a lack of awareness on whether the system they implemented has this capability, most interviewees described use of non-FHIR-based write access for administrative functions (such as patient appointment scheduling). One hospital employed write capabilities from proprietary APIs to capture data collected by Bluetooth-enabled devices (such as wearables like activity trackers). Other hospitals voiced a desire for increased write capabilities to push patient-reported outcomes data back into the EHR and for clinical risk calculation. Specifically, interviewees noted that there is a need for improved integration with third-party apps to collect self-reported patient data and the use of risk calculators to aggregate data and predict patient mortality or the occurrence of specific conditions (such as sepsis). For example, a patient using an activity tracker, taking multiple daily blood glucose readings, and weighing him- or herself once a week is generating a large amount of data. A third-party application using APIs may aggregate and use that data to make predictions and alert physicians to alarming trends.
"We’re using APIs for integration with Bluetooth-enabled patient wearables or scales, blood pressure cuffs, things like that to get data to help our care coordinators have an escalation process to address our high-risk patients."Hospital quote
Despite the additional benefits of write access, hospital executives raised concerns about offering apps the ability to document information in the EHR without also including the logic the software used to make that decision. For example, clinicians could use decision support tools to inform medication dosing; however, those tools would only document the medication dose and not explain the criteria or data used to reach that decision.
Hospital-based participants expressed the need for decision support to fit seamlessly into the clinicians’ workflow, without requiring them to proactively launch an application or enter a different screen to use the tool. Yet these steps often require clinicians to manually transfer data from an app to the EHR—reducing the likelihood of using CDS tools, introducing the opportunity for errors, and adding a burden for providers.
As the regulations implementing the Cures Act don’t require write access, those rules are unlikely to spur greater use of this capability.
Variability of EHR vendor API implementations
As of mid-2019, EHR developers inconsistently implemented FHIR APIs. Some vendors have invested heavily and made large swaths of information in their systems available to hospital clients, whereas others offer far less and lag behind their peers. As previously discussed, the federal government has required vendors to make only certain key data elements available.
To ensure the inclusion of all necessary data elements in this exchange, HL7 created FHIR Resources to bundle commonly exchanged data together. Apps can then request a single resource and be assured they will receive all the relevant data elements they need. For example, the Immunization FHIR includes data elements relevant to an immunization encounter: patient, vaccine given, and the administering practitioner, among others. HL7 develops these resources so that when third-party developers request information, such as whether a patient received a particular vaccine, they receive all the relevant data elements from the system.
This research was completed between June and October 2019, and it is likely that more resources have been made available in the intervening year. Since the completion of this research, ONC released the final regulations requiring additional data elements be made available for exchange, which will result in more vendors making additional resources available. APIs can be developed using FHIR, or with additional data elements. Various FHIR contain the USCDI data elements that are required for exchange. Although the federal government currently requires the availability of certain data elements via APIs, no corresponding requirement exists for FHIR. This discrepancy has resulted in variability in the FHIR made available across different vendors (see Table 3).
All nine vendors examined made six FHIR available for read access: AllergyIntolerance, Condition, Immunization, MedicationStatement, Observation (which includes vital signs and lab results), and Procedure. (Any two-word functions depicted in the report have been reprinted verbatim according to the style used by HL7 for FHIR.) Write access was much less prevalent, with only three vendors making any resources available for external providers to add to.
Table 3
Sum of FHIR Resource Availability of EHRs: Read vs. Write
Vendors with capability | Read total | Write total |
AllergyIntolerance | 9 | 2 |
Condition | 9 | 2 |
Immunization | 9 | 1 |
MedicationStatement | 9 | 2 |
Observation | 9 | 3 |
Procedure | 9 | 0 |
CarePlan | 8 | 0 |
Device | 8 | 0 |
DiagnosticReport | 8 | 0 |
Goal | 8 | 0 |
Patient | 8 | 1 |
MedicationOrder | 7 | 0 |
DocumentReference | 6 | 1 |
MedicationAdministration | 4 | 0 |
Encounter | 3 | 1 |
Medication | 3 | 0 |
MedicationRequest | 3 | 0 |
CareTeam | 2 | 0 |
Practice | 2 | 0 |
Appointment | 1 | 0 |
AssessPlan | 1 | 0 |
ClinicalImpression | 1 | 0 |
ClinicalProvider | 1 | 0 |
HistoricalVaccine | 1 | 0 |
MedicationDispense | 1 | 0 |
Person | 1 | 0 |
Problem | 1 | 0 |
ProcedureRequest | 1 | 0 |
Provider | 1 | 0 |
RelatedPerson | 1 | 0 |
ResultObservation | 1 | 0 |
Some EHR developers offered a wide range of FHIR, whereas others offered very few (see Table 4). EHR developers offered between nine and 20 FHIR for read access, while most vendors do not offer any write capabilities. Only three vendors offer write access, though only one resource was similar across them (Observation, which includes vital signs such as blood pressure and temperature, lab data such as blood glucose, and device measurements, such as EKG data).15 Vendors typically differ on the FHIR they offer because they may not have these capabilities in development plans, clients may not request these features, or vendors lack staff available for interoperability efforts that aren’t required by federal regulations. In addition, some vendors were early adopters of FHIR, whereas others waited for the standard to gain broader use.
Table 4
FHIR by Vendor: Read and Write Capabilities
FHIR capability | Vendor 1 | Vendor 2 | Vendor 3 | Vendor 4 | ||||
Read | Write | Read | Write | Read | Write | Read | Write | |
AllergyIntolerance | X | X | X | X | ||||
Appointment | X | |||||||
CarePlan | X | X | X | X | ||||
CareTeam | X | X | ||||||
ClinicalImpression | X | |||||||
Condition | X | X | X | X | X | |||
Device | X | X | X | X | ||||
DiagnosticReport | X | X | X | X | ||||
DocumentReference | X | X | X | X | ||||
Encounter | X | X | X | |||||
Goal | X | X | X | X | ||||
Immunization | X | X | X | X | ||||
Medication | X | |||||||
MedicationAdministration | X | X | X | |||||
MedicationDispense | X | |||||||
MedicationOrder | X | X | X | |||||
MedicationRequest | X | |||||||
MedicationStatement | X | X | X | X | X | |||
Observation | X | X | X | X | X | |||
Patient | X | X | X | X | ||||
Person | ||||||||
Procedure | X | X | X | X | ||||
ProcedureRequest | X | |||||||
Provider | X | |||||||
RelatedPerson | X | |||||||
Total | 13 | 0 | 20 | 0 | 17 | 5 | 15 | 0 |
FHIR capability | Vendor 5 | Vendor 6 | Vendor 7 | Vendor 8 | Vendor 9 | |||||
Read | Write | Read | Write | Read | Write | Read | Write | Read | Write | |
AllergyIntolerance | X | X | X | X | X | X | ||||
Appointment | ||||||||||
CarePlan | X | X | X | X | ||||||
CareTeam | ||||||||||
ClinicalImpression | ||||||||||
Condition | X | X | X | X | X | X | ||||
Device | X | X | X | X | ||||||
DiagnosticReport | X | X | X | X | ||||||
DocumentReference | X | X | X | |||||||
Encounter | X | |||||||||
Goal | X | X | X | X | ||||||
Immunization | X | X | X | X | X | X | ||||
Medication | X | X | ||||||||
MedicationAdministration | X | |||||||||
MedicationDispense | ||||||||||
MedicationOrder | X | X | X | X | ||||||
MedicationRequest | X | X | ||||||||
MedicationStatement | X | X | X | X | X | X | ||||
Observation | X | X | X | X | X | X | X | |||
Patient | X | X | X | X | X | |||||
Person | X | |||||||||
Procedure | X | X | X | X | X | |||||
ProcedureRequest | ||||||||||
Provider | ||||||||||
RelatedPerson | ||||||||||
Total | 15 | 3 | 14 | 5 | 11 | 0 | 13 | 0 | 10 | 0 |
Interviews with both EHR developers and health care providers revealed a disconnect between clinicians’ needs compared to vendors’ offerings. Some hospital representatives said that they did not have certain functions available in the EHR, but when the research team examined the EHR developer documentation, they found those functions were in the system. Other hospital interviewees noted their impression that EHR developers are not providing the most up-to-date functionalities (such as updating to the most recent version of FHIR, which is akin to providing a software update) in a timely manner. In some cases, the disconnect between hospital executive perceptions and EHR functionality occurred because of poor communication between developers and health care providers.
Terms of use affect API feasibility for hospitals
In addition to technical capabilities as factors that influence the availability and utility of APIs, the costs and terms that govern the business relationships between third-party app developers, EHR vendors, and hospitals can also affect the use of these tools.
Costs associated with APIs can add up quickly
Cost for use of APIs and their connected applications varied by vendor and application type. Costs can be incurred in a number of ways, such as implementation fees, maintenance fees, and call rates, which are charges that occur every time an API is used to access data. The documentation from EHR developers often lacked robust cost information, although several interviewees indicated that they believe their fees fell within normal market ranges without providing details. The absence of clear cost information can make budgeting difficult for hospitals.
Third-party developers can create applications that use APIs and partner with EHR vendors—for example, via placement in the relevant EHR vendor marketplace, which functions much like a smartphone app store—to deploy those tools to hospitals and other care settings. In general, the health care facility pays a third-party app developer for the use of its program, while the application developer pays fees to the EHR vendor for integration with its system. Vendors and hospitals can also create their own apps internally, though few health care facilities indicated that they have this capability. The hospitals that were developing their apps tended to be larger academic medical centers with many resources, whereas smaller facilities did not have the capacity to develop tools internally and instead relied on their vendors for APIs.
Annual fees, which are paid by application vendors, were typically listed as approximately $10,000 across EHRs, though costs varied. One vendor charged an annual fee of $12,000 for validation of an app, while another had a $2,500 annual fee.
All vendors offered patient access APIs at no cost because federal regulations require it. One vendor specified in its developer documentation that use of FHIR APIs for applications authorized by patients using their portal credentials is included in the licensing fees and does not require a separate agreement or cost. However, APIs for provider-facing applications, such as CDS, have associated implementation and maintenance fees. These costs may become prohibitive to implementing CDS tools that could improve patient care and provider workflows, especially because clinicians or hospital executives need to justify additional expenditures for these capabilities without necessarily having robust data to support the business case for implementation.
Costs for implementation often varied based on different levels of support from the EHR developer and partnerships, such as inclusion and promotion of the applications in the vendor app marketplaces. Costs from one vendor ranged from $1,000, which included little application vendor support, to $20,000, which included vendor promotion, site implementation assistance, private sandbox environments where developers can test applications with mock data, and trainings.
Aside from implementation and maintenance fees, some EHR vendors also charged third-party applications for each time they use the API, referred to as a “call” for clinician-facing applications. For one vendor that provided data, API call rates reached $0.75 per call. Many other vendors did not include call rates in their documentation. Fees for administrative apps (such as for scheduling that did not read the encounter or patient-level data) were lower than those that access the encounter or patient-level data. However, the volume of calls, and thus their overall impact and cost, could not be determined from this study. As API-based apps become more widely used in health care, vendor call-based fees may become cost prohibitive.
Several EHR developers also offered a revenue share cost model with the app developer based on the income generated from providers. A number of EHR vendors had a combination of both revenue share and call-based cost models. Percentage of revenue shared was not specified in all vendor documentation or interviews. One vendor specified a 15% revenue share for when the application developer could demonstrate that the fees from the standard program model exceeded 15% of gross revenue from the application, and therefore would allow application developers to pay the lesser amount.
Although the regulations implementing the Cures Act did not specify the amount of permissible costs, the rules generally restricted fees to reasonable amounts to recoup development and implementation resources needed by the EHR vendor. Given the variation in costs observed and lack of transparency, regulators in the future will need to ensure that the fee restrictions reflect the intent of the policies to minimize costs so that APIs can be used “without special effort,” which is a requirement for APIs spelled out in Cures.
Intellectual property
All EHR vendors interviewed indicated that they retain intellectual property of their API used by the application, while application developers retained the intellectual property of their applications. The intellectual property considerations were not included in all the vendors’ terms of service documentation for use of the developer portals, but this distinction was confirmed in interviews.
Despite the third-party application developers retaining their own intellectual property, one EHR vendor indicated that it builds functionality into its base product if many clients use a capability offered by a particular application. However, the code from the app developers’ product is not shared with the EHR vendor. Information about intellectual property rights of the data was not included in the documentation reviewed. For example, a number of hospitals may be using an app that automatically calculates medication dosage based on a patient’s weight. The EHR vendor may decide that, instead of allowing a third party to generate profits from that use, it will build the functionality directly into the EHR. To do that, the vendor does not access the original code, but builds its own internally.
App implementation
When discussing APIs and associated application rollout procedures at hospitals, several organizations noted a misconception that integration of APIs should be straightforward.
API-based applications are not “plug and play,” as one hospital stated; they are not as simple to install as a smartphone app. Hospital representatives stressed that the process requires extensive management oversight and coordination with and between the EHR vendor and third-party application developer. One hospital equated API integration to adoption of an advanced audiovisual system, emphasizing the large number of connections that need to come together for a CDS app rollout. Hospital participants emphasized that future API-based applications must be incorporated into the workflow, which requires resources, time, and planning on the part of the implementing health care organization.
"Integration with APIs technically should be a simple process, [but] in our experience requires a lot of hand-holding and a lot of back and forth discussion."Hospital quote
Hospitals described using external “concierge” or “consultant” services as one way to avoid misunderstandings when hospital staff interested in using API-based apps are reviewing their options. These consultants work as a go-between among third-party application developers, EHR vendors, and hospital staff to assist in identifying the best and most efficient approach to using APIs. These conversations often change the focus from requesting a specific API to determining what clinicians need to accomplish via the API.
This information is then used to determine if an API is appropriate, if the end goal can be achieved through a pre-existing API, or if a custom API is needed.
Future promise of APIs
Although EHR vendors and health care organizations identified initial promise of APIs, they noted that these technology tools will likely offer even greater benefits once advances in CDS workflow and write capabilities into EHRs take hold.
Clinical decision support tools offer major improvements to care
Vendors described APIs for CDS, both proprietary and FHIR-based, as an area for future investment to leverage the abundance of health care data that clinicians could use to aid decision-making.
Several EHR vendors discussed the future promise afforded by CDS Hooks, an emerging standard that helps integrate these tools into clinician workflow, to enhance the usability and utility of decision support software. CDS Hooks allows EHRs to integrate third-party tools directly within the clinical workflow of the medical record system. Certain provider actions trigger CDS Hooks, which starts an application automatically, as opposed to requiring the clinician to proactively open a decision support tool. The clinician can then use the application, which will record the decision made by the provider, directly in the EHR.
For example, researchers at the University of Utah have created BiliApp, a decision support tool to help manage newborn bilirubin levels. The app uses FHIR APIs (both from the EHR as well as ones it developed) to retrieve patient data and pass it to a CDS Hooks-based service. The service then analyzes the information and provides patient-specific recommendations through a user-facing application accessed directly in the EHR.16
As mentioned, regulations implementing the Cures Act will further accelerate the ability of providers to apply decision support tools, and therefore the marketplace for these aids will likely increase.
Write access is necessary for many use cases
Although there exists a dearth of write API functionalities, the potential of this capability to enhance clinical care, patient outcomes, population health, research, and analytics offers promise. Write capabilities can allow patients to contribute data directly into their records.
For example, patients could update their address, report that they are no longer taking a medication, or input new symptoms. Many decision support tools, including via CDS Hooks, would benefit from the ability for clinicians to write information or orders back into the record, rather than relying on the provider to do so manually.
As emphasized earlier, hospitals noted concerns about data written into the EHR and that hesitation has led developers not to roll out APIs with write capabilities. Providers worried that patient data, though useful, could include inaccuracies, whether from wearable devices, patient self-monitoring, or other external sources. Interviewees also raised concerns about the data provenance, or where the information originated, and whether patients should be allowed to amend their EHR data. After the research concluded, ONC released final regulations that added provenance to the USCDI, albeit for read access. Standardized implementation guides to support write capabilities may ease some of these concerns.
How can such practice impact your health? how? Why?
Share the wealth of health with your friends and family by sharing this article with 3 people today.
If this article was helpful to you, donate to the Shidonna Raven Garden and Cook E-Magazine Today. Thank you in advance.
Commenti