Onc-certified Ehr Program Clinical Design Support Tool

Overview

Technology has revolutionized the way people live their lives. Individuals can use smartphones to access their bank account, shop from almost any store, and connect with friends and family around the globe. In fact, these personal devices have tethered communities together during the coronavirus pandemic, allowing many people to maintain much of their lives remotely.

Yet when it comes to accessing and sharing their health information, hospitals and physician's offices can frequently ask patients to go through arduous, arcane steps, such as submitting forms using a fax machine or paying fees to obtain their records, or they simply deny patients access to their own records. And health care organizations often don't seamlessly exchange data—a process known as interoperability—and instead require patients to serve as the intermediary, manually transferring their data from one place to another.

To address these challenges, health care can adapt the same technological approaches that have revolutionized other industries by incorporating digital tools called application programming interfaces (APIs). These tools allow personal finance websites to aggregate information from banks and credit card companies to provide consumers a complete picture of their spending habits, for example, or let travel services compare flights from multiple airlines without the user having to visit each airline's site individually. If standard APIs were broadly adopted in health care, patients could access and compile their data from multiple providers while clinicians could process complicated information and make care recommendations. APIs would also offer other benefits, such as facilitating the exchange of clinical data among health care providers.

This report will focus on three health care benefits of APIs:

• Patient access to data.
• The incorporation of clinical decision support (CDS) tools, such as risk calculators or apps that provide recommendations for prescribing antibiotics.
• Provider-to-provider exchange of information.

When patients have access to their records on a personal device via APIs, they can track and manage their health outside of the doctor's office or hospital. They can integrate their information in health apps on their smartphone to promote disease management, allowing them to digest information outside of a short clinical visit and track their health over time.

APIs can also help clinicians more effectively use patient data from electronic health records (EHRs) to make decisions. Health care providers can integrate some applications into the EHR to offer a broad range of these CDS tools, giving clinicians the opportunity to pick the functions that work best for them. However, these tools may introduce bias into care, such as if an application analyzing potential pictures of skin cancer is tested primarily on light-skinned patients.

And when two providers, such as a primary care physician and a specialist, need to exchange information about a shared patient, they must frequently do so using full clinical documents, which can be hundreds of pages long and cause providers to struggle to find and extract relevant information. This situation contributes to clinician burden and often results in patients having multiple, incomplete records across different sites of care. APIs can allow providers to exchange only the information needed to inform care decisions and in a digital format, thereby mitigating the need to exchange full clinical documents. Improving the way providers communicate through standard APIs could advance care coordination, reduce unnecessary testing and procedures, and save money. Despite the potential for improving provider exchange, APIs have not been broadly implemented in health care.

However, APIs can't be broadly adopted if technology developers implement them in proprietary ways so that they work with only one EHR and apps have to be coded differently for each system with which APIs interact. But standards—such as the industry-developed Fast Healthcare Interoperability Resources (FHIR), which is a standard for exchanging health care information electronically—ensure easier use of APIs. FHIR can offer access to individual pieces of information—such as a list of medications—instead of a broader document containing more data, some of which might be unnecessary or patients may not wish to share.

Another issue is that although most APIs can only read information from EHRs, several opportunities exist to promote the ability to input information back into electronic records, known as write access functions. This action would allow CDS tools to offer additional capabilities and benefits to clinicians and enable patients to contribute to their own records, by changing an address, updating symptoms, or correcting errors.

Federal regulations finalized in 2020 require the use of FHIR and expand the dataset that must be available for exchange via APIs, but the rules did not address write access. Those regulations are scheduled to take effect in 2022. Although these regulations are critical, they do not mitigate the need for significant additional policy and technology developments in order to successfully integrate and prioritize APIs within health care. Policymakers can take additional measures to promote the use of APIs and incentivize new capabilities through both legislation and additional regulation.

Despite these policy advances, outstanding questions remain on the current capabilities of APIs, the gap that the new regulations will fill, and additional barriers to more widespread use of these tools to improve data exchange. Obtaining a snapshot of the current state of the industry can both provide a benchmark to measure whether policies successfully improve use of APIs and to identify opportunities where additional policies are needed.

