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. For years, patients who wanted their own medical records had faced a familiar obstacle course of forms, fees, faxes and waiting, and the rules were intended to make it much shorter.

The rules had a long history. Congress passed the 21st Century Cures Act in December 2016, and its health IT provisions told HHS to define and police “information blocking.” HHS published both rules in proposed form in February 2019. A year of heavy comment followed, from EHR vendors, hospitals, insurers, app developers and privacy advocates.

The opposition was public. In January 2020, CNBC reported that Epic’s chief executive had emailed hospital leaders urging them to oppose the ONC proposal, citing patient privacy and cost. CNBC later reported that about 60 hospitals and health systems signed a letter to HHS along those lines. Supporters of the rule, including many app developers and patient advocates, argued that the privacy concern was being used to protect existing business positions.

The first final rule came from the Office of the National Coordinator for Health Information Technology, usually shortened to ONC, the part of HHS responsible for health technology policy. It implemented provisions of the Cures Act. The rule defined information blocking and its exceptions. Information blocking means practices that unreasonably get in the way of patients and others accessing, exchanging or using electronic health information.

The rule named eight exceptions, covering preventing harm, privacy, security, infeasibility, health IT performance, content and manner, fees, and licensing. A practice that fit an exception’s conditions would not count as blocking. A practice that fit none would be judged on its facts.

The ONC rule also required certified health IT, meaning the electronic health record software that has passed government certification, to support standardized application programming interfaces based on HL7 FHIR. It required certified products to be able to export a patient’s full electronic health information. It replaced the older Common Clinical Data Set with the United States Core Data for Interoperability, version 1, as the baseline data set. And it barred developers from contract terms that gagged customers from discussing usability or security problems. It also limited the fees developers could charge, so that patients would not pay for connecting an app to their own records.

Those terms need explaining. An application programming interface, or API, is a defined doorway through which one piece of software can ask another for information and receive it in a predictable format. FHIR, pronounced “fire,” is a widely used standard from the health standards group HL7 for how health data such as medications, allergies and lab results should be described and exchanged. Together they mean a patient’s chosen app can connect to a hospital’s records in a consistent way, without custom engineering for every hospital.

The second rule, the Interoperability and Patient Access rule from the Centers for Medicare & Medicaid Services, applied a similar idea to insurers. It 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 qualified health plans on the federally facilitated exchanges.

The CMS rule went further than patient access. It required those payers to publish provider directories through an API and to exchange certain data with a patient’s new plan when the patient switched. It also changed Medicare’s conditions of participation, so that hospitals with capable EHRs had to send electronic notifications when a patient was admitted, discharged or transferred.

The timing was difficult. The healthcare IT industry’s largest annual conference, HIMSS20, had been scheduled for Orlando that same week; organizers cancelled it on March 5 because of the coronavirus. Two days after the release, the World Health Organization described COVID-19 as a pandemic, and on March 13 the President declared a national emergency.

The rules were published in the Federal Register, the government’s official journal of rules, on May 1, 2020. Hospital leaders read them while running incident command for a pandemic.

Most attention went to the obvious goal: getting health data moving. A less noticed consequence mattered just as much for hospital leaders. Once a patient sends their data to an app of their choice, that copy can leave the protection of HIPAA, the federal health privacy law most people know.

Most commentary on the March 2020 rules focused on interoperability, the ability of different computer systems to exchange and use information. It is about getting data to move between systems that had resisted it, often for a mix of technical, commercial and cautious reasons.

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 sections below first set out the building blocks, then take the three mechanisms in turn. A short hypothetical case shows how they combine on an ordinary Monday. The article closes with what is at stake, the signs of readiness, and the decisions a general counsel and CIO should settle.

Records, standards and who HIPAA covers

A few building blocks make the rest of the story easier to follow.

The electronic health record. An EHR is the software system where a hospital or clinic keeps each patient’s chart: diagnoses, medications, test results, notes and more. A large health system’s EHR is one of the most important and expensive systems it owns.

Certification. EHR software can be certified by the federal government as meeting defined requirements. Hospitals and clinicians have strong incentives to use certified products, because Medicare payment programs have long rewarded the use of certified technology. That is why requirements placed on certified software reach almost every provider.

APIs and FHIR. As described above, an API is a standardized doorway between systems, and FHIR is the standard describing health data passing through it. Before such standards were common, connecting two health systems often meant a bespoke project. FHIR breaks a record into “resources,” such as a patient, an observation or a medication request, each with a defined structure.

