Electronic Tools Can Strengthen Health Care Data Access, Sharing

Overview

Much of the internet used daily by millions of Americans is powered by tools that allow the transfer and use of data from many sources. Websites display numerous new tweets in real time, applications aggregate personal spending habits and investments, and widgets show the current weather. These tools, called application programming interfaces (APIs), enable easy and prompt access to data through algorithms so that information can be shared and used in creative ways.

Although APIs are common in web services like social media sites and online retailers, they are not broadly leveraged for exchanging data among electronic health records (EHRs) or providing patients with access to their information. Widespread adoption of APIs—coupled with increasing use of data formatting and nomenclature standards—could revolutionize how information is shared and free patients from hand-delivering their records to providers.

APIs in health care

Now that most hospitals and physicians’ offices have EHRs and are collecting health data such as medication lists and laboratory results electronically, APIs could help facilitate data exchange among health care facilities to give clinicians better information on patients’ health.¹ These tools could also allow individuals access to their medical records.² While APIs have been used in health care for some purposes, such as appointment scheduling, they are not widely employed for sharing data among facilities or with patients.

APIs work as bridges between two types of software. To find the cheapest flight from Chicago to Paris, for example, consumers can search each major airline’s website for available flights. A faster and easier way to do this for some people, however, is to search on a website that aggregates data from airlines using APIs, pulling together prices and flight availability to help consumers compare options.

A similar approach could be used in health care. Once software developers create programs that use data extracted from EHRs, patients and clinicians will be able to aggregate health information from many sources to better coordinate care, analyze appropriate treatment options, and maintain a complete and accurate medical history. APIs can allow more data to be accessed, enabling more effective aggregation of health information to provide clinicians and patients with better tools to support care.

In the past, APIs in health care were not based on commonly used standards, but rather were proprietary to each EHR system. The development of new open standards for how APIs could be built, coupled with recent government actions to spur their use, is ushering in a new era for these software interfaces that will promote the seamless exchange of information, known as interoperability.

Standards can enhance interoperability

APIs alone, however, are not enough to ensure interoperability. Exchange of data through APIs is a key next step, but sending and receiving systems also should use the same vocabularies—which are used to document complex clinical concepts in standard ways—for the information to have meaning.

Previous standards for exchanging health care data were most commonly used to send messages between hospital departments or full clinical documents, such as referral notes and care summaries, to outside parties. However, these standards often contribute to clinicians receiving too much unnecessary information along with what they need.

To address this, the standards development nonprofit Health Level Seven International created Fast Healthcare Interoperability Resources (FHIR).³ This standard allows developers access to modular—or individual—pieces of data and provides more flexibility to obtain only relevant information through an API. FHIR can still be used to exchange messages and clinical documents but now can also send just patients’ medication lists or only their most recent care plans. This precision enables users to extract only the information they need.

Although FHIR helps exchange data between EHR systems, it does have drawbacks: It does not require standardized vocabularies for medication names, diagnoses, lab test orders, and other key information, thus risking the ineffective communication of complex clinical data. That’s why major EHR vendors and several large hospital systems have formed the Argonaut Project, which is creating guidelines for how organizations can use FHIR to transmit information in a constrained and consistent way.⁴ Through a consensus-based process, the project has created guides on how to communicate—via FHIR—the common clinical data set (CCDS), which is the critical health information such as medication lists and vital signs that the federal government has identified as essential for exchange.

The Argonaut specifications—which have been the foundation for recent efforts to use APIs⁵— enhance interoperability by standardizing the terminologies hospitals use to describe clinical information, allowing communication between care facilities. For example, Argonaut guides could allow developers to use APIs to pull standardized data from multiple EHRs and create applications that seamlessly move and integrate data among systems, or use information from multiple sources to evaluate a patient’s risk for, say, diabetes or congestive heart failure.

Regulatory actions to promote APIs

The federal government has taken several steps in recent years to encourage the use of APIs to exchange data. The Office of the National Coordinator for Health Information Technology (ONC)—the federal agency that oversees EHRs—set a criterion in 2015 for electronic health records to make the CCDS available for patient access through an API.⁶ In effect, this requires EHRs to allow patients to use various applications—including on their smartphones—to download their health information. This requirement falls short, though. It requires access only to the CCDS and not to all critical data contained in EHRs; does not mandate the use of constrained vocabularies for all information like the Argonaut guidelines do; and omits other uses of APIs, such as to foster interoperability among health care providers.

In 2016, Congress advanced the use of APIs via the 21st Century Cures Act.⁷ This measure requires ONC to release new criteria for EHRs to make all data elements in health records available via APIs “without special effort,” which final regulations will define. EHR developers would need to make public the technical documentation that allows third parties to access and use data contained in the system. Often called open APIs, these tools have many purposes that support interoperability beyond transmitting data to patients, as the 2015 ONC regulations require.