To evaluate the current and near-future uses of APIs, The Pew Charitable Trusts collaborated with RTI International, an independent, nonprofit research institute, to analyze publicly available EHR vendor documentation to understand their terms of service and the data made available via their FHIR APIs by each product developer. Additionally, the research included structured interviews conducted between June and October 2019 with high-level staff from EHR vendors, hospitals around the country, and other experts.

The research revealed:

• Use cases. Of the three use cases examined (patient access, clinical decision support, and provider-to-provider exchange), hospitals most frequently implemented APIs for patient access and clinical decision support. APIs have not yet appeared significantly for other uses, such as data exchange among health care providers treating the same patient.
• Data exchange capabilities. Vendors vary significantly on the data elements they permit for exchange via APIs built on the FHIR standard. This disparity significantly affects the amount of information that can be exchanged via APIs, as does lack of write access.
• Terms of use. The agreements that govern the relationships between care providers, EHR vendors, and third-party application developers in the use of APIs can dictate costs, who retains the intellectual property of the application and API, and how apps are developed and deployed. In the EHR documentation reviewed, many of the terms and conditions lacked critical details, including on costs.
• Future promise. Interviewees identified three areas as critical future opportunities to improve the use of APIs in health care settings: enabling their use to enter data into EHRs and not just extract information, incorporating applications more seamlessly into clinicians' workflow, and adding more standard data elements, such as images or cost information.

These findings provide insights that can inform policymakers as they consider accelerating both patient access to their medical information and more effective use and sharing of data by health care providers. As APIs become more integrated into EHRs, policymakers should focus on policies that:

• Improve privacy and security.
• Build out the ability to enter data into records.
• Increase API use for data exchange among providers.
• Include more data elements for exchange.
• Monitor costs.
• Guard against health inequities with CDS tools.

Building the case for APIs

APIs are the backbone of the modern internet, seamlessly connecting different software programs into a unified view. These tools have made other industries operate more efficiently, yet standard APIs have not been widely implemented for use in hospitals and by health care providers.

The federal government has recognized the utility of APIs within the health care ecosystem and has taken several steps to encourage their use. In 2015, the Office of the National Coordinator for Health Information Technology (ONC) first required the use of APIs in certified EHRs. The Centers for Medicare & Medicaid Services (CMS), in turn, required health care providers to use products certified to those requirements or receive reduced payment from the federal government. To ensure these certified EHRs advance interoperability, in 2016, Congress passed the 21st Century Cures Act (known as Cures), which further required ONC to update its policies to make more information available to exchange via APIs "without special effort."

In 2015, ONC also required certified EHRs to make a subset of data, called the Common Clinical Data Set (CCDS), available for patient access through an API—albeit not necessarily a standard one—or portal. The CCDS contains critical health information, such as medication lists and vital signs, that the federal government identified as essential. However, this requirement applied only to patient access, not other use cases such as provider exchange or decision support. The 2015 rules required EHRs to allow patient access to their health information at no cost. The regulations also allowed vendors to use proprietary APIs, rather than ones built on common standards that make it easier for systems to communicate.

A year later, Congress built upon the 2015 requirements by passing the Cures Act, which tasked ONC to ensure that EHRs make "all data elements" in health records available via APIs. That requirement also stated that all EHR vendors must provide documentation for third parties, such as software developers of apps that can be synced into the health record system, to understand how to access information in the record. In May 2020, ONC formally finalized the regulations implementing these provisions, including by defining "without special effort" by indicating that use of proprietary standards or high fees would constitute "special effort"; as a result, the rules mandated use of national, nonproprietary standards and restricted fees. In those rules, ONC expanded the dataset available to patients and renamed it the United States Core Data for Interoperability (USCDI). This set of information contains all data in the CCDS and adds additional important information such as clinical notes and expanded patient demographics.

