A federal scorpion wants to cross an interoperability river but cannot swim, so it asks an EHR frog to carry it across to the other, deregulated side of the river.
The EHR frog hesitates, afraid that the scorpion might sting it, but the scorpion promises not to, pointing out that it would drown if it killed the frog in the middle of the river.
The frog considers this argument sensible and agrees to transport the scorpion, wanting to get to the deregulated side too.
Midway across the river, the scorpion stings the frog with information blocking regulation anyway.
The dying frog asks the scorpion why it stung despite knowing the consequence, to which the scorpion replies: "lol lmao" and swam to the other shore.
To add insult to injury, he then flipped off the frog with HTI-6.
Okay, we’re perhaps getting a bit too far down the metaphoric lane with no intro or explanatory text. Mea culpa - it’s hard not to get lost in the excitement of the first real regulatory drop in the new regime from our friends at the Assistant Secretary for Technology Policy, the artist formerly known as the ONC.
Health API Guy is a reader-supported publication. To receive new posts and support my work, upgrade to become a paid subscriber.
We’d been expecting HTI-5, the long-awaited heir to the Cures throne, for some time. And the consensus expectation was straightforward: deregulation. In “The Unified Agenda and Deregulation” and “Awaiting the Next Tablets”, we talked about why that expectation was rooted in the administration’s own top-of-funnel signaling via the Unified Agenda, where HTI-5 was explicitly flagged as deregulatory in aim.
The notice in the Unified Agenda shows HTI-5 (as many anticipated) will be deregulatory in aim. We aren’t getting fun new EHR capabilities like FHIR subscriptions out of this - we’ll see the number mandated capabilities and regulatory requirements on EHRs decrease in line with this administration’s overall hypothetical deregulatory push (Unleashing Prosperity Through Deregulation).
The thesis then was simple: the government would likely reduce what EHRs are required to build, certify, and report. Fewer certification criteria. A trimming back of Meaningful Use-era leftovers. Less burden on EHRs. Less federal scorpion, more free-market frog.
What we maybe underweighted at the time is that deregulation of certification does not necessarily mean deregulation of conduct. You can shrink the checklist and still sharpen the stick. And as it turns out, while HTI-5 may indeed loosen the scaffolding around certified capabilities, it looks increasingly willing to tighten the screws on information blocking: fewer exceptions, fewer escape hatches, and far less patience for “market freedom” arguments once data is in motion.
The value of summary is limited in this LLM world we live in and the ASTP’s own Fact Sheet is a great resource to this extent. However, a brief rundown ordered from most to least interesting:
Automated and agentic access is squarely in scope, with revised definitions of “access” and “use” clarifying that autonomous systems and other automated means are subject to information blocking analysis
Information blocking regulatory burden increases, with fewer exceptions, narrower conditions, and explicit concern about the misuse of the Infeasibility and Manner Exceptions to frustrate access, exchange, or use of EHI
TEFCA loses its special carve-out, with the proposed removal of the TEFCA-specific Manner Exception signaling that participation in a federal exchange framework does not confer immunity from information blocking scrutiny
Certification is explicitly re-centered on APIs (particularly FHIR) rather than end-user functionality, with non-FHIR, workflow-specific, and transport-specific requirements pared back or eliminated in favor of data access surfaces
The rule removes 34 criteria and updates 7 out of the 60 present today, shrinking the scope of the ONC Health IT Certification Program and continuing the retreat from Meaningful Use–era functional mandates
Conditions and Maintenance of Certification are materially reduced, including descoping Real World Testing, narrowing Insights reporting, and removing other ongoing oversight mechanisms viewed as high-burden and low-yield.
Let’s dig into that overall picture of the proposed rule’s biggest takeaways and some of the surprises we saw. Also, if you’re looking for raw, unfiltered, and overly detailed comments, you might like the notes from my read-through yesterday here.
HTI-5 and the past five years of regulatory moves make clear that information blocking is no longer something you manage defensively through exceptions, negotiation tactics, or framework badges. The vendors that fare best will lean into access, design for it intentionally, and align their technical and commercial strategies accordingly.
It’s something we help with at HTD Health. If you’re a developer of certified health IT, we’d love to talk about how to adapt your product, API strategy, and operating model for where the rules are clearly heading. And if you’re an application developer trying to navigate access, automation, or information blocking exceptions in this new environment, we’re happy to help you chart a path forward. Reach out here.
Information Blocking
RPA and Agents
HTI-5 is littered with references to AI, RPA, and agents, reflecting an agency that is clearly trying to be forward-thinking. From the preamble:
This would allow more creative artificial intelligence (AI)- enabled interoperability solutions that combine FHIR with newer standards to emerge, such as Model Context Protocol (MCP) which “standardizes how applications provide context to Large Language Models (LLMs)” , and further embrace the Cures Act’s reference to “…successor technology or standards…” in the API Condition of Certification.
What’s notable here is not the endorsement of any specific technology (although they certainly signal a penchant for FHIR), but a deliberate rejection of technology-specific gatekeeping. ASTP is signaling that interoperability obligations should persist even as implementation paradigms evolve, rather than freezing compliance around today’s APIs or yesterday’s standards.
It feels like we're almost at that moment and tipping point. The momentum with FHIR will continue and its utility will remain, but so many of the rigid, use case specific pipes we've built will feel silly as we graduate to the next era of exchange - perhaps MCP, perhaps something we haven't thought of yet, but almost certainly a data exchange mechanism that's LLM/AI native. Dumb, flexible pipes become infinitely more valuable than smart, rigid ones.
To believe otherwise is to believe we’ve reached an end state that is not just the local maximum, but the absolute zenith of what’s possible. The only truth is that the things we’ve built will look dumb to the next generation.
HTI-5 continues this theme and kicks off the information blocking revisions by proposing updates to the definitions of “access” and “use” to emphasize that they include automated means, explicitly calling out autonomous and agentic systems.
This is preemptive regulatory cleanup that matches their recent FAQ on the topic. It forecloses arguments that RPA, screen scraping, or AI-driven workflows fall outside information blocking analysis simply because they are not traditional API integrations. If a person is entitled to the data, their machine can be too, subject to exceptions (more on that below).
There’s been a lot of chatter of information blocking exceptions being slimmed down, as June’s CMS Request for Information had specific language asking about that:
…
What exceptions could they target?
HTI-3’s Protecting Care Access: Health tech is mostly bipartisan in its arc, but this exception (intended to allow for some withholding of EHI for reproductive health care scenarios) is not. It will be cut due to conservative values and ongoing partisan culture wars.
TEFCA-related stuff: HTI-1 added the TEFCA Manner exception to make TEFCA a goldcard of sorts. HTI-2 added statutory language about TEFCA. They will propose removing both, but they’ll listen to comments here.
Other exceptions: Cutting anything beyond those would be absolutely wild. Most others feel reasonable, if narrowly interpreted (as the courts have done). Any other exception cutting would cause a lot of pushback from EHRs and providers as affected actors. Maybe some exceptions could be combined? Fees and licensing are similar, as are infeasibility and manner. But that also would just be shuffling cards.
TEFCA indeed was cut, but the ASTP went well beyond my predictions and opted for “absolutely wild”. Instead of trimming around the edges, HTI-5 takes aim at the structure of several core exceptions themselves, explicitly citing misuse, abuse, and strategic deployment as justification for narrowing or outright removal:
Innovators and patient advocates indicated that some of the exceptions as currently codified may be too broad or are being misused in an anti-competitive or obstructive way.
Perhaps it’s just alphabetization in play, but it’s easy to read into the ordering of parties there in terms of who these updates are for. The innovation ecosystem has a strong sway with this administration.
1. Infeasibility Exception
HTI-5 squarely targets the Infeasibility Exception, not by repealing it wholesale, but by removing or narrowing specific conditions ASTP/ONC believes have been weaponized.
Third-party seeking modification use condition (proposed removal)
This condition was a really complex double negative that disallowed an actor from claiming infeasibility when a third party sought to modify certified health IT (write data) and a provider was involved.
I liked this condition to the exception despite its complexity. At HTD, we include a section on it in our information blocking workshops specifically to show that write access to the EHR has always been within the scope of information blocking, despite persistent industry assumptions to the contrary.
However, because the condition was framed as a narrow carve-out from infeasibility (rather than a clear rule about when access must be provided), it became confusing to interpret and easy to invert. ASTP’s conclusion in HTI-5 is essentially that this level of indirection created more room for gamesmanship than protection. If modification truly raises security, integrity, or safety issues, those concerns are already covered elsewhere. If it doesn’t, the condition merely serves as a doctrinal speed bump that slows access without adding real analytical value.
ASTP says it has observed substantial growth in: “technical approaches that enable efficient, appropriately secure modification use as well as two-way exchange interactions between different developers’ systems”. This is odd for two reasons:
There’s always been two-way exchange. HL7 v2 interfaces, CCDAs with acknowledgements, eRx, lab results, ADT feeds…health IT has never been meaningfully “read-only.” Writing back into systems is not a new phenomenon, even if modern APIs and agentic workflows add new paths.
The rise of new write-capable technologies doesn’t actually change the legal calculus. Information blocking doctrine is intentionally technology-agnostic, a point ASTP itself emphasizes elsewhere repeatedly in HTI-5! Whether data is written via HL7 v2, FHIR, RPA, or some future protocol should not affect whether blocking analysis applies.
Unless I’m insane, under HIPAA, EHI is definitionally only EHI with a provider's involvement. A vendor wanting to connect to another vendor isn't dealing with EHI, so information blocking isn't in play as written. A vendor will still need to be a provider's business associate for a complaint.
However, this section had some verbiage that suggests the ASTP sees otherwise?
"...potential business associates of the EHR developer’s health care provider customer, from accessing or using a health care provider’s EHR and relevant EHI"
This needs clarification from the ASTP. Potential business associates shouldn't be accessing EHI. Business associates should be accessing EHI.
Manner exception exhausted condition (narrowed or removed)
The Manner Exception Exhausted condition was originally introduced in HTI-1 as a pressure-release valve. It was designed to protect actors facing a requestor who refused reasonable alternatives by allowing an infeasibility claim once the actor had exhausted the Manner Exception in good faith.
In practice, ASTP now says it has become something else entirely. The agency states plainly that the condition has been invoked to delay or deny access even when practical paths forward existed, and that its internal feedback (via RFIs, the information blocking portal, and direct stakeholder engagement) points to systematic misuse rather than edge-case reliance.
HTI-5 proposes to re-engineer the condition so that it is far harder to satisfy without actually enabling access. The changes operate along several dimensions at once:
My wife’s favorite (only) karaoke song, so this is a deep cut homage to her
“Two” becomes “all”: Instead of offering any two alternative manners, actors must offer all of the enumerated alternatives in §171.301(b)(1) before claiming exhaustion. ASTP notes this does not mean all conceivable manners, but I guarantee people will interpret it that way (people don’t read).
“Same” becomes “analogous”: Access can no longer be denied because it isn’t identical in form - the comparison is now about substance.
“Substantial number” becomes “any”: If an actor provides analogous access to even one other party, it cannot rely on exhaustion to deny access here. Partnerships with EHRs with exclusive technical integrations are really at risk here.
“Similarly situated” is removed: ASTP eliminates the category altogether, citing its use to segment requestors by size or business model. The comparison is now binary: do you offer analogous access to anyone else or not?
Taken together, these changes eliminate most of the interpretive slack that made the condition useful as a defensive tool rather than a true last resort.
But the ASTP goes further! They explicitly float the option of removing the manner exception exhausted condition entirely if commenters indicate that the revised version would still permit abuse. This would still allow for negotiation of manner, but force denials to rest solely on security, performance, feasibility, or other exceptions.
RPA Legalized
In the same/analogous section, the agency explicitly notes that automated access, RPA, and agentic systems. It’s worth including in full:
Similarly, the manner exception exhausted condition (as § 171.204(a)(4) is currently codified or as we propose in this proposed rule to modify it) would not be available to an actor if the actor makes an API available to entities or individuals and a requestor attempts to access the API through automated means (such as robotic process automation and agentic AI).76 In such cases, the access achieved by automated means would be the same and analogous to an entity or individual accessing the API using more manual means. Accordingly, we believe replacing “the same” with “analogous” is a better basis for comparing the request with what the actor provides to other individuals or entities, including those who may use different automated means, or may use manual means. We believe this revision aligns more with the intent of the statutory information blocking definition (PHSA section 3022(a)(1)), which focuses on practices “likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information” without any specification of, or limitation to, access, exchange, or use of EHI through particular mechanisms, technologies, or workflows.
Said more simply (as I am a simple man): If a human user is permitted to view, retrieve, or write data in an EHR, an actor cannot avoid its access obligations simply because the same interaction is performed by software acting on that user’s behalf.
The arc is now explicit and everything we’ve been talking about ad nauseum is black-and-white. Information blocking involves the superset of the circles:
This doesn’t bless unrestricted automation, but it gets close! What it does do is remove a common loophole: treating automation itself as the reason for denial. If access is permitted manually under provider authorization, the burden shifts back to the actor to justify an exception for such - not on the fact that “a machine is doing it.”
Manner Exception
Under the original Cures Act framework, the Manner Exception served two related functions. First, it allowed actors to decline a specific technical approach requested by a requestor if it was not feasible or agreeable, so long as the actor offered reasonable alternative technical manners for fulfilling the request.
Second (and more controversially), it created a special carve-out for fees and licensing when the actor fulfilled a request in the exact manner requested. In that narrow case, fees and licensing tied to the requested manner were not required to comply with the Fees Exception or the Licensing Exception.
Suppose you’ve received care at Dr. Brendan Keeler’s Fun Fun Adventure Clinic and want to request your records under your HIPAA Right to Access. You are eccentric (you’re reading this newsletter, so highly likely) and decide that handwritten records delivered by carrier pigeon are the best manner by which to receive that. You request that from my Fun Fun Clinic.
At that point, I have two options under the Cures Final Rule:
I can respond in the manner requested. In this case, I can actually charge you a fee outside of the Fees Exception (i.e. charge you whatever I want), which sorta makes sense - carrier pigeons are expensive, and likely my clinic has not exercised that particular communication muscle recently. (Note: this is not an invitation to make some trendy NYC carrier pigeon startup)
Alternatively, I can say “no, I’m technically unable to fulfill the request, carrier pigeons went out of vogue around World War II and are low-key a form of animal exploitation, so let’s do something different.”
The theory was that this carve-out would preserve market-based negotiation for technically specific access. Actors could attempt to reach agreement on the requested manner at market rates, and if negotiations failed, they could fall back to alternative manners that would be subject to the Fees and Licensing Exceptions. In effect, the rule treated the requested manner as a space for voluntary, arm’s-length bargaining, and alternatives as the regulated backstop.
Flexibility for actors to negotiate how access happens (API vs file, content + transport, etc.)
Market negotiation so actors could charge for value-added technical work without every fee being second-guessed
However, ASTP is seeing that the exception is being abusing by some actors to smuggle in bad contracts:
Non-market pricing: Charging fees that exceed fair market value due to leverage over EHI access rather than the actual cost or value of the technical service provided.
Take-it-or-leave-it contracts: Conditioning access to EHI on acceptance of non-negotiable, standardized contract terms where the requestor has no realistic alternative source of the data.
Unconscionable terms (IP grabs, extreme indemnification, gag clauses, revenue share, etc.): Imposing excessive or unfair contractual provisions that use EHI access to extract unrelated rights, shift unreasonable risk, silence oversight, or claim downstream economic value.
In response, ASTP is proposing two paths to rein in this behavior.
Constrain the requested manner carve-out: ASTP would keep the existing structure of the Manner Exception, but sharply limit the requested manner carve-out by defining “fair market value”, “contract of adhesion”, and “unconscionable terms”. This preserves some negotiated flexibility, but adds complexity by creating a bespoke rule set that applies only to the requested manner.
Eliminate the carve-out entirely: ASTP would remove the requested-manner carve-out altogether, requiring all fees and licensing (regardless of manner) to comply with the Fees and Licensing Exceptions. This collapses the Manner Exception back to its core role: governing technical implementation, not pricing or contractual leverage.
It seems obvious to me that option 2 is the right one. Look, if we’re getting into the “fairly socialist for a conservative administration” business of price setting and contract policing, we might as well be simple about it to at least be deregulatory. We don’t need two sets of rules - applying the Fees Exception uniformly seems to be the right path. I’m curious to track comments here, though!
Other Exception Removals
HTI-5 proposes removing the TEFCA-specific Manner Exception entirely. Participation in a federally blessed exchange framework does not insulate actors from information blocking scrutiny.
The TEFCA Manner Exception (introduced in HTI-1) functioned as a kind of regulatory gold card. If an actor could point to TEFCA participation as the offered manner, that was often treated as presumptively reasonable, even if it did not meet the requestor’s actual needs.
The changes here are at least another sign of the mixed support and slightly more ambivalent posture this administration has towards TEFCA. The Biden administration under Micky Tripathi pulled every regulatory lever and statutory authority they could reach in order to jump-start network effects. ASTP’s stated view now appears to be that TEFCA no longer requires that kind of catalyst. In the preamble, the agency frames the removal as a maturation decision: TEFCA is implemented, operational, and widely understood. It no longer needs a special safe harbor layered into the information blocking framework. It’s one of the many “mission accomplished” justifications that are used throughout the rule.
My general take is that they typically provide air cover for the real reasons for removal or revision. In this case, the more plausible explanation is that TEFCA participation has increasingly been used as a categorical defense: a way to short-circuit the substantive inquiry into whether access was actually enabled. HTI-5’s broader pattern is to strip away exactly those kinds of badges and presumptions.
Beyond that, what makes the TEFCA cut especially notable is what wasn’t cut. Many expected HTI-3’s Protecting Care Access Exception to be an early casualty. Unlike most health IT policy, this exception sits squarely in partisan terrain, having been designed to allow withholding of EHI in certain reproductive health care contexts. From the outside, it looked politically vulnerable in a deregulatory rulemaking under a conservative administration.
But HTI-5 leaves it intact! In doing so, it undercuts the idea that HTI-5 is simply about rolling back the last administration’s work. Instead, the pattern is more nuanced and more targeted. ASTP is not cutting exceptions because they are politically inconvenient. It is cutting or narrowing areas it believes have become outdated, burdensome, or obstructionist. The TEFCA Manner Exception fits that description. Protecting Care Access, whatever one thinks of it substantively, does not appear to have generated the same pattern of strategic misuse.
Although there are a few culture war elements to the rest of the rule, I appreciated the relative discipline here. HTI-5 largely resists the temptation to relitigate controversial policy choices for their own sake, and instead focuses on where the regulatory machinery itself has stopped working as intended. In a rule this sprawling (and in a political environment this charged), that restraint is notable.
Severability
HTI-5 includes a belt-and-suspenders severability section, which is not in and of itself unique - many government rules include a generic statement that if one provision falls, the rest should stand.
HTI-5 goes beyond boilerplate severability. ASTP includes operational hypotheticals describing how judicial invalidation of specific provisions should not destabilize the rest of the rule. That level of specificity seems like a tell: the agency is drafting with anticipated, clause-by-clause litigation in mind.
The ASTP appears to be anticipating challenges in three main areas:
Removal of certification criteria, where developers may argue that downstream obligations collapse without the upstream requirement
Specific conditions within the Infeasibility Exception, particularly those being narrowed or removed
Cross-references to the Manner Exception, where challengers may try to argue that striking one element destabilizes the rest of the information blocking framework
That expectation is entirely reasonable.Information blocking enforcement inherently lives at the intersection of technical feasibility, commercial negotiation, and legal interpretation. As HTI-5 tightens standards and removes discretionary off-ramps, disputes between counterparties are almost guaranteed to migrate into formal complaints and, eventually, courtrooms. So this unique severability section is ASTP’s way of preemptively fencing off the blast radius.
Certification Criteria
The ASTP has a table of what’s proposed to be removed or revised. At a high level, the proposed cuts cluster around a small set of recurring principles:
Not effective: criteria that failed to change behavior or improve interoperability outcomes
Not adopted: requirements with persistently low uptake despite years of certification pressure
Deregulate UI: backing away from certifying end-user workflows, screen-level behaviors, and UI affordances, and toward regulating data availability and access surfaces instead
Anything CDA-related: legacy document-centric artifacts that no longer align with the API-first direction of travel
“Free market” FHIR: areas where ASTP appears willing to let implementation and evolution occur without prescriptive certification guardrails
Punt to CMS: requirements better enforced through payment programs or operational policy rather than health IT certification
AI enablement: clearing away any regulation of AI where possible to allow for innovation
Culture wars: politically charged areas where certification has become a proxy for broader ideological disputes
I’ve extended that a bit and added some color commentary in the chart below. For a more in-depth review of each cut or revised criteria, check out the full thread on Twitter here.
While the criteria body count is admirable, the ASTP didn’t go as far as I thought they would, quite honestly:
The order entry criteria all seemingly fall into the “ubiquitous capability - mission accomplished” category, as 417 products are certified to one or more. These requirements focus on end-user functionality and workflow behavior rather than data access surfaces. In a rule that repeatedly signals a shift away from certifying what users can do and toward how data is accessed, I’m surprised it was kept.
Social, psychological, and behavioral data have less ubiquity, but easily could be lumped into the same rationale as “Family health history” and “Implantable device list”. These data elements are well understood, widely supported in practice, and no longer meaningfully advanced by continued certification enforcement, while their “backend” is supported by their inclusion in USCDI, where standardized representation and exchange expectations persist independent of end-user workflow certification
View, Download, and Transmit is only lightly revised! I was sure this was a goner. Patient access is now driven far more by API-based access requirements, information blocking enforcement, and app-based workflows than by prescriptive portal functionality. Continuing to certify VDT feels like holding onto a Meaningful Use artifact long after its policy work has been absorbed elsewhere in the stack. It's also a CDA oriented criteria so it's another reason it felt dead in the water! My only guess is that it's because this administration is all about patient access and doesn't want to remove any route to such, even if it's superseded by newer patterns and yoked to older standards.
Public health criteria are inconsistent. For those looking closely, they remove or revise all the CDA public health criteria (cancer registries, case reports, antimicrobial use, and surveys) to promote FHIR, but keep all the HL7v2 ones (lab ORUs, immunizations VXUs, and syndromic surveillance ADTs). It’s weird to go so hard after CDA formats as legacy, but be totally okay with keeping HL7v2 around. If we’re going all in on FHIR, let’s take the big shots.
Conclusion
Circling back to our metaphor: any reports of ASTP’s death were greatly exaggerated. The scorpion is very much alive, swimming just fine. Frankly, I’m pumped. It’s good to see our fearless health tech regulators back in action, and I genuinely can’t wait to see what HTI-6 brings
However, suffice to say, the EHR Association did not get everything they wanted. While the operational and procedural changes will benefit them, many big ticket items were left out:
EHI Export and Bulk FHIR were not touched: EHRA has consistently argued very explicitly for portability obligations to be scoped narrowly and exercised sparingly tied to specific use cases. I don’t think that will change. As UI- and workflow-centric certification is pared back, these requirements increasingly function as the non-negotiable backstops.
TEFCA was not elevated, but demoted: EHRA urged ASTP to reinforce TEFCA as a unifying national framework. HTI-5 removes TEFCA’s Manner Exception “gold card,” making participation infrastructure, not immunity.
Information blocking exceptions were tightened: EHRA explicitly asked for simplification and reduced compliance burden around information blocking exceptions. HTI-5 does the opposite: narrowing definitions, collapsing ambiguity, and floating full deletion of the Manner Exception Exhausted condition.
There’s also another shoe waiting to drop, too. The messaging from the ASTP is clear that they are not done:
As discussed in this deregulatory proposed rule, we propose to aggressively reduce and remove long-standing functionality-oriented and non-FHIR-based certification criteria from the Certification Program. While this approach would directly and rapidly reduce compliance burdens for health IT developers that participate in the Certification Program, more broadly, it enables ASTP/ONC to reset the Certification Program’s regulatory scope and establish a new foundation on which to build FHIR-based API requirements in the future
Later, they hint at capabilities they are thinking about:
Finally, we believe that FHIR supports easier scalability to support real-time data exchange, which will support a broader ecosystem of health IT tools than C-CDA. Various capabilities, such as CDS Hooks, Subscriptions, and SMART Health Links, support new interoperability paradigms that are much more difficult to do using C-CDA.
We are firmly in the “cut” cycle, but make no mistake - ASTP intends to bulk up again this spring. Legacy, workflow-oriented requirements are being cleared out to make room for a new generation of FHIR-native, event-driven, real-time capabilities.
EHR vendors should prepare to shoulder a different kind of burden: fewer UI mandates and document artifacts, but more API depth, operational rigor, and machine-facing interoperability obligations. The scaffolding is coming down, but the next structure is already being sketched.
Health API Guy is a reader-supported publication. To receive new posts and support my work, consider becoming a paid subscriber.