SMART on FHIR. The ONC rule built on an authorization pattern called SMART on FHIR. It uses the same web standards, OAuth 2.0 and OpenID Connect, that let a consumer sign in to one website with an account from another. The patient approves an app; the app receives a time-limited token; the token defines what it may read.

The United States Core Data for Interoperability. Usually called USCDI, this is a defined list of the data elements, such as allergies, medications and lab results, that systems should be able to exchange. ONC versions it, so the list grows over time.

Electronic health information. Usually shortened to EHI, this is the information the information blocking rule protects. ONC tied it to the HIPAA “designated record set,” the records used to make decisions about a patient. For the first period, the duty covered only the USCDI elements; the full definition took effect later.

HIPAA. The Health Insurance Portability and Accountability Act sets privacy and security rules for “covered entities,” which are health care providers, health plans and clearinghouses. It also covers their “business associates,” the vendors that handle health data on their behalf. HIPAA is defined by who holds the data, not by what the data is. The same blood test result is protected by HIPAA in a hospital’s system and may not be once it sits in a consumer app the patient chose.

The right of access. HIPAA already gave patients a right to copies of their records, in the form they ask for if readily producible. In 2019, the HHS Office for Civil Rights published guidance on apps. Once a covered entity sends records to an app at the patient’s direction, it is generally not responsible for what the app does next. The 2020 rules turned that principle into infrastructure.

With those pieces in place, the three mechanisms become clearer.

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. Before the rule, a hospital might decide case by case whether and when to share. After it, a delay or refusal needed to fit one of the recognized exceptions or risk being treated as blocking.

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. A health information exchange is an organization that moves records between hospitals, clinics and others in a region or network.

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.

Who the rule reaches, and how hard

The statute treats the three kinds of “actor” differently. A provider is blocking only if it knows a practice is unreasonable and likely to interfere. A developer or network is held to a stricter test: it knows, or should know, that the practice is likely to interfere.

The consequences differ too. Congress authorized civil money penalties of up to $1 million per violation for developers and networks. For providers, it called instead for “appropriate disincentives” through other HHS programs. When the rule took effect, neither penalty regime was yet in place.

That gap shaped behavior. Developers, facing the larger stick, moved first on product changes. Providers had a duty with an unclear consequence, and many treated it as lower priority while the pandemic absorbed their attention. Compliance leaders who documented their reasoning early were better placed when enforcement arrived.

The exceptions as a decision path

The eight exceptions fall into two groups. Five describe when an actor may decline a request: preventing harm, privacy, security, infeasibility and health IT performance. Three describe how an actor may fulfill one: content and manner, fees, and licensing.

A practical way to use them is as a decision path that staff can follow. The first question is whether the request involves EHI at all. The second is whether the organization can meet it in the manner requested. If not, the content and manner exception lets it offer an alternative, such as a different format, provided the conditions are met.

Only after that does refusal come into play. Each refusal exception carries conditions. A security-based refusal, for example, must be tailored to a specific risk and applied consistently, not used as a blanket. A harm-based refusal generally requires a licensed professional’s individualized judgment about a specific patient.

Writing the path down matters for two reasons. It lets front-line staff in health information management handle most requests without escalation. And it creates the record an investigator would ask for later: the policy, the date it was adopted, and evidence it was applied the same way each time.

Start with an inventory

For a health system, compliance is mostly policy and workflow. The starting point is an inventory of the ways requests for data arrive:

• the patient portal, the website or app where patients log in to see their records;
• the release-of-information desk, which handles formal requests for copies of records;
• 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.

The inventory tends to surface channels nobody owns. Research requests, life insurance underwriting requests, and requests from attorneys often travel through separate offices with their own habits. Each is a channel, and each needs a documented basis for its delays.

Uncomfortable findings

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. Many clinicians preferred to see a result before the patient did, so they could explain it. That preference is understandable, but under the rule it was no longer enough on its own.

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.

Results release: the hardest case

Test results produced the sharpest internal conflict. Oncologists, pathologists and genetic counselors worried about a patient reading a cancer diagnosis on a phone at night, alone, before anyone could explain it. Their concern was clinical, not commercial.

The rule’s answer was narrow. The preventing harm exception allows a delay where a licensed professional has determined, for a specific patient, that release is reasonably likely to endanger life or physical safety. A general worry that results may upset patients does not meet that bar.