Contrary to the 2015 provisions, these new regulations do not place any restrictions on the use case, freeing APIs to be leveraged beyond patient access to offer additional benefits such as clinical decision support (CDS) tools and provider exchange. In addition, these regulations require use of the most recent version of FHIR (at date of publication) and the associated implementation guides. These guides, which were developed by Health Level Seven International (HL7), reduce variation in how FHIR can be used to ease integration and data sharing.¹ Finally, ONC placed some restrictions on fees and maintained that APIs for patient access to their data must remain free. These final regulations are scheduled to be fully implemented two years after finalization, in late 2022, after a delay due to the COVID-19 pandemic.

In this period of technological advancement in health care, Pew sought to understand what API usage looks like in practice, what progress has been made based on recent policy changes, what gaps exist, what hospitals and vendors envision for the future, and the actions that can advance the use of APIs.

FHIR: A National Standard Critical for Effective APIs

The Fast Healthcare Interoperability Resources (FHIR) standard allows different systems access to modular—or individual—pieces of data and provides more flexibility to obtain only relevant information through an API, such as a medication list or recent diagnosis. For example, apps on patients' smartphones can use FHIR to request and receive a list of allergies without accessing any other data. Federal regulations have increasingly referenced FHIR as a requirement for data exchange. The nonprofit Health Level Seven International maintains the FHIR standard.

Methodology

To understand how hospitals and vendors use APIs, Pew collaborated with RTI to analyze vendor documentation and conduct structured interviews with leadership at health care facilities (such as the chief medical information officer, chief of information services, chief health information officer, and EHR implementation leaders), EHR developer representatives, and other subject matter experts. Interviews were conducted between June and October 2019.

Literature and documentation review

An environmental scan—the process of seeking, gathering, interpreting, and using information from a wide range of sources—compiled peer-reviewed and gray literature (research developed by organizations outside of the traditional academic publishing and distribution channels), federal regulations, and EHR developer documentation. Initial search terms included health care, application programming interfaces, hospital, acute care, inpatient, outpatient, electronic health record, electronic medical record (EMR), electronic health information, exchange of patient data, interoperability, developer, EHR vendor, EMR vendor, and health information technology (health IT). Search criteria were further refined by limiting articles to English with a publication date between 2012 and 2019. Staff used PubMed, Embase, Web of Science, and the Cumulative Index to Nursing and Allied Health Literature to search databases.

Through the initial search parameters, researchers identified 51 articles. A review of the article abstracts refined the search to 21 by eliminating articles that had no relevance to APIs, had an international focus, or were too focused on a specific industry or initiative (such as genetics, blockchain, or IT security). By reviewing key references from the initial set of identified articles on a rolling basis, researchers were able to identify seven additional journal articles; they used the same methodology to review 35 different sources to identify relevant gray literature. Finally, researchers reviewed blogs, technical reports, and key federal rules/regulations pertaining to the use of APIs in health care.

They then reviewed API documentation from EHR developers to also identify costs, applicable terms of service, and the data available by each vendor. To identify the 10 largest vendors for inpatient settings, researchers examined participation in a federal program—often referred to as the EHR Incentive Program and currently called Promoting Interoperability—to require use of EHRs in certain ways. This program covers the vast majority (more than 95%) of the market. Researchers made further revisions based on mergers and acquisitions and involvement in the Argonaut project, which is a private sector-led effort to create guidelines for how organizations can use FHIR to transmit information in a consistent way.² If required, researchers created developer accounts to access documentation that was not publicly available.

Interviews of key hospital and vendor experts

The findings from the environmental scan informed discussions with EHR developers and health care providers. Researchers developed an interview guide, focused on different API use cases (patient access, CDS, and provider exchange), barriers to their utilization, and future goals. RTI project staff used NVivo software to analyze interview notes. Table 1 depicts the topics covered in interviews.

Table 1

Discussion Topics for API Interviews

Topics	Use	Question categories
Hospital discussion topics	Current use of APIs	Current use of APIs to extract data from the EHR (read capability) Current use of APIs to enter data into the EHR (write capability) Process for integrating and developing APIs Making apps available to patients and providers
	Future use of APIs	Desirable API capabilities not currently able to use Required API characteristics to support effective use Expanding resources to further use of third-party apps Government role to advance API use Features and use of APIs in other industries
