Interoperability rules sent patient data beyond HIPAA’s reach

The week

On March 9, 2020, the Department of Health and Human Services released two long-awaited final rules. The rule from the Office of the National Coordinator for Health Information Technology implemented provisions of the 21st Century Cures Act. It defined information blocking and its exceptions, and required certified health IT to support standardized application programming interfaces based on HL7 FHIR. The Interoperability and Patient Access rule from the Centers for Medicare & Medicaid Services required many payers in federal programs to give patients API access to their claims and some clinical data. Those payers included Medicare Advantage organizations, Medicaid and CHIP programs and certain exchange plans. The rules arrived as hospitals were turning to the pandemic, and were published in the Federal Register on May 1, 2020.

Most commentary on the March 2020 rules focused on interoperability: getting data to move between systems that had resisted it. For health system privacy, security and data leaders, the more consequential shift concerned where data ends up. The rules worked through three mechanisms: the duty not to block, standardized APIs as a front door, and, as a result of both, data leaving the HIPAA perimeter. Each needs a different response, and together they ask data leaders to govern flows they cannot refuse.

The duty not to block

Information blocking turned what had been a practical question, whether to release data, into a compliance question with defined exceptions. Information blocking covers access, exchange and use of electronic health information. Health care providers, certified health IT developers and health information networks and exchanges are all covered, with different knowledge standards and different consequences. Practices that had been routine, such as holding results until a clinician reviewed them, or requiring manual approval for requests from outside organizations, needed to fit an exception or change.

For a health system, compliance is mostly policy and workflow. The starting point is an inventory of the ways requests for data arrive: patient portal, release-of-information desk, health information exchange, payer requests, third-party apps, other providers. For each channel, the organization records its current delays and refusals and tests each against the exceptions.

Some results were uncomfortable. Delays built into EHR configuration for clinician convenience, such as holding certain lab or pathology results for days, needed a documented basis or removal. Refusals based on privacy, security or preventing harm carry specific conditions, so counsel should help write the criteria. The output is a short set of documented practices that staff can apply consistently, and a named owner who decides new cases.

Timing matters as much as refusal. A request answered slowly can amount to interference even if it is eventually fulfilled. Health systems should therefore measure turnaround by channel, such as days from request to release at the information desk, and investigate outliers. Those metrics also show where manual steps could be automated, which reduces both compliance risk and staff workload.

Standardized APIs as a front door

Certified EHR technology had to support FHIR-based APIs that let patients connect apps of their choice. Payers in CMS programs had to offer similar access to claims and clinical data. This changed the architecture of patient access. Instead of a portal controlled by the provider, there would be an API that any registered app could call once the patient authorized it.

An API is an access path like any other. It needs strong patient authentication, careful app registration, rate limits, monitoring for abnormal use and a process for revoking access. The rules limited a provider’s ability to refuse an app based on its own view of the app’s privacy practices. They did not remove the duty to secure the API itself, and security teams that had never watched the patient portal closely needed to treat it as a primary interface.

The same plumbing also works inbound. Standardized APIs and a defined data set, the United States Core Data for Interoperability, make it easier for a health system to pull data from other organizations as well as send it. Organizations that built one governed integration layer for both directions got more value from the investment and had fewer one-off interfaces to secure.

Data leaving the HIPAA perimeter

Once a patient directs data to a consumer app that is not a covered entity or business associate, HIPAA generally no longer applies to that copy. The app’s handling is governed instead by its own privacy policy, by the Federal Trade Commission’s authority over unfair and deceptive practices and by any applicable state laws. This was a deliberate choice to put patients in control. It also created a new kind of exposure for patients and a reputational question for providers.

Providers could not block an app simply because they disliked its privacy practices, but they could educate patients. That made patient communication a data protection control. The better approach explained, at the point of authorization, what an app could do with the data and how to revoke access, in plain language and without discouraging legitimate use.

Governance had to extend to flows the organization did not control. That means knowing which apps are connected, how much data each pulls and whether patterns change, and reporting those numbers to privacy and compliance leaders regularly. It also means clarity on who owns these decisions, because they sit between compliance, health information management, IT and clinical leadership. Without a named owner, each group assumes another is handling it.

Monitoring also creates its own obligation. If a health system sees an app pulling unusually large volumes, or many patients connecting the same unfamiliar app in a short period, it needs a playbook. That might include checking whether patient accounts were compromised, notifying affected patients, and reporting concerns about an app’s conduct to regulators. Deciding those steps in advance avoids improvising them under pressure.

With hindsight

The pandemic delayed the timelines. ONC moved the information blocking applicability date to April 2021, and CMS delayed enforcement of parts of its rule. Enforcement then developed in stages: the HHS Office of Inspector General finalized civil money penalties for developers and networks in 2023, and HHS finalized disincentives for providers in 2024. The Trusted Exchange Framework and Common Agreement began operating at the end of 2023, adding a national network layer. CMS’s 2024 interoperability and prior authorization rule extended API requirements to provider access, payer-to-payer exchange and prior authorization.

Concern about data outside HIPAA also grew. The FTC brought its first Health Breach Notification Rule case, against GoodRx, in 2023 and updated the rule in 2024 to make clear it covers health apps. Patient API access is now routine across certified EHRs and many payers, while the protection gap the 2020 rules opened remains only partly closed.