ONC finalized the first part of its HTI-5 rule, scaling back its proposed EHR deregulation (still waiting to see what lands re: AI Agents + Info blocking). See article for what was cut or deferred, and how it compares to our SMART Health IT comment letter. https://x.com/i/article/2114832573381713920
HTI-5 Final Rule Keeps 20 EHR Criteria Slated for Repeal and Punts on Information Blocking
TL;DR: ONC’s HTI-5 final rule cuts EHR certification far less than proposed, removing 14 of 34 targeted criteria while keeping core security, safety, and public health rules. It drops AI model disclosures, scales back public testing and usage reporting, and delays the C-CDA sunset to 2030. The information-blocking and AI-agent decisions wait on a follow-up final rule. From our SMART letter, ONC kept Bulk FHIR usage reporting but dropped testing and reporting on EHI Export.
ONC has finalized the first piece of its HTI-5 deregulatory rule, keeping 20 of the 34 EHR certification criteria it proposed to eliminate and deferring every proposed change to the information-blocking regulations. Below is what survived, what was cut or loosened, and how the final text compares with the February 2026 comment letter that Dan Gottlieb, Ken Mandl, and I submitted for the SMART Health IT team.
Background on ONC certification
Within the Department of Health and Human Services, the Office of the National Coordinator for Health Information Technology (ONC) runs a voluntary certification program for electronic health record (EHR) software. Most vendors serving U.S. hospitals and physician practices certify their products because providers need certified software to participate in Medicare’s Promoting Interoperability program and avoid Medicare payment penalties.
The program regulates at two levels: certification criteria §170.315, which are specific software capabilities a product must demonstrate (such as sending a referral summary or letting a patient connect a smartphone app), and conditions of certification §§170.401–407, which are ongoing obligations on the vendor (such as testing features in clinical use and reporting usage metrics).
Where previous ONC rules mostly added requirements, the December 2025 HTI-5 proposed rule was written to subtract them. ONC proposed eliminating 34 of its 60 certification criteria and scaling back several vendor oversight rules, arguing that older requirements had served their purpose and that certification should center on FHIR web APIs.
Part 1: What the final rule changes
After pushback from hospitals, clinicians, public health agencies, and security commenters, ONC kept 20 of the 34 criteria it had proposed to cut and extended the transition off document-based exchange by three years, to January 1, 2030.
- 14 criteria removed (out of 34 proposed for removal)
- 7 criteria revised (6 loosened, 1 expired-date cleanup)
- 39 criteria kept unchanged
- $108M estimated annual vendor savings (ONC's figure)
Information-blocking proposals were deferred
ONC states that this rule acts on a narrowed set of proposals while the rest of HTI-5 remains under review. None of the proposed changes to the information-blocking rules 45 CFR Part 171 were finalized here. That leaves two closely watched proposals unaddressed: clarifying that automated AI agents count as legitimate users of health data, and removing the TEFCA Manner Exception so vendors and providers cannot use participation in the federal TEFCA network to refuse direct FHIR API requests. Both could appear in a subsequent final rule or be dropped.
Proposed removals that ONC kept
Twenty of the 34 criteria ONC proposed to eliminate remain in the final rule (18 unchanged and 2 in simplified form), and one proposed revision to public health reporting was withdrawn.
All 13 privacy and security safeguards (d)(1)–(13) §170.550(h)
ONC had proposed to eliminate all 13 privacy and security criteria, arguing that the HIPAA Security Rule already covers security. Commenters overwhelmingly objected that certification is the only way buyers, especially small and rural providers, can verify that user authentication, access controls, audit logs, automatic log-off, encryption, and multi-factor authentication are actually built into a product before purchase, and warned that vendors might otherwise drop them. ONC kept all 13 criteria unchanged for now and said it will revisit privacy and security certification in future rulemaking.
Implantable device tracking (a)(14)
EHRs must still record and display Unique Device Identifiers (UDIs) for implanted devices such as pacemakers and artificial joints. ONC retained the criterion unchanged and kept it in the Base EHR definition required for Medicare programs so patients can be identified during device recalls.
Medication, allergy, and problem reconciliation (b)(2)
Originally proposed for removal, this capability was retained as a functional-only requirement. Certified EHRs must still let clinicians merge outside medication, allergy, and problem lists into a patient’s active record during care transitions or other clinical workflows, but ONC dropped the requirement to use the C-CDA document format or display a side-by-side manual comparison screen, allowing more automated reconciliation tools.
Public health case, cancer, and survey reporting (f)(4), (f)(5), (f)(7)
ONC withdrew its proposal to eliminate cancer-registry reporting (f)(4) and National Health Care Surveys reporting (f)(7) after public health agencies warned that no FHIR replacement is ready at scale. For electronic case reporting of outbreaks and reportable diseases (f)(5), ONC also withdrew its proposal to strip out technical data standards, keeping both the HL7 FHIR and CDA standards in place.
Safety-enhanced design and quality management (g)(3)–(5)
Commenters objected on patient-safety grounds to removing these three criteria, and ONC retained all three. Vendors must still maintain a quality management system (g)(4), design with accessibility in mind (g)(5), and apply user-centered design to high-risk clinical features such as medication ordering (g)(3). On (g)(3), ONC reduced the reporting burden: vendors no longer submit detailed usability test data from clinical test participants and instead attest to which user-centered design process they applied.
Criteria removed from certification
Fourteen criteria are eliminated: seven take effect 60 days after publication (around December 28, 2026) and seven on January 1, 2027. Removing a criterion does not require vendors to disable a feature, but they no longer have to certify it and can modify it, unbundle it and charge extra, or retire it. ONC’s rationale is that these capabilities are either universal commodity features or superseded by FHIR APIs.
Legacy app-connection APIs (g)(7), (g)(9)
Removed January 1, 2027. These 2015-era criteria required EHRs to let outside apps look up a patient and pull a summary document. Because the standardized FHIR API criterion (g)(10) already covers app connections using SMART on FHIR, SMART on FHIR becomes the sole certified pathway for patient and clinician apps.
Standalone Direct secure messaging (h)(1), (h)(2)
Removed 60 days after publication. This deletes the standalone certification tests for Direct secure email, though sending and receiving care summaries over Direct and related edge protocols remains required under the care-transitions criterion (b)(1) until January 1, 2030. ONC noted that Direct is already standard across the industry.
Document privacy tags and care plans (b)(7)–(9)
Removed 60 days after publication. Ends certification for sending and receiving C-CDA documents with security and privacy tags (b)(7), (b)(8) (used to flag sensitive records such as substance-use treatment) and for creating standardized C-CDA care-plan documents (b)(9). ONC concluded that these document-based approaches had implementation problems and could be ineffective, and said it plans to address granular consent and sensitive-data segmentation in future FHIR-based rules.
Recording patient-provided documents (e)(3) and family history (a)(12)
Removed January 1, 2027. Eliminates the requirement that an EHR provide a certified workflow to record unstructured patient-supplied documents (such as a scanned advance directive) (e)(3), and the requirement to record family health history using standard clinical codes (a)(12).
Quality-measure filtering, Medicare calculators, and C-CDA lab test (c)(4), (g)(1), (g)(2), (g)(6)
Removes three reporting-support tools on January 1, 2027: filtering clinical quality measures by payer, clinician, or patient demographics to identify care gaps (c)(4), and the built-in calculators that compute numerators and percentages for Medicare’s Promoting Interoperability program (g)(1), (g)(2). Also removes, 60 days after publication, a standalone C-CDA document-creation lab test (g)(6) and the already-expired 2015 clinical decision support criterion (a)(9).
Criteria narrowed or loosened
Alongside the two criteria above that were loosened rather than eliminated ((b)(2) reconciliation and (g)(3) safety design), ONC revised five other criteria.
Document-based care transitions (b)(1)
This criterion covers creating, displaying, and sending/receiving C-CDA care summaries, including over Direct and related edge protocols. ONC had proposed to drop almost all of it on January 1, 2027, leaving only a check that incoming C-CDA files are properly formatted. The final rule adopts that narrowing but delays the sunset to January 1, 2030, giving hospitals and vendors three additional years to move care transitions to FHIR. After 2030, certified EHRs must still validate incoming C-CDA documents (b)(1)(ii)(A).
AI model disclosures and clinical decision support (b)(11) §170.402(b)(4)
Under the 2024 HTI-1 rule, EHR vendors offering predictive decision-support tools (including AI models) had to display detailed source-attribute disclosures covering how a model was trained, its intended use, its performance across patient groups, and the vendor’s risk-management practices, with annual reviews. HTI-5 eliminates all of those transparency, risk-management, and annual review requirements.
The rule also eliminates source-attribute disclosures (such as clinical citations and funding sources) for traditional rule-based alerts; narrows the patient data that predictive tools must be able to draw on to a defined clinical subset plus clinical notes and treatment plans (rather than all of USCDI); drops requirements to trigger alerts specifically when reconciling a care-transition summary; and removes an explicit reference to drug-drug and drug-allergy checking from the decision-support selection requirement.
ONC argued that clinicians rarely relied on the disclosures and pointed instead to industry frameworks and FDA oversight. Many hospital and clinical commenters objected that removing standardized disclosures shifts the burden and legal risk of vetting AI tools onto individual health systems. ONC noted it may reconsider source disclosures for rule-based alerts in a future rule.
Patient portal standards (e)(1)
The patient portal criterion (view, download, and transmit) still requires portals to let patients view and download their records, but ONC removed the certification checks for the WCAG 2.0 web-accessibility standard and for a clock-synchronization standard on activity logs. Most commenters opposed dropping the accessibility check; ONC responded that covered health care providers remain bound by the ADA, Section 504 of the Rehabilitation Act, and Section 1557 of the Affordable Care Act.
Antimicrobial use and resistance reporting (f)(6)
Converted to a functional-only criterion. Certified EHRs must still generate antimicrobial use and resistance reports for electronic transmission to the CDC’s National Healthcare Safety Network, but the older CDA document standard is no longer required because it no longer matched current CDC specifications.
Clinical quality measure report file (c)(3)
Administrative cleanup only: deletes an expired pre-2023 transition clause with no change to current requirements.
Changes to ongoing vendor obligations
HTI-5 also cuts back the public testing and usage reporting required of EHR vendors each year.
Real World Testing narrowed to APIs §170.405
Vendors no longer submit annual Real World Testing plans, and they file public annual results reports for only four API criteria: the standardized FHIR API (g)(10) and the three provider-to-payer prior-authorization APIs adopted in the 2025 HTI-4 rule (g)(31)–(33).
Non-API features (including care-transition documents, public health reporting, and full-record EHI Export (b)(10)) must still be tested internally each year, and vendors must report any non-conformities they find to their certification body within 30 days. Without a public results report for those features, however, customers, researchers, and regulators lose their annual view into how they perform in production. A majority of commenters opposed narrowing public reporting; ONC finalized it as proposed. (In a drafting mismatch, the preamble says ONC dropped a proposed requirement to list voluntary standards updates in RWT results for non-API features, but that clause remains in the regulatory text at §170.405(b)(2)(iv).)
Insights usage reporting cut from seven measures to two §170.407
ONC eliminated five measures before reporting ever began: patient record access rates, clinical document reconciliation rates, the count of distinct applications supported by a vendor’s APIs, and two immunization-exchange measures.
Two measures survive. First, vendors must report FHIR API traffic in apps, stratified by user type (such as patient vs. clinician) and FHIR data resource starting in July 2027, and by version of the US Core FHIR specification (which implements USCDI) starting in July 2028. Second, reversing its proposal, ONC kept the Bulk FHIR usage measure, with first reports pushed from July 2028 to July 2029. A vendor reports for a given year only if its product held active certification on January 1 of the data-collection year and remains certified when reports are due the following July (otherwise it files an ineligibility attestation).
Base EHR definition and product list updates §170.102 §170.523
The Base EHR definition sets the core bundle of certified capabilities that hospitals and clinicians need to participate in Medicare’s Promoting Interoperability program. It drops the removed legacy app-access (g)(7), (g)(9) and Direct (h)(1), (h)(2) criteria while keeping the implantable device list (a)(14), clinical decision support (b)(11), care transitions (b)(1), and the FHIR API (g)(10). (The Base EHR change takes effect 60 days after publication, a few days before (g)(7) and (g)(9) expire on January 1, 2027.) ONC also deleted the obsolete Common Clinical Data Set definition, leaving USCDI as the sole baseline, and stopped requiring certification bodies to post test-data version details on the public product list.
Public FHIR endpoint directories retained §170.404
One vendor asked ONC to stop requiring vendors to publish machine-readable lists of their customers’ FHIR server addresses (endpoints), arguing the list exposes its customer roster to competitors. ONC rejected the request, noting that public endpoint lists are needed for patients and apps to connect without manual setup.
Agency name restored
Following an April 2026 HHS reorganization that restored the Office of the National Coordinator for Health Information Technology (ONC) name, the rule removes regulatory references to ASTP (Assistant Secretary for Technology Policy).
Next rulemaking: RIN 0955-AA10
ONC frames HTI-5 as clearing space for a FHIR-first certification program. The preamble previews a separate upcoming rulemaking (RIN 0955-AA10) focused on expanding standardized APIs across performance and automation, writing data into the EHR (rather than mostly reading data out), and a wider clinical and administrative scope covering public health and quality reporting. ONC specifically notes newer AI integration protocols, such as the Model Context Protocol (MCP) for connecting AI models to tools, as layers that can build on top of FHIR.
Part 2: How our SMART Health IT comments fared
In February 2026, Dan Gottlieb, Ken Mandl, and I submitted comments on the HTI-5 proposal on behalf of the SMART Health IT team at Boston Children’s Hospital. We backed ONC’s shift toward FHIR APIs and trimmer certification rules, but argued that deregulation had to preserve visibility into whether APIs work in the field and prevent vendors from pricing automated tools out of access.
1. Retaining Bulk FHIR usage reporting (Won, in part)
What we argued. Bulk FHIR exports data for thousands of patients at once to support public health, quality measurement, and value-based care, yet production exports are often painfully slow. We urged ONC to keep Bulk FHIR in Insights reporting, tracking exports initiated, completion rates, and data volume.
What ONC finalized. ONC reversed its proposal and kept the Bulk FHIR measure §170.407(a)(3)(ii). Acknowledging that current Bulk FHIR performance “is suboptimal,” ONC cited three sources: a 2024 JAMIA study, a Trially blog post, and our Good Neighbor case study on Bulk FHIR for public health. First reports are due July 2029.
Remaining gap. The surviving metric requires vendors to report only how many bulk export requests completed and how many customer sites used bulk export. Because it omits failed requests, export duration, and data volume, it tracks whether Bulk FHIR is used rather than whether it performs reliably.
2. Measuring the app ecosystem (Mixed)
What we argued. Raw API call volume does not show whether a competitive market of third-party apps is emerging or whether traffic is concentrated in a few dominant integrations. We asked ONC to preserve both a count of distinct apps and a breakdown between patient-facing and clinician-facing traffic.
What ONC finalized. ONC kept the core FHIR app usage measure §170.407(a)(3)(i), including stratification by user type (patient, clinician, and other users), with first reports due July 2027, but eliminated the count of distinct applications supported by each vendor as overly burdensome.
Remaining gap. Without a count of distinct applications, Insights data will report total API call volume by user category without distinguishing a thousand apps generating a million calls from three apps generating the same million calls, which was the central competition question we raised.
3. Public testing of full-record export (EHI Export) (Not adopted)
What we argued. Standard FHIR APIs cover only the USCDI slice of a patient’s chart. Full-record EHI Export (b)(10) is the only certified path to the rest of the medical record, and in practice it is often manual and difficult to use. Earlier Real World Testing results had exposed those gaps, and we warned that dropping public testing would risk turning full-record access into a paper right.
What ONC finalized. ONC removed public Real World Testing results reporting for EHI Export §170.405. Vendors must still offer EHI Export and test it internally; ONC stated that certification-body surveillance and direct agency review provide sufficient oversight.
Our view. Standardized FHIR APIs continue to carry public annual test results while full-record EHI Export now has none. Losing public visibility into (b)(10) makes it more important for ONC’s next rulemaking to require a standardized, OAuth-authorized API for full EHI export.
4. Preventing extra fees on AI agents acting for users (Pending)
What we argued. We supported ONC’s proposal to clarify that automated tools and AI agents count as permissible actors under the information-blocking rules, but warned that vendors could still price agents out by treating the interfaces an agent uses as separately licensed products. We asked ONC to clarify that an agent acting for a clinician should be priced like that clinician (plus any actual cloud compute costs), and an agent acting for a patient should have free access just as the patient does.
What ONC finalized. Nothing in this rule. Because ONC deferred all information-blocking proposals 45 CFR Part 171, both the automated-access clarification and the licensing questions around it remain under review.
Preamble note on unbundled fees. Elsewhere in the HTI-5 preamble, ONC wrote that if vendors begin charging separately for software features removed from certification, customers gain “price transparency.” That framing of unbundled fees runs counter to our warning against letting standard interfaces become separate toll booths for automated tools.
5. Removing the TEFCA shield against direct API access (Pending)
What we argued. Under the current TEFCA Manner Exception §171.403, if both a requester and a data holder participate in the federal TEFCA network, the data holder can insist on fulfilling a request through TEFCA and decline a direct FHIR API connection. ONC proposed to eliminate that exception, and we supported removing it.
What ONC finalized. Deferred along with the rest of the information-blocking proposals. The TEFCA Manner Exception remains in force unless and until ONC issues a subsequent final rule removing it.
6. Forward-looking API agenda for HTI-5 or HTI-6 (Out of scope)
Our letter also proposed an architectural roadmap for either HTI-5 or ONC’s next rulemaking. For patient access, we recommended mandating portal-based single sign-on with remote identity proofing so patients can authenticate once and authorize access without repeated manual steps; giving patients access to medical imaging (both metadata and full diagnostic images) and full-record EHI through the same OAuth-based app authorization flows used for USCDI data (including a complete PDF medical record option); supporting dynamic app registration outside preconfigured trust networks; and enabling FHIR Subscriptions so apps receive notifications when new data arrive. For provider and population access, we called for stronger Bulk FHIR filtering and patient-organized exports, standard APIs to define patient cohorts, enforceable Bulk FHIR performance parity with proprietary export tools, and quarterly institutional reporting of real-world Bulk FHIR speed and failure rates.
ONC treated all requests for new certification requirements as out of scope for this deregulatory rule. Its summary of the public comments set aside for future consideration (covering API performance expectations, bulk data access and support, and endpoint discovery and onboarding) closely tracks our recommendations, and the preamble points to the planned FHIR rulemaking (RIN 0955-AA10) as the next venue for API requirements.
Bottom line
- Where our position prevailed: Insights usage reporting §170.407. Bulk FHIR is the only one of the six measures proposed for removal that ONC kept, and ONC cited our Good Neighbor case study directly in explaining why visibility into Bulk FHIR matters.
- Clearest loss from our perspective: ONC ended public Real World Testing results reports for full-record EHI Export (b)(10), leaving the non-FHIR portion of the medical record without public annual test reports.
- Still pending: every information-blocking proposal from HTI-5, including whether AI agents are protected against extra interface licensing fees and whether the TEFCA Manner Exception will be repealed. Watch for a second HTI-5 final rule or a re-proposal.
- Other certification shifts: retiring the 2015-era app criteria (g)(7), (g)(9) makes SMART on FHIR (g)(10) the sole certified app-connection standard, and ONC rejected a vendor push to hide public FHIR endpoint lists §170.404.
- Next rulemaking venue: ONC’s upcoming FHIR rule (RIN 0955-AA10), where our recommendations on Bulk FHIR performance verification, OAuth-authorized full-record and imaging APIs, portal single sign-on with remote identity proofing, and FHIR Subscriptions could be taken up.
Sources: FR 2026-21943 (public inspection) · SMART Health IT comments on the HTI-5 proposed rule · Good Neighbor bulk FHIR case study
Earlier posts on HTI-5: HTI-5: Deregulation, Rhetoric, and Architectural Gaps · HTI-5 Analysis: A Battle is Brewing Over AI Agents as EHR Users · Deregulation of Certified Health IT: Cuts to Real World Testing
Prepared Oct 26, 2026 from the public-inspection text. References such as (g)(10) refer to paragraphs of 45 CFR 170.315 or the CFR sections indicated.
Reference terms
FHIR (Fast Healthcare Interoperability Resources). The HL7 web-API standard for exchanging structured health records (such as active medications or recent lab results) rather than whole documents.
SMART on FHIR. The OAuth-based sign-in and app-launch specification on top of FHIR that lets a patient or clinician connect an external app to an EHR. Required in certified EHRs since 2022 (g)(10).
Bulk FHIR. A companion specification for exporting FHIR data on an entire patient population at once (for example, every patient in a clinic or health plan), used for quality measurement, public health monitoring, and value-based care.
USCDI and US Core. USCDI (United States Core Data for Interoperability) is the federal baseline list of clinical data classes (allergies, medications, labs, clinical notes) that certified EHRs must support. US Core is the FHIR implementation guide that maps USCDI to FHIR resources.
EHI Export (full-record export). A required capability (b)(10) for exporting all of a patient's electronic health information, including billing, specialty, and other records outside USCDI and standard FHIR profiles.
C-CDA and Direct. Document-based exchange standards. C-CDA is a structured care-summary document format; Direct is a secure email protocol used to transmit those summaries between clinics and hospitals during referrals and discharges.
Information blocking. Rules under the 21st Century Cures Act 45 CFR Part 171 prohibiting EHR vendors, health care providers, and networks from unreasonably interfering with access, exchange, or use of electronic health information.
TEFCA. The Trusted Exchange Framework and Common Agreement, a federally backed network-of-networks governance framework for nationwide health record exchange.
Real World Testing. An annual condition of certification §170.405 requiring EHR vendors to test that certified capabilities work in production customer deployments, not only in a certification lab.
Insights reporting. A reporting condition §170.407 finalized in 2024 and phasing in starting in 2027 that requires EHR vendors to report standardized metrics on production use of their certified APIs.
Standards-based vs. functional criteria. A standards-based criterion specifies both what the software must do and which technical standard it must use. A functional criterion requires the workflow capability without mandating a format.
Why the rule says "super intelligence". Following a September 2026 executive order (EO 14434), ONC's preamble replaces "artificial intelligence (AI)" with "super intelligence (SI)" throughout, including for ordinary clinical predictive models. This post uses "AI."