Vendor discussion topics	Current use of APIs	APIs offered today Technical requirements to access APIs Terms of service
	Future use of APIs	Future use of APIs Potential for apps and APIs to further health IT objectives Investments in API functionality Hospital requests that are not currently feasible Business model to provide access to and development of APIs Government role to advance API use

Source: Interviews with RTI International, June 17-Oct. 7 2019

Hospital and developer recruitment for interviews

Researchers identified 60 hospitals for recruitment, equally stratified according to size (small, medium, and large) and setting (urban and rural). Size categories were developed by using the rural/urban bed size categories as defined by the Agency for Healthcare Research and Quality and the U.S. Census Bureau's urban/ rural designations for counties: fewer than 100 beds for small; 100-300 beds for medium; and more than 300 beds for large.³ Researchers contacted desired hospitals via phone calls and email communication throughout the recruitment period (June 17, 2019 to October 7, 2019) and added further hospitals on a rolling basis via recommendations from professional organizations and through existing professional networks. The final sample consisted of 11 hospitals, some of which represented health care systems with multiple facilities of varying sizes and some of which were standalone facilities. Table 2 displays a de-identified overview of the participating hospitals delineated by size, location, and number of member hospitals.

Table 2

Hospitals Recruited for Interviews

Hospital No.	Location	Rural/Urban	Small	Medium	Large	Type of Organization
1	Midwest	Rural			X	System with 10 hospitals
2	South	Urban			X	System with 1-5 hospitals
3	South	Urban			X	System with 6-10 hospitals
4	South	Urban			X	System with 1-5 hospitals
5	East	Rural	X	X		System with 1-5 hospitals
6	Mid-Atlantic	Rural	X	X		System with 10 hospitals
7	West	Urban/rural	X	X	X	System with 10 hospitals
8	East	Urban		X		System with 1-5 hospitals
9	West	Rural	X	X		System with 1-5 hospitals
10	South	Rural	X			Standalone
11	Midwest	Urban		X		Standalone

Source: Interviews with RTI International, June 17-Oct. 7, 2019

To recruit EHR vendors, researchers examined the list of the nine largest vendors in both hospital and ambulatory health care markets, based on participation in CMS' EHR-related payment policies. Outreach to EHR vendors occurred during the same recruitment period applied to hospitals (June 17, 2019 to Oct. 7, 2019). Researchers obtained vendor contact information from corporate websites, participation in the Argonaut project, professional contacts, and networking at conferences during the recruitment process. The final interview sample size consisted of five of the nine EHR vendors. In addition, interviews included one organization developing health care-focused patient-facing applications for the additional perspective of developing and integrating with EHRs.

There are other issues that cut across care that this research did not delve into, such as patient identity matching, usability of individual apps, or business models to support use of APIs.

As with all qualitative research, the format of this study emphasizes the experiences and knowledge of the participants and should not be generalized to all health care providers and EHR vendors. However, researchers chose interview participants who could provide different perspectives, and their experiences can give insight to observed trends and inform future policymaking.

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.⁴ 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.⁵ 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.⁶ 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.⁷

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.⁸ 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.⁹

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.¹⁰

Several reasons exist for slow patient uptake, including access challenges, clunky technology, and poor marketing.¹¹ 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.¹² Properly sharing the appropriate health data improves the delivery of preventative services.¹³

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.¹⁴

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).¹⁵ 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.¹⁶

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.

Policymakers can further accelerate and improve API use

Congress, CMS, and ONC have accelerated some uses for APIs, including patient access. The ONC regulations requiring FHIR, associated implementation guides, and additional standardized data will aid the implementation of APIs in health care. However, these new rules should not be the final effort on APIs. Given the expected increased use of these tools and their future promise, gaps that policymakers should address include privacy, write capabilities, data exchange among providers, and costs.

