Editor’s Note: In December, the authors published a primer on the information blocking final rule, which you can read at the Journal of AHIMA. It contains context useful for this article on apps and APIs.

By Debra Primeau, MA, RHIA, FAHIMA, and Jaime James, MHA, RHIA

Application programming interfaces (APIs) are among the fastest growing software technologies in the world, influencing the way we work and play in the real world, and interact with each other online.

Without leaping into a morass of technical jargon and acronyms, an API is software that bridges two or more applications, allowing data to flow irrespective of each application’s original design.

For apps designed to continuously pull data streams from multiple sources, APIs serve to decrease development time, save storage space on endpoint devices, and overcome differences in standards or programming languages among systems. The ability of APIs to optimize interoperability and manage information flow is one reason for the vitality and continued growth of the so-called app economy.

Examples of APIs in action include the Health (Apple) and CommonHealth (Android) apps for consumers, and the iBlueButton app for Medicare beneficiaries and veterans, all of which allows consumers to manage their own healthcare data. These apps use secure APIs to aggregate a patient’s health data across the continuum of care—including consumer-generated data from wearables and health apps—in one location.

Consumers are not the only beneficiaries of this interface software. APIs simplify healthcare delivery, making it easier for clinicians to exchange information with each other and patients. A pediatrician, for example, may use an application that is connected via the electronic health record’s (EHR) API to perform specific analytics on a given population and provide instant feedback that can then be shared with parents.

APIs will become even more essential as hospitals accelerate compliance with the Office of the National Coordinator (ONC) for Health IT’s information blocking provisions. These regulations, which go into effect in April as part of the 21st Century Cures Act (Cures Act), will enable consumers to easily store, aggregate, use, and share electronic health information (EHI) using apps of their choice.

Consumers will wield an unprecedented level of power over their own health information.

While these provisions will bring the healthcare industry closer to the long-awaited ideal of a patient-centered ecosystem, HIM professionals need to understand how this technology will impact the privacy, security, and accessibility of health information.

Familiarity with the opportunities and risks of using consumer-access APIs will help HIM professionals guide both providers and patients through uncharted waters.

The ‘Other’ Final Rule

Our December 2020 Journal of AHIMA article “Game Planning the Information Blocking Final Rule” explored the provisions of the ONC’s information blocking final rule.

The Centers for Medicare and Medicaid Services (CMS) published its own final rule—Interoperability and Patient Access—concurrent with the ONC provisions. (A useful fact sheet from CMS can be found here.)

The CMS final rule includes the use of APIs to expand data sharing and transparency among CMS-regulated payers, starting in January 2023:

  • Patient Access API: Medicare Advantage organizations, Medicaid fee-for-service (FFS) programs, and Medicaid managed care plans will be required to implement and maintain a secure, standards-based API that allows patients to easily access their claims and encounter information, including cost as well as a defined sub-set of their clinical information through third-party applications of their choice.
  • Provider Directory API: Payers will be required to make provider directories publicly available via a standards-based API. The intent is to help patients find providers for care and treatment, as well as help clinicians find other providers for care coordination, in the most user-friendly and intuitive ways possible.
  • Payer-to-Payer Data Exchange: Payers are required to exchange certain patient clinical data—specifically, the United States Core Data for Interoperability (USCDI) v 1 data set—at the patient’s request, allowing the patient to take their information with them as they move from payer to payer.
  • Admission, Discharge, and Transfer Event Notifications: Modification to the Conditions of Participation (CoP) requiring hospitals to send electronic patient event notifications of a patient’s admission, discharge, and/or transfer to another healthcare facility or provider.

The CMS final rule delivers on the promise to put patients first, giving them access to their health information when they need it most and in a way they can best use it. This rule finalizes new policies that give patients access to their health information and moves the healthcare system toward greater interoperability.

The FHIR Standard—And Why It Matters

As part of certification, IT developers must provide access to all data elements of a patient’s electronic medical record through an API (to the extent privacy laws allow) and this access, exchange, and use must be at both an individual and group patient level.

The Cures Act requires developers of certified health IT to publish APIs that allow health information to be accessed, exchanged, and used “without special effort.” The phrase “without special effort” means that APIs developed for healthcare are standardized, transparent, and competitive.

CMS and ONC have adopted a single standard as the best option to align the industry and enable widespread interoperability which is the Fast Healthcare Interoperability Resources (FHIR) Release 4. Initially developed in 2012 by standards development organization Health Level Seven International (HL7), FHIR is a response to market needs for faster and easier methods to exchange EHI.

As to how it works, FHIR creates a common set of APIs that allow EHI, including clinical and administrative data, to be available securely to authorized stakeholders for the benefit of a patient receiving care.

The exponential growth of EHI and the app economy created the need for clinicians and consumers to be able to share data in a lightweight, real-time fashion using modern internet technologies and standards. FHIR is based on internet standards widely used by industries outside of healthcare.

By adopting existing standards and technologies already familiar to software developers, FHIR significantly lowers the barriers of entry for new software developers to support healthcare needs.

Many healthcare applications already use FHIR. By May 1, 2022 (plus a three-month enforcement discretion), ONC mandates that HL7 FHIR API capabilities must be rolled out for certified health IT.

Governance Issues

Like any new technology, APIs present both opportunities and risks. Among health information management (HIM) professionals, there are many concerns regarding APIs, including security, privacy, and educating patients on how to safely manage their own data. All of these issues should be built into a multidisciplinary governance structure.