Health systems found workable middle paths. Some offered patients a choice at enrollment about how they wanted to receive sensitive results. Others invested in counseling before tests were ordered, so patients knew a result might arrive before a call. Clinical leaders had to own these choices, because the trade-off is about care, not configuration.

Speed counts too

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. A release-of-information team buried in manual requests is both a compliance exposure and an expensive use of skilled staff.

How it differs by organization

An academic medical center on a single large EHR platform tends to have the vendor’s certified API and portal ready. Its harder work is policy: specialty clinics with their own release habits, research data flows and complex referral networks.

An ambulatory network built through acquisitions often runs several EHRs. Each needs its own inventory and configuration review, and practices may differ in how they hold results. Standardizing the policy across platforms is usually the larger job.

Behavioral health and substance use treatment programs face a further layer. Federal confidentiality rules for certain substance use disorder records, known as 42 CFR Part 2, and many state laws impose consent requirements of their own. The privacy exception accommodates such legal preconditions, but staff need clear guidance on which records they cover.

A health information exchange is itself an actor, held to the stricter knowledge standard. Its participation agreements, fees and onboarding rules became potential sources of blocking, which pushed many exchanges to revisit terms written years earlier.

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. The hospital no longer designs every screen the patient sees. It provides the doorway; the patient chooses who walks through it on their behalf.

How a patient connection works in practice

The sequence is simple. A patient downloads an app, perhaps one that gathers records from several doctors into one place. The app asks the patient which hospital they use and sends them to that hospital’s own login page. The patient signs in with their usual portal credentials and sees a screen asking whether they want to let this app read their records. If they agree, the hospital’s system issues the app a digital pass, often called a token, that lets it request the patient’s data through the API for a period of time.

The token works like a valet key for a car, which lets the valet drive and park but not open the trunk or glove box, and which the owner can take back. It grants defined access, for a defined patient, and it can be withdrawn. The hospital never hands the app the patient’s password.

Notice where the hospital’s control sits in that sequence. It controls the login, the consent screen, the token and the doorway. It does not control what the app does with the data afterward.

One detail changes the risk profile. Many implementations issue a refresh token, which lets the app obtain new access tokens without the patient signing in again. That turns a one-time download into a standing connection that can keep pulling new results for months. The length of that standing access is a configuration choice worth reviewing deliberately.

Patient access and population access

The certification criterion covered two kinds of access. Single-patient access is the app flow above. Population access, often called bulk FHIR, lets an authorized system request data on a defined group of patients at once, for example an accountable care organization pulling data on its attributed members.

The two carry different risks. A single-patient token exposes one record. A bulk export credential, if stolen or misused, exposes thousands. Bulk access is typically granted to business partners under contract, so it should sit inside vendor risk management, with narrower scopes and tighter credential handling than the patient flow.

The payer side

For payers, the CMS rule created a parallel doorway. A Medicare Advantage plan or Medicaid managed care organization had to let enrollees connect apps to their claims and encounter data, and to clinical data the plan maintains. The rule set a look-back period, so the data reaches back several years.

Claims data reveals a great deal. A pharmacy claim shows a medication; a procedure code can reveal a diagnosis the patient never typed into any app. For payers, the API concentrated years of sensitive history behind one consumer login.

CMS gave payers two limited tools. A payer could deny API access to an app only if it posed an unacceptable security risk to the payer’s own systems, not because of its privacy practices. A payer could, however, ask apps to attest to basic privacy terms and tell enrollees when an app declined. Payers also had to publish educational material for enrollees about choosing an app.

A doorway still needs a lock

An API is an access path like any other. It needs:

• strong patient authentication, so that only the real patient can grant access;
• careful app registration, so the organization knows which apps are connecting;
• rate limits, caps on how many requests an app can make in a given period, which slow down abuse;
• monitoring for abnormal use, so unusual patterns are noticed;
• a process for revoking access, so a patient or the organization can shut the door when needed.

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. Security teams that had never watched the patient portal closely needed to treat it as a primary interface, as important as any system used by staff.

Where account takeover enters

The weakest link in the flow is usually the patient’s portal account. Patients reuse passwords, and portal enrollment often relies on information an attacker can find, such as a date of birth and an address. An attacker who takes over a portal account can authorize an app they control and harvest the record through a fully compliant API.

That makes portal identity proofing and multifactor authentication the controls that do most to reduce API risk. They also carry a cost. Older patients and those with limited English or limited internet access abandon enrollment when steps pile up. Each added check needs a fallback path, such as in-person verification at registration, so that security does not become a barrier to access.