Although some changes may require Congress to pass new legislation, ONC and CMS could also accelerate additional use cases and their related benefits through policymaking. For example, Congress required ONC to develop the Trusted Exchange Framework and Common Agreement (TEFCA), a program created through the Cures Act to support nationwide data exchange. Similarly, CMS maintains the Promoting Interoperability Programs, through which the agency offers financial incentives for hospitals to use technology in ways that improve patient care. And the private sector—including app developers and EHR vendors—can also take steps to advance the use of third-party applications integrated within EHRs and ensure provider access to data at the point of care and within workflows.

"We want those apps to have the same privacy and security standards that we have."

Hospital quote

To further accelerate API use, policymakers should consider regulations, legislation, or other policies that:

• Improve privacy and security. Given provider concerns about unauthorized access to patient data and the effect of this hesitation on offering consumer and patient-facing applications access to patient data via APIs, policymakers should prioritize solutions for privacy and security gaps. Congress, ONC, other offices within the Department of Health and Human Services, the Federal Trade Commission (which has jurisdiction when companies violate their own terms and conditions), state attorneys general, and other policymakers should ensure that third-party applications both provide information about and confirm adherence to disclosures on how they use data and respect patient preferences. Given concerns that consumers do not often review terms and conditions of software applications, which are often designed to be difficult to understand, policymakers should ensure that appropriate privacy and security safeguards are in place and that consumers can understand and make meaningful choices about how their data is used.

  Meanwhile, technology developers and health care providers should commit to disclose how they use data and make certain that patients are able to meaningfully understand and agree to policies governing their data. Emerging industry-led codes of conduct—such as one developed by the CARIN Alliance, a multisector coalition that advances patient access to data—can provide guidance on best practices.¹⁷

• Build out the ability to enter data into records. Although currently most APIs can only read information from EHRs, several opportunities remain to promote write access functions—both for CDS to offer additional capabilities and benefits to clinicians and to enable patients to contribute to their records, such as changing an address or updating symptoms.

  First, health stakeholders—including EHR vendors—should develop and refine write access implementation guidance to address, among other things, how to record the provenance of information. Once developed, ONC should consider expanding its requirements for EHR certification to include write access. ONC could build on its existing provisions for read access APIs and focus on the USCDI. CMS can also advance this approach through its Promoting Interoperability Programs.

• Increase API use for data exchange among providers. Although government policies have prioritized patient access to data, vendor participants noted there are few technical barriers to using FHIR APIs for provider exchange. To more effectively and efficiently treat patients, hospitals and health care providers should be able to both retrieve the relevant data from their own copies of patients' records and access information stored in other providers' EHRs. Standard APIs have the potential to improve how providers connect via APIs to hospitals and other ambulatory sites where they share patients.

  New pilots for evaluating enhanced data sharing among clinicians could offer insights on the benefits and potential challenges of using FHIR for cross-provider data exchange. Benefits include, for example, ensuring that clinicians receive only the information they need—both reducing the quantity of data reviewed and preserving privacy.

  Going forward, federal agencies should encourage the use of APIs for cross-provider data exchange. For example, ONC can incorporate this method for data exchange in TEFCA, and CMS could tie provider interoperability to reimbursement. Other use cases should be explored, including APIs for population health, public health, clinical care delivery, analytics, and reporting.

• Include more data elements for exchange. ONC has already taken steps to add more data to APIs by expanding the information made available in the USCDI. However, Congress required that EHRs make "all data elements" available via APIs, and some notable gaps remain. For example, the USCDI does not currently include images, genomic data, social determinants of health, cost information, and other, more granular, information.

  More data will give patients a comprehensive view of their health, enable the development of additional decision support tools (such as those that analyze images or genomic data), and ease communication between providers. Additional data accessibility via the USCDI and APIs will also benefit providers and other stakeholders. ONC has indicated plans to expand USCDI regularly and cyclically and should aggressively act to expand the available data elements.¹⁸