Broad considerations to include in a governance structure include:

Security. As vendors of certified health IT implement FHIR-based APIs over the next two years, they also will have to comply with security requirements, such as OAuth2, which is an industry-based authorization standard. This protocol, which is used by the banking and travel industries, enables certified health IT vendors to permit or deny an app secure access, as well as limit what data is being accessed. These requirements will help ensure access to health information through third-party apps is appropriate, secure, and at the direction of the patient.

Privacy. Most commercial third-party app developers will not be subject to HIPAA. Standards for handling data privacy and security, as well as rules for “good” app behavior, will need to be developed as part of API governance.

An app should request the minimum dataset required to perform its function with clear and accurate privacy policies to guide selection. According to HHS, an individual may request a provider to direct their EHR to a third-party app in an unsecure manner or through an unsecure channel (this may be more out of consumer convenience than anything nefarious).

In this circumstance, the provider would not be responsible for unauthorized access to an individual’s EHI while in transmission to the app. However, the provider should consider informing the consumer of the potential risks involved.

Patient Responsibility. To achieve a patient-centered ecosystem, patients must be informed consumers of healthcare. Unfortunately, most app user agreements are insufficient to adequately inform consumers of the responsibility they assume for their health data’s privacy and security.

Consumers are often unaware of the extent to which their health data is de-identified, sold, and otherwise reused without their consent. User agreements, which often appear in tiny fonts and include hard-to-decipher legalese, are not substitutes for robust patient information, advocacy, and education.

The HIM Role

HIM professionals are responsible for protecting the privacy and security of our patients’ information as well as the implications of APIs and apps as it pertains to information blocking. Although the choice to release EHI to an app belongs to the consumer, they will likely turn to providers for secure recommendations.

In addition to creating the governance structure, HIM professionals will play a significant role in ensuring the data is accurate and secure.

Patient Empowerment. Healthcare organizations need to strike a delicate balance between patient’s access to their information and the need to educate consumers about the risks of such control.

Patient education should be factually accurate, unbiased, and transparent. Patients should be educated on app privacy and security along with the privacy and/or security risks posed by the technology or the third-party developer. Education may come in the form of updating a provider’s privacy notice and/or placing information regarding the privacy and security “best practices” for third-party apps on the organization’s website or providing information as an app is requested.

Healthcare providers may consider establishing processes to notify patients whether an app developer has attested whether its privacy policy and security practices meet “best practices.” CMS provides minimum app privacy notice criteria and examples that may be accessed to assist in this. Healthcare providers may also want to begin to establish lists of apps that have been vetted to assist in facilitating the assessment of the app’s privacy and security practices.

Patients should be made aware of resources such as the CARIN Alliance Code of Conduct and the HHS Model Notices of Privacy Practices to help consumers and providers understand selection criteria for APIs and apps.

Healthcare organizations may want to consider implementing consent processes that explain the information collected and how it will and/or will not be used. Patients should understand how the provider will screen third parties with access to data for matching purposes, what security practices are followed, and if there are user-friendly methods to opt out of communications.

App Security. In addition to education, HIM professionals have a responsibility to ensure the apps that are being used to share data into their electronic health record (EHR) systems are safe and secure to protect their organizations from potential unintended consequences of breaches and hacking/ransomware.

There is also a responsibility to establish solid workflows to address patient requests for access to their electronic health information via third party apps that the organization may not connect with despite any risks noted regarding the app itself or the third-party developer. With the appropriate governance to ensure policies, procedures, and workflows are documented and implemented, these potential risks can be mitigated.

APIs allow people with the right authorization to access healthcare data efficiently and effectively. They will liberate the clinical and financial data from legacy silos and improve data interoperability and transparency—with the ultimate goal of improving health outcomes.

Access to health data via APIs does require additional considerations, privacy and security standards, and regulatory compliance needs. If properly managed through an information governance program, the benefits far outweigh the risks.

Innovating with APIs

Healthcare API-driven apps have endless potential to innovate with patient care and outcomes.

  • Long-Term Care. Apps and devices are being deployed by long-term care providers and senior living communities to mitigate residents’ social isolation and engage those with cognitive decline.
  • Consumer wearables and home care devices assist remote monitoring by a healthcare professional or caregiver and can be used to identify risks or trends that require interventions.
  • Remote Monitoring. Electronic transfer greatly assists in situations where the consumer and clinicians do not share the same physical location. For example, remote monitoring can be used for predicting fall risks, sleep cycles, and trends that suggest cognitive decline. Researchers and clinicians can study COVID-19 symptoms and treatments through devices that enable remote monitoring of oxygen saturation, blood pressure, temperature, and pulse rate.
  • Data Insights. Patients will eventually have access to both clinical and financial information that will assist them in making informed decisions about their healthcare. Health information will more easily be shared not only between providers to patients but between patients and providers and provider to provider.



Debra Primeau (dprimeau@primeauconsultinggroup.com) is president of Primeau Consulting Group.

Jaime James (jjames@mrview.com) is senior HIM consultant of legislative policy and compliance, MMRA.

Leave a comment

1 Comment

  1. Should we need to revise the ROI authorization forms in order to comply with the ONC Cures Act Final Rule?

Send a Comment

Your email address will not be published. Required fields are marked *