The aggregator problem

Certified EHR endpoints were only half the chain. Many consumer apps connect through intermediaries that aggregate records from many hospitals and payers. Security research published in October 2021, in a report titled “Playing with FHIR,” found serious authorization flaws mainly in such third-party aggregators and apps, rather than in the EHR systems themselves.

For a health system, that research pointed to a limit. It can harden its own API, but data that leaves through it may land in a less protected system. The provider’s contribution is to keep scopes narrow, monitor for abnormal pulls, and give patients clear information about revocation.

What to measure

A short set of metrics turns the API from a feature into a governed interface. Useful ones include the number of registered apps, active patient connections per app, data volume per connection, failed authorization attempts, and the time to revoke access once a concern is raised.

The owner of those metrics matters as much as the numbers. Security operations should see the raw signals daily. Privacy and compliance leaders should see a monthly summary with trends, so that they notice a new app growing fast before it becomes a problem.

The same plumbing works both ways

The same plumbing also works inbound. Standardized APIs and a defined data set, the USCDI, make it easier for a health system to pull data from other organizations as well as send it. A patient arriving at the emergency department from another health system, for example, might have medications and allergies available far faster.

Organizations that built one governed integration layer for both directions got more value from the investment and had fewer one-off interfaces to secure. An integration layer is the shared set of tools and rules through which data enters and leaves the organization.

The CMS rule added an inbound and outbound duty of its own: the admission, discharge and transfer notifications. Sending them to a patient’s community providers is a small data flow, but a hospital that routes it through the same governed layer gains one more reason to have that layer.

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. A patient may not realize that the protections they assume apply to “medical records” do not follow the data into every app. If an app later misuses that data, the patient may still associate the harm with the hospital whose records it came from.

Which rules take over

Outside HIPAA, three sources of protection remained in 2020. The FTC can act against an app that breaks the promises in its own privacy policy, or whose practices are unfair. The FTC’s Health Breach Notification Rule, dating from 2009, required certain vendors of personal health records to notify people of breaches, though it had never been enforced at that point.

State law formed the third layer, and it was uneven. California’s consumer privacy law had taken effect at the start of 2020. It exempted data covered by HIPAA, but data in a consumer app would generally not have that exemption. Most states had no comparable law yet.

The practical effect was that protection depended on where the patient lived and what the app had promised. A hospital explaining the risk to patients could not describe one standard, because there was none.

Why the business associate route was closed

A natural question from boards was why a hospital could not require apps to sign a business associate agreement. The answer is that an app chosen by the patient acts for the patient, not for the hospital. It is not a business associate, so HIPAA gives the hospital no basis to demand one.

Insisting on contract terms as a condition of access would likely look like interference. The difference matters for vendor management: apps the hospital itself selects and pays for, such as a remote monitoring tool, belong in the business associate program. Apps the patient brings do not.

Patient communication as a control

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 clear language and without discouraging legitimate use. The balance matters: a warning so alarming that patients abandon useful apps could itself look like interference.

ONC’s rule allowed actors to inform patients about privacy and security risks, provided the information was accurate, objective and applied the same way to every app. That standard rules out a warning shown only for apps that compete with the hospital’s own tools. It also rules out vague alarm. A consistent, factual screen about what to look for in a privacy policy meets it.

Governing what you do not control

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 fall between compliance, health information management, IT and clinical leadership. Health information management is the department responsible for medical records. Without a named owner, each group assumes another is handling it.

Have a playbook ready

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.

The playbook should separate two situations that look alike in the logs. In the first, patient accounts were taken over; that is the hospital’s security incident, with its own breach analysis under HIPAA. In the second, patients genuinely chose an app that then behaves badly; that is the app’s problem, and the hospital’s role is to inform patients and regulators.

The case against this framing

The strongest objection is that the perimeter was never tight. Patients could always request paper copies and hand them to anyone. The HIPAA right of access already let them send records to third parties. On this view, the 2020 rules changed convenience, not principle.

The objection is right about principle and wrong about scale. A paper copy is a one-time disclosure that a patient handles personally. An API connection is automated, can persist through refresh tokens, and can be repeated across millions of patients through the same few apps. Concentration in a handful of aggregators turns individual choices into large data stores outside HIPAA.

A second objection is that worrying about apps repeats the vendor arguments of early 2020, which critics saw as protecting market position. That risk is real. The response is to separate the hospital’s legitimate duties, securing its doorway and informing patients accurately, from any attempt to steer patients away from competitors. The rule permits the first and penalizes the second.