• Monitor costs. In the Cures Act, Congress instructed the Department of Health and Human Services, the agency that oversees both ONC and CMS, to ensure that EHR-based APIs can be used "without special effort." In implementing that requirement, ONC indicated that exorbitant costs would represent special effort. Therefore, the agency determined that, aside from patient access APIs that must remain free to use, EHR vendors can only charge reasonable fees to generally recoup their expenses. ONC did not require technology developers to follow specific cost structures, such as through call-based or tiered systems.

  To ensure that API use remains affordable and accessible without special effort, ONC should aggressively monitor costs charged for their use and take appropriate enforcement actions in the event that EHR developers violate the regulatory provisions. As EHR developers make the USCDI available via FHIR-based APIs, ONC should also issue sub-regulatory clarification based on real-world examples of cost structures. Additionally, ONC should work with researchers to generate anticipated reasonable costs based on those charged in other industries that use APIs.

• Guard against health inequities with CDS tools. ONC regulations will usher in a new era for CDS that use APIs, which will increasingly help guide medical decisions on medications, treatment plans, and a range of other interventions. However, some decision support tools may exacerbate or fail to address inequities in care, increasing disparities for disadvantaged populations. For example, researchers have questioned whether forthcoming CDS tools for melanoma will appropriately support diagnoses for patients of varying skin complexions.¹⁹ The federal government, health care providers, and the industry should monitor the creation of CDS tools to ensure they are developed with data on diverse populations and do not increase disparities once deployed.

In addition, FHIR-based APIs may also offer promise in improving the public health infrastructure, such as in responding to future pandemics by making data exchange easier with state and local health departments to obviate the need for faxes. This research occurred prior to the novel coronavirus pandemic of 2020, and therefore that issue was not explicitly investigated or proactively raised by interviewees.

Conclusion

Increased use of APIs—particularly those based on common adopted and consistently deployed standards—has the potential to make health care more efficient, lead to better care coordination, and give providers and patients additional tools to access information and ensure high-quality, efficient, safe, and value-based care. Yet obstacles remain, such as some hospital hesitation to grant patient access to data, lack of bidirectional data exchange, confusion around the process of implementing APIs, and potentially prohibitive fee structures.

Despite that hesitation, recent rule-making will further integrate APIs into health care. With that, clinicians and patients alike can have access to comprehensive data and use third-party applications to aggregate information, make better decisions, and manage care more effectively.

Endnotes