In 2018, the Centers for Medicare & Medicaid Services (CMS) took another step toward promoting the use of APIs to support interoperability. It launched MyHealthEData, an initiative to give patients access to their health records, and has pursued payment policies to encourage hospitals to use EHRs that can make some data available via APIs so patients can view, download, and transmit their health information. Once implemented, patients could use smartphone applications, for example, to hold their health data in one location.⁸

Private sector support of APIs

As the federal government strives to expand the use of open APIs to encourage sharing health data, the private sector is moving forward on refining existing standards—through initiatives like the Argonaut Project—and developing new applications that enhance EHR functionality.

Many EHR vendors have created programs that allow third-party application developers to access their systems using APIs. Some vendors also provide testing tools, documentation, and other resources to help developers use APIs.

The SMART Health IT Project, an open source effort run by Harvard Medical School and Boston Children’s Hospital, seeks to support developers looking to create applications that run across multiple EHRs and health systems.⁹ These applications use the Argonaut implementations of FHIR so they can be installed on multiple EHRs without extensive customization. Additionally, they have created open source tools and a testing “sandbox” to assist developers and a gallery where users can find and try out SMART applications. Some of these applications are in clinical use at institutions such as Intermountain Healthcare and Duke University Health System, and could help clinicians adopt best practices faster.¹⁰

Next steps

Although Congress, federal agencies, and the private sector are taking actions to support the use of APIs to improve interoperability, several challenges remain that should be addressed to fulfill APIs’ promise. As EHR developers, health care facilities, clinicians, and government work together to advance effective API use and improve access to health data, they should consider how to:

• Make all relevant data, not just the CCDS, available via APIs.
• Ensure that information already coded in health data terminologies remains in that format during exchange and is not converted into formats that are more difficult to use, such as PDFs.
• Support efforts to further standardize data elements in the health record by encouraging use of existing terminologies and engaging in the development of new ones where codes don’t exist.
• Provide access to patients’ full health records—not just a limited number of years—held in each system so individuals with chronic illnesses and their care providers have a complete history of their condition.

Use of APIs to extract data from EHRs could mark a turning point for interoperability. Clinicians could gain access to more usable data from other institutions and use new clinical decision-support tools based on that information to better coordinate care. Additionally, patients could more easily obtain their data and use different approaches to aggregate and analyze the information to take ownership of their care. When implemented effectively and with appropriate standards like FHIR, APIs could propel health information technology forward by enabling the flow of useful, usable data.

Endnotes

1. Robert S. Huckman and Maya Uppaluru, “The Untapped Potential of Health Care APIs,” Harvard Business Review (Dec. 23, 2015), https://hbr.org/2015/12/the-untapped-potential-of-health-care-apis.
2. JaWanna Henry et al., “Adoption of Electronic Health Record Systems Among U.S. Non-Federal Acute Care Hospitals: 2008-2015,” ONC Data Brief 35 (2016), https://www.healthit.gov/sites/default/files/briefs/2015_hospital_adoption_db_v17.pdf
3. Health Level Seven International, “HL7 Fast Healthcare Interoperability Resources Specification (FHIR), DSTU Release 1,” accessed June 12, 2018, http://www.hl7.org/implement/standards/product_brief.cfm?product_id=343.
4. Health Level Seven International, “The Argonaut Project,” accessed June 12, 2016, https://hl7.org/implement/standards/fhir/2015Jan/argonauts.html.
5. Apple Inc., “Empower Your Patients With Health Records on iPhone,” accessed June 27, 2018, https://www.apple.com/healthcare/health-records.
6. 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications, 80 Fed. Reg. 62601 (Oct. 16, 2015), https://www.gpo.gov/fdsys/granule/FR-2015-10-16/2015-25597.
7. 21st Century Cures Act, Pub. L. No. 114-255, 130 Stat. 1033 (2016), https://www.congress.gov/114/plaws/publ255/PLAW-114publ255.pdf.
8. Centers for Medicare & Medicaid Services ,“Trump Administration Announces MyHealth E-Data Initiative at HIMSS18” (March 6, 2018), https://www.cms.gov/Newsroom/MediaReleaseDatabase/Fact-sheets/2018-Fact-sheets-items/2018-03-06.html; Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System and Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long Term Care Hospital Prospective Payment System and Policy Changes and Fiscal Year 2019 Rates; Quality Reporting Requirements for Specific Providers; Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs (Promoting Interoperability Programs) Requirements for Eligible Hospitals, Critical Access Hospitals, and Eligible Professionals; Medicare Cost Reporting Requirements; and Physician Certification and Recertification of Claims, 83 Fed. Reg. 41144 (Aug. 17, 2018), https://www.gpo.gov/fdsys/pkg/FR-2018-08-17/pdf/2018-16766.pdf.
9. SMART Health IT Project, “What Is SMART?” accessed June 12, 2018, https://smarthealthit.org/an-app-platform-for-healthcare/about.
10. SMART Health IT Project, “Who Is Using SMART?” accessed June 12, 2018, https://smarthealthit.org/an-app-platform-for-healthcare/who-is-using-smart.