The TEFCA Excuse Is Expiring and DSM gets Deregulated: What HHS's 2026 Rules Mean for HIEs

For years, health information exchanges have operated inside two regulatory frameworks pointed in opposite directions. HIPAA's Privacy Rule presumes protected health information should not move unless a specific permitted use, disclosure category, or authorization allows it. The interoperability and information-blocking rules presume the opposite: electronic health information should move unless a specific exception applies. TEFCA participation has functioned as the easiest way to satisfy that second presumption without examining each request individually.

That arrangement is expiring in 2026.

HHS is finalizing a HIPAA Privacy Rule update that pushes more data out through patient-directed channels. At the same time, it is removing several of the information-blocking exceptions HIEs have relied on for years, and for the first time it is actually enforcing information-blocking penalties against exchanges and networks themselves, not only against the EHR vendors most assumed were the real target.

This is not a rules update HIEs can file away for later. It changes what counts as a legitimate reason to deny a data request, who can be fined for denying one anyway, and how much protection TEFCA participation still provides. The sections below walk through what each change looks like in an actual request, not just in the regulation text.

The exceptions are closing in

The most consequential piece is HTI-5, the deregulatory rule ONC/ASTP proposed on December 29, 2025. Comments closed February 27, 2026, and finalization is expected this month (August 2026.) On paper, HTI-5 reads as deregulation: it would strike 34 of the 60 existing health IT certification criteria and revise seven more, moving certification toward FHIR-based APIs and away from older standards like the Direct Project (HealthIT.gov fact sheet; Reed Smith). That is a bigger deal than it sounds. Direct Secure Messaging still carries a large share of real-world transitions-of-care and public health reporting traffic today, and once it is no longer a certification requirement, vendors have no regulatory obligation to keep building or maintaining it, which could mean the standard quietly erodes over time even though nothing formally bans it. Flip to the information-blocking section, though, and it is the opposite story. The three exceptions HIEs lean on most in an actual denied-request conversation all get narrower.

• The TEFCA exception disappears entirely. Right now, an HIE that participates in TEFCA can point to that participation as a defense against an information-blocking complaint, almost regardless of what happened with the specific request in question. Picture a home health agency asking a regional HIE for admission, discharge, and transfer alerts on a shared patient. The HIE never actually turns that feed on, but when the agency complains, the HIE's answer is "we're a TEFCA QHIN participant, so we're meeting our interoperability obligations." Today, that answer can be enough on its own. HTI-5's stated basis for removing this exception (formally, the TEFCA Manner Exception) is TEFCA's continued implementation and maturation, the framework no longer needs a standing carve-out built for its early days (Federal Register). That case is easy to see in the numbers, even if they're not the rule's own cited rationale: separate HHS data shows TEFCA exchange volume climbing from roughly 10 million records in January 2025 to more than 1 billion by mid-2026, a scale at which network membership alone stops being a meaningful stand-in for whether any particular request got fulfilled (HHS press release). Once this exception is gone, "we're in TEFCA" stops being an answer, and the home health agency's specific request has to actually be fulfilled, or declined for a request-specific reason that survives on its own.

  
  

• The manner exception gets tighter. This exception lets an actor decline to share data in the exact way a request specified, as long as it offers a workable alternative and negotiates that alternative in good faith. Here's the loophole HTI-5 is closing: picture a small rural clinic asking an HIE for a real-time discharge-alert feed through a specific method the HIE genuinely can't support. The HIE offers an "alternative," a data-sharing agreement with a $50,000-a-year connection fee, far above what comparable connections normally cost, plus a clause locking the clinic into exclusivity so it can't also connect through a competing network. The clinic can't afford it and won't accept the exclusivity term, so it walks away. Under the current rule, the HIE can say: we offered an alternative, the clinic declined it, so our obligation is satisfied and we're protected. The clinic never got the data, but on paper the HIE looks compliant. HTI-5 says an alternative offered on those terms (a price designed to be unaffordable, a take-it-or-leave-it structure, one-sided conditions) no longer counts as a good-faith offer. So it no longer protects the HIE, and the underlying denial is exposed as information blocking instead (McDermott).

  
  

• The infeasibility exception narrows too. Right now, an actor can deny a request that would let a third party modify electronic health information, on the theory that letting an outside party write into the record is too risky or technically unworkable. Picture an EHR vendor or HIE refusing to let an independent care-management company write care-gap reminders or updated medication lists back into a shared record, on the grounds that a "third party modifying the data" is inherently infeasible, even though the care-management company is using the same secure, standards-based write methods the vendor's own products use elsewhere. HTI-5 removes that justification, on the reasoning that two-way interoperability is common enough now that this kind of denial no longer has a good excuse (ONC fact sheet). The same section also closes a related gap: if a state Medicaid agency runs an automated system that queries an HIE thousands of times a day to check for care gaps, an HIE can no longer argue that an automated or AI-driven query isn't a "real" request that the rule was meant to cover (HealthIT.gov).

  
  