1. HL7 International, "FHIR Specification (V3.0.2: STU 3)," Oct. 24, 2019, http://hl7.org/fhir/STU3/summary.html.
2. HL7 International, "FHIR Specification (V0.4.0: DSTU 2 Draft) - 2.14.1 the Argonaut Project," Feb. 23, 2015, https://hl7.org/implement/standards/fhir/2015Jan/argonauts.html.
3. W. Tian, "An All-Payer View of Hospital Discharge to Postacute Care, 2013: Statistical Brief # 205," inHealthcare Cost and Utilization Project (HCUP) Statistical Briefs, (Rockville, Maryland: Agency for Healthcare Research and Quality, 2016), https://pubmed.ncbi.nlm.nih.gov/27441335/; U.S. Census Bureau, "2017 FIPS Codes," accessed May 24, 2018, https://www.census.gov/geographies/referencefiles/2017/demo/popest/2017-fips.html.
4. U.S. Department of Health and Human Services, "Individuals' Right Under HIPAA to Access Their Health Information 45 CFR § 164.524," last modified Jan. 31, 2020, https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.
5. Centers for Medicare & Medicaid Services, "Certified EHR Technology," last modified April 5, 2020, https://www.cms.gov/Regulationsand-Guidance/Legislation/EHRIncentivePrograms/Certification.
6. J. Walker et al., "Open Notes After 7 Years: Patient Experiences With Ongoing Access to Their Clinicians' Outpatient Visit Notes,"Journal of Medical Internet Research21, no. 5 (2019): e13876, https://doi.org/10.2196/13876.
7. Apple Inc., "Institutions That Support Health Records on iPhone and iPod Touch," Oct. 8, 2020, https://support.apple.com/en-us/HT208647.; Ibid.
8. S.C. Lin et al., "Are Patients Electronically Accessing Their Medical Records? Evidence From National Hospital Data,"Health Affairs38, no. 11 (2019), https://www.healthaffairs.org/doi/full/10.1377/hlthaff.2018.05437.
9. V. Patel and C. Johnson, "ONC Data Brief No. 40: Individuals' Use of Online Medical Records and Technology for Health Needs" (The Office of the National Coordinator for Health Information Technology, 2018), https://www.healthit.gov/sites/default/files/page/201803/HINTS-2017-Consumer-Data-Brief-3.21.18.pdf.
10. A. Neinstein et al., "Deploying Patient-Facing Application Programming Interfaces: Thematic Analysis of Health System Experiences,"JMIR Publications 22, no. 4 (2020), https://www.jmir.org/2020/4/e16813/.
11. G.A. Wildenbos et al., "Older Adults Using a Patient Portal: Registration and Experiences, One Year After Implementation,"SAGE Journals4 (2018), https://journals.sagepub.com/doi/full/10.1177/2055207618797883.
12. J.K. Bower et al., "Racial/Ethnic Differences in Diabetes Screening and Hyperglycemia Among U.S. Women After Gestational Diabetes,"Preventing Chronic Disease 16 (2019): 190144, http://dx.doi.org/10.5888/pcd16.190144; D.A.C. Wallace et al., "Black White Disparities in Receiving a Physician Recommendation for Colorectal Cancer Screening and Reasons for Not Undergoing Screening,"Journal of Health Care for the Poor and Underserved24, no. 3 (2013): 1115-24, https://dx.doi.org/10.1353%2Fhpu.2013.0132.
13. S.I. Pitts et al., "Team-Based Health Information Exchange Use Increased Mammography Documentation and Referral in an Academic Primary Care Practice: An Interrupted Time Series,"Journal of General Internal Medicine33 (2018): 710–14, https://doi.org/10.1007/s11606-017-4259-8.
14. Care Quality, "Consumer-Directed Exchange," March 6, 2020, https://carequality.org/consumer-directed-exchange/;Commonwell Health Alliance, "Carequality Connectivity," Jan. 15, 2019, https://www.commonwellalliance.org/connect-to-the-network/carequality/.
15. HL7 International, "FHIR Specification (V4.0.1: R4 - Mixed Normative and STU)," Nov. 1, 2019, https://www.hl7.org/fhir/observation. html.; Ibid.
16. P. Kukhareva, senior clinical informaticist, University of Utah, "Biliapp: A Smart on FHIR App for Neonatal Bilirubin Management" (presentation, AMIA 2019 Annual Symposium, Washington, D.C., Nov. 19, 2019), https://symposium2019.zerista.com/event/ member/636493; Ibid.
17. Scientific Committee for Animal Nutrition—European Commission, "Report of the Scientific Committee for Animal Nutrition on the Efficacy and Risk for Users of the Therapeutic Macrolides Antibiotics Tylosin and Spiramycin Used as Feed Additives" (1998), https:// ec.europa.eu/food/sites/food/files/safety/docs/animal-feed_additives_rules_scan-old_report_out06.pdf; CARIN Alliance, "The CARIN Alliance Code of Conduct," accessed Jan. 29, 2020, https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct.
18. HealthIT.gov, "USCDI ONC New Data Element and Class Submission System Now Available," July 27, 2020, https://www.healthit.gov/buzz-blog/interoperability/uscdi-onc-new-data-element-and-class-submission-system-now-available.
19. R. McCullom, "Artificial Intelligence, Health Disparities, and COVID-19," Undark, July 27, 2020, https://undark.org/2020/07/27/aimedicine-racial-bias-covid-19/.

Onc-certified Ehr Program Clinical Design Support Tool

Source: https://www.pewtrusts.org/research-and-analysis/reports/2021/01/standard-technology-presents-opportunities-for-medical-record-data-extraction

Posted by: hookthonegive.blogspot.com

Share this post