One hospital, one unfamiliar app

Suppose a regional health system’s EHR now supports patient APIs, and dozens of apps have registered.

One Monday, the monthly report to the privacy officer shows something new. Over the weekend, several hundred patients authorized the same newly registered app, which none of the staff recognize. The app has pulled complete records for each patient, far more than a typical app requests.

Because the health system prepared, the steps are already written down. The security team checks whether the patient accounts show signs of compromise, such as logins from unusual locations or password resets just before authorization. The privacy team looks up the app’s registration details and published privacy policy. Health information management confirms that the patients’ authorizations were genuine. If the accounts were compromised, the team revokes access and notifies the affected patients. If the authorizations were genuine but the app’s conduct looks questionable, the system cannot block it on that basis alone, but it can inform patients and raise its concerns with regulators.

The team also checks the pattern of enrollments. Several hundred authorizations in a weekend might reflect a legitimate marketing push, such as an employer wellness program promoting the app. Or it might reflect a scheme that enrolled patients with misleading promises. The answer changes which regulator, if any, should hear about it.

Without that preparation, the same Monday looks different. The report goes to someone who is unsure whether it is their problem. IT assumes compliance is handling it; compliance assumes IT is. A week passes. That gap, rather than the technology, is usually where the risk lies.

What is at stake for a health system

• Regulatory exposure. Information blocking is a compliance obligation with consequences. Routine habits, such as holding results or slow release processes, can now carry risk.
• Patients and reputation. Patients gained real control over their data. Health systems that make access easy and explain it clearly build trust; those that seem obstructive, or whose patients are harmed by apps, may lose it.
• Security. Patient-facing APIs are a new front door to the organization’s most sensitive data and need the same protection as any staff system.
• Cost and staff. Measuring and automating release processes cuts compliance risk and frees skilled staff from manual work.
• Clinical value. The same standards that send data out make it easier to bring data in, improving the information available at the point of care.

The weight of these differs by organization. A payer faces the largest concentration of history behind one login, so security and patient education dominate. An academic medical center faces the hardest clinical policy questions on results release. A small physician practice relies almost entirely on its EHR vendor’s defaults, so its influence comes from asking that vendor the right questions.

The costs also fall unevenly. Large systems could fund integration teams and API monitoring. Smaller hospitals and practices generally could not, and depended on vendors and health information exchanges for both capability and compliance. For them, the contract with the EHR vendor became the main compliance instrument.

Signs of a health system that is ready

A well-prepared health system tends to have:

• an inventory of every channel through which data requests arrive, with delays and refusals tested against the exceptions;
• documented release practices, written with counsel, and a named owner for new cases;
• turnaround times measured by channel and reviewed;
• patient APIs protected with strong authentication, registration, rate limits, monitoring and revocation;
• portal enrollment with identity proofing and multifactor authentication, plus a supported fallback for patients who struggle with it;
• one governed integration layer for data coming in and going out;
• plain-language explanations for patients at the moment they authorize an app, applied identically to every app;
• regular reporting of connected apps and data volumes, and a playbook for unusual patterns.

The usual ways it goes wrong:

• Treating it as an IT project. Leaving information blocking to the technology team when most of the work is policy, workflow and clinical practice.
• Keeping convenient holds. Leaving result-release delays in place because clinicians prefer them, without a documented exception.
• Ignoring the API. Securing staff systems carefully while treating the patient API as a minor feature.
• Over-warning patients. Discouraging app use so strongly that the warning itself becomes interference.
• Selective warnings. Showing cautions only for apps that compete with the organization’s own tools.
• No owner. Letting decisions about apps and data flows fall between departments.

An examiner or investigator reviewing a complaint would likely ask for a predictable set of evidence. That includes the written release policy and its adoption date, the exception relied on for each category of delay, turnaround data, and records showing the policy was applied consistently. Assembling that file before anyone asks is far cheaper than reconstructing it afterward.

Patient-app decisions the general counsel and CIO need to settle

1. Where do we delay or refuse requests today, and which information blocking exception does each rely on?
2. Do we hold any test results from patients by default, and is there a documented basis for each hold?
3. Which apps are connected to our records today, and how much data does each pull?
4. Who owns decisions about third-party apps: compliance, health information management, IT or clinical leadership?
5. What would we do on Monday morning if hundreds of patients connected the same unfamiliar app over a weekend?