A follow-on rule, HTI-6, is expected as a proposal around November 2026 and goes further on API standards and information-blocking updates. This is a multi-year arc, not a single rule to track once and move past (Fenwick; Inside Privacy).

Enforcement stopped being theoretical

The bigger near-term shift may not be a new rule at all. It is that HHS has started actually acting on the rules already on the books, even though the first visible action landed on developers, not HIEs. HIEs and health information networks are named, explicitly, as information-blocking "actors" carrying the same exposure as health IT developers, and that matters because in February 2026, ASTP (led by National Coordinator Thomas Keane) issued notices of nonconformity, a certification-program enforcement step that can lead to a corrective action plan, certification termination, or referral to OIG for civil penalties, to certain certified health IT developers over information-blocking and API issues (Healthcare Dive; HHS press release). No HIE had been the subject of one of these notices as of that point, and OIG has not yet issued an actual civil monetary penalty to anyone. What has changed is that the machinery is now visibly running: the Information Blocking Complaint Portal has logged well over a thousand complaints, and OIG has said it is actively reviewing them.

The exposure, once OIG does act, is real money, and it can add up fast. Civil monetary penalties run up to $1 million per violation for developers, HIEs, and networks, and a single bad practice applied to multiple requestors can count as multiple violations rather than one (OIG enforcement alert; Alston & Bird). Consider the rural clinic example above. If that same $50,000-connection-fee agreement was used as the standard response to every clinic that asked for the same feed over the past year, an investigation isn't necessarily limited to one violation because it was one agreement. Each denied clinic can be its own instance. CMS enforcement runs alongside OIG's: hospitals found to have committed information blocking can lose "meaningful EHR user" status, clinicians can be zeroed out on the Promoting Interoperability portion of their MIPS score, and CMS can deny or terminate an ACO's participation in the Medicare Shared Savings Program. ONC handles certification consequences separately. Once OIG resolves or finalizes a penalty, violators are named publicly, adding a reputational cost on top of the financial one (Alston & Bird).

That changes what exception documentation is for. What used to be an internal compliance note, written mainly to explain a decision to an internal audit committee, is now the document that decides whether an HIE is writing a seven-figure check.

More data, moving faster, through HIE pipes

Separately, OCR is finalizing a HIPAA Privacy Rule update, expected this same month, that traces back to a January 2021 proposal. For HIEs, the relevant piece is direct: it creates a formal pathway for individuals to direct a covered entity to share their EHR-based PHI with another covered entity, and it expands "healthcare operations" to explicitly cover care coordination (HIPAA Journal; Fenwick). A separate proposal, on its own track and expected around November 2026, would take another run at shrinking the access-request response window, continuing the original 2021 push to bring it down from 30 days to 15.

Picture a patient with diabetes switching to a new primary care practice. Under the new pathway, the patient directs the new practice to request their record from the old one, and the old practice has to transmit it within a firm, short window rather than the new practice waiting on a signed authorization to work its way through medical records. The rule does not route this through an HIE, or specify any transmission method at all; it simply obligates the old practice to send the record, leaving the how up to whatever channel gets it there in time. That is where an HIE's role gets indirect rather than automatic: as more of these directed, provider-to-provider transfers hit tighter deadlines, a fast electronic channel, an HIE connection, a direct EHR-to-EHR interface, or Direct Secure Messaging, becomes the difference between meeting the deadline and missing it. For a practice with no existing point-to-point channel to the sender, an HIE connection already in place is often the fastest way to actually clear that deadline, turning what would otherwise be a scramble into a routine query or push instead of a manual records request. Less ambiguity about whether a given request is HIPAA-permissible, paired with a hard deadline, makes privacy-based caution a harder excuse for sitting on one.

Two reversals, pulling in opposite directions

42 CFR Part 2 alignment is already final, and it is already changing what moves through HIE systems, though not at the point most people assume. It doesn't touch how the initial consent is collected, and it doesn't merge Part 2 consent into general HIPAA consent. HIEs have been able to collect broad, general-designation Part 2 consent, the "my treating providers" language, rather than naming a specific recipient, since a 2017 rule, and that consent has always been its own separate, opt-in document, distinct from whatever consent model (opt-out or otherwise) covers general medical data. None of that changed in 2024, and there's no reason it should.