Each answer should be written down, with an owner and a review date. The first two belong to compliance and clinical leadership together. The third and fifth belong to security operations, with a summary to the privacy officer. The fourth is a governance decision for the executive team.

The March 2020 rules opened the doors to patient data on purpose. The work for health system leaders is to make sure those doors are well built and well watched, and that patients understand where their data goes once it leaves.

With hindsight

The pandemic delayed the timelines. ONC moved the information blocking applicability date from November 2020 to April 5, 2021. CMS announced in May 2020 that it would not enforce the payer Patient Access and Provider Directory API requirements until July 1, 2021. The hospital admission, discharge and transfer notification requirement was pushed to May 2021.

The scope then widened in steps. Until October 6, 2022, the information blocking duty covered only the USCDI data elements. After that date, it covered the full set of electronic health information. Certified developers had until the end of 2022 to deliver the new standardized FHIR API to customers.

Not everything held. In September 2021, CMS said it would not enforce the payer-to-payer exchange requirement until further rulemaking, because the rule had not settled the technical standards. That piece returned only in CMS’s 2024 rule.

Enforcement developed in stages. The HHS Office of Inspector General finalized civil money penalties for developers and networks in 2023, with fines of up to $1 million per violation. HHS finalized disincentives for providers in June 2024. A hospital found to have blocked can lose its status as a meaningful EHR user, and with it a large share of its annual Medicare payment update. Clinicians in the Merit-based Incentive Payment System can receive a zero for the Promoting Interoperability category. Accountable care organizations and their participants can be barred from the Medicare Shared Savings Program for at least a year.

The staggered approach meant that, for several years, the rules were clearer than the penalties. In September 2025, HHS announced a crackdown, with ONC and the Inspector General issuing an enforcement alert that said they would actively pursue information blocking. That announcement amounted to an admission that the duty had not been fully absorbed five years after the rules were issued.

The results release debate also produced evidence. A large survey of patients at four academic medical centers, published in JAMA Network Open in 2023, found that most patients preferred immediate access to results, even before a clinician had reviewed them. A minority who received abnormal results reported more worry. Both sides found support in it; the case for blanket holds did not.

ONC kept revising the framework. Its HTI-1 rule, finalized in December 2023, set USCDI version 3 as the baseline from 2026, added transparency requirements for decision support tools, and refined the exceptions. In 2024 the office was reorganized and renamed as the Assistant Secretary for Technology Policy and ONC.

The national plumbing grew too. The Trusted Exchange Framework and Common Agreement, known as TEFCA, began operating at the end of 2023. It added a national network layer: an agreed set of rules allowing different health information networks to connect with one another, rather than every organization negotiating separately.

CMS’s 2024 interoperability and prior authorization rule extended API requirements further. It added provider access, so clinicians can see data held by a patient’s insurer. It added payer-to-payer exchange, so data follows a patient who switches plans. And it added prior authorization, the process by which insurers approve certain treatments in advance. Most of its API requirements were set to apply from 2027.

In July 2025, CMS launched a voluntary health technology ecosystem initiative at a White House event. EHR vendors, networks and app companies pledged to support patient-facing apps and to replace paper intake forms with digital check-in. That moved the federal emphasis from forbidding obstruction toward actively promoting consumer apps.

Concern about data outside HIPAA also grew. The October 2021 “Playing with FHIR” research showed that the weakest points were third-party aggregators, as described above. The FTC said in a 2021 policy statement that health apps could fall under its Health Breach Notification Rule. It brought its first case under that rule, against GoodRx, in 2023, and updated the rule in 2024 to make clear it covers health apps. That rule requires certain companies not covered by HIPAA to notify people when their health data is disclosed without authorization, so it reaches into exactly the space the 2020 rules opened up.

States moved as well. Washington’s My Health My Data Act, passed in 2023 with most provisions effective in 2024, regulates consumer health data outside HIPAA and lets individuals sue. Several other states adopted narrower measures. Congress has not passed a comprehensive federal privacy law, so the patchwork the 2020 rules exposed remains a patchwork.

What held up was the core bet: standardized APIs made patient access routine across certified EHRs and many payers. What did not hold up was the assumption that the market and existing law would protect data after it left. The protection gap has narrowed, through FTC enforcement and state law, but it remains open.

Sharing patient data is no longer something a health system can choose to slow down. What it can still choose is how well it secures the doorway, how clearly it explains the choice to patients, and how quickly it notices when something looks wrong.