What changed is what happens to the data after that first, properly consented disclosure. Before 2024, Part 2's redisclosure restriction traveled with the record through every downstream hop. A hospital that received a patient's SUD treatment history under a valid consent generally could not then pass that same information along to a second treating provider the way it could with any other clinical data in the chart, because Part 2 required its own justification for that next disclosure too, not just the first one. The 2024 rule changes that specific link: once a HIPAA-covered entity or business associate receives Part 2 records under a valid consent, it can now redisclose those records further under ordinary HIPAA rules, the same way the rest of the chart moves, as long as the required Part 2 redisclosure notice still travels with the record and the data isn't used against the patient in a legal, administrative, or legislative proceeding without separate authorization (HHS.gov Part 2 overview; HIPAA Journal).

Imagine a patient with a history of opioid use disorder who signed a general-designation Part 2 consent authorizing their treatment program to share records with their treating providers through the HIE. That covers the first hop: the treatment program discloses to the hospital currently treating them. The friction has historically been the next hop. If that hospital needed to pass the same information to a different treating provider, an ER across town during a later overdose event, Part 2's redisclosure restriction followed the data there too, and the hospital could not forward it under its own routine HIPAA-permitted operations the way it could with anything else in the chart. Under the 2024 rule, that second hop can now happen under ordinary HIPAA rules once the first disclosure was properly consented. Any HIE that still treats every downstream hop of Part 2 data as requiring its own fresh justification, built around the pre-2024 restriction, has reason to check whether that step is still necessary.

The reproductive health privacy rule went the other direction entirely. The 2024 rule adding heightened protections for reproductive health information was vacated nationally by a federal district court in Purl v. HHS in June 2025. HHS itself did not appeal. A September 2025 appeal filed by third-party intervenors trying to defend the rule after HHS declined to (the cities of Columbus and Madison, and Doctors for America) was voluntarily withdrawn, and the Fifth Circuit granted the dismissal. The rule, and its attestation requirement, is done (American Bar Association; Holland & Knight; Georgetown Health Care Litigation Tracker). Any HIE that built specific logic around that rule, for example, flagging certain diagnosis codes for extra review or requiring requestors to attest they weren't seeking the data for an investigation into reproductive health care, can retire that logic at the federal level. State reproductive-health privacy laws remain active and still vary by state, so this is not a clean reset everywhere. An HIE operating across state lines still needs to check what each state independently requires.

What isn't moving, yet

The HIPAA Security Rule overhaul is the biggest cybersecurity rewrite HIPAA has seen in over a decade: mandatory encryption, MFA, network segmentation, annual penetration testing, and a full technology asset inventory mapping every system that touches protected health information. It drew more than 4,000 public comments after its January 2025 proposal and has since slid off HHS's active agenda onto the long-term list, with finalization now expected around July 2027 instead of the May 2026 target it previously carried (Clark Hill). It is not interoperability-specific, but HIEs sit at the exact center of the cross-organizational data flow this rule is meant to secure. The delay buys planning time. It does not buy an exemption.

Where compliance teams should focus first

The place to start is the exceptions, not the headlines, because those are what show up first when a requestor complains.

• Every agreement or SOP that leans on TEFCA participation as a blanket answer should be checked against a simple test: if a specific requestor complained about a specific denied request tomorrow, would "we're in TEFCA" be the whole answer, or is there a request-specific reason behind it. HTI-5 is about to make the first answer insufficient on its own.

• Participation and data-use agreements are worth a second look, especially any that were priced or structured in a way that makes them hard for a requestor to actually accept. That is a contracts review as much as a compliance one, and it is exactly the kind of agreement the manner exception change is aimed at.

• Part 2 data handling deserves a fresh look, though not at the consent-collection step. General-designation, opt-in consent for BH/SUD data has been available for years and should stay separate from general HIPAA consent. What is worth checking is downstream: whether the HIE, or a participant receiving Part 2 data through it, still blocks that data from moving to a second or third hop that would otherwise be routine under HIPAA, since the 2024 rule may have already removed that restriction.

• More of these directed, provider-to-provider transfers should be expected once the Privacy Rule's EHR-directed sharing pathway goes live, triggered by patient instruction and a firm deadline instead of a signed authorization working through medical records.

• Exception documentation should be written as though OIG will read it after the fact, because it might, and because the same pattern applied to multiple requestors can turn one bad agreement into multiple violations.

  
  

The Security Rule is the one item on this list that can wait. Everything else cannot.

None of this is finished yet. HTI-5, the Privacy Rule update, and HTI-6 are all still moving, and final rule text has a way of shifting from what is proposed. The task right now is not to declare compliance against rules that have not been published. It is to make sure that when they are, the answer to a denied request is something more specific than "we're in TEFCA."