ONC/ASTP certification & the Cures Act
How the 21st Century Cures Act reshaped US health IT: the voluntary certification program, certified EHR technology, the Conditions of Certification, and the HTI rules that keep changing the criteria.
In one line
The United States does not certify hospitals' software choices, it certifies products: a voluntary federal program says what an EHR must be able to do, and federal payment programs then quietly make that certification compulsory in practice.
Who runs it, and what it is called now
The program lives at the Assistant Secretary for Technology Policy / Office of the National Coordinator for Health Information Technology — ASTP/ONC. HHS reorganised its technology functions and renamed ONC in July 2024; the office kept the National Coordinator role and picked up broader HHS data, technology and AI policy. You will still see "ONC" everywhere, including in the regulation text and in the program's own name (the ONC Health IT Certification Program). Both names refer to the same office. If you are writing for a US audience in 2026, "ASTP/ONC" is the safe form.
The program's rules sit in 45 CFR Part 170. Certification criteria are enumerated at
§ 170.315 — each one a lettered paragraph like (b)(1), (g)(10).
The Cures Act is the engine
The 21st Century Cures Act (Public Law 114-255) was signed on 13 December 2016. Three sections of Title IV drive almost everything a health IT developer deals with today:
| Section | Subject | What it produced |
|---|---|---|
| § 4002 | Transparent reporting on usability, security and functionality | The Conditions and Maintenance of Certification a developer must keep meeting after the certificate is issued |
| § 4003 | Interoperability | TEFCA — the Trusted Exchange Framework and Common Agreement |
| § 4004 | Information blocking | 45 CFR Part 171 and the exceptions regime |
The Cures Act also gave the phrase that shows up in every API argument: certified health IT must let electronic health information be accessed, exchanged and used without special effort. That is the legal hook underneath the patient-facing FHIR API.
Certification, in practice
- ONC-ATLs (accredited testing laboratories) test the product against the criteria.
- ONC-ACBs (accredited certification bodies) issue the certification.
- Results are published on the Certified Health IT Product List (CHPL) — a public register you can search before you buy, integrate with, or write a claim against.
Certified EHR technology (CEHRT) is the shorthand for a product certified to the criteria a given CMS programme requires. Certification is voluntary; participation in Medicare's Promoting Interoperability programme and the MIPS Promoting Interoperability category is not, if you want the money. That is how a voluntary program becomes the floor.
Two criteria matter disproportionately to anyone building on top of an EHR:
- § 170.315(b)(1) — transitions of care, the C-CDA document export path.
- § 170.315(g)(10) — standardized API for patient and population services. This is the
criterion that forces a FHIR endpoint, US Core profiles and SMART app launch into every
certified EHR in the country. If you have ever launched a third-party app inside Epic or
Cerner without a bespoke contract,
(g)(10)is why.
The HTI rules
Since 2023 ASTP/ONC has updated the program through a numbered series of Health Data, Technology, and Interoperability (HTI) rules. Know what each one did, because vendors quote them constantly:
| Rule | Status | Subject |
|---|---|---|
| HTI-1 | Final, published in the Federal Register 9 Jan 2024 (effective 11 Mar 2024) | Certification Program Updates, Algorithm Transparency, and Information Sharing |
| HTI-2 | Final, 16 Dec 2024 | Trusted Exchange Framework and Common Agreement; information blocking amendments; program corrections |
| HTI-3 | Final, 17 Dec 2024 | Protecting Care Access — a new information blocking exception |
| HTI-4 | Final, 4 Aug 2025 | Electronic prescribing, real-time prescription benefit, electronic prior authorization criteria |
| HTI-5 | Proposed — comment period 29 Dec 2025 to 27 Feb 2026 | Deregulatory: proposes removing more than half the certification criteria, revising information blocking, modernising FHIR APIs |
HTI-1 is the one to internalise. It:
- adopted USCDI v3 as the certification baseline from 1 January 2026;
- adopted US Core 6.1.0 at § 170.215(b)(1)(ii) and made SMART App Launch v2 the only version usable in the program from 1 January 2026 (v1 was available through 31 Dec 2025);
- created the Decision Support Interventions criterion, the first federal transparency requirement for predictive algorithms shipped inside certified health IT — developers must publish "source attributes" so a clinician can judge whether the model is fit for their patients;
- created the Insights Condition, a reporting obligation on certified developers.
HTI-5 is still a proposal at the time of review. Do not design around it, but do read it — it signals where the program is heading, including a proposal to remove the TEFCA Manner Exception from the information blocking rules.
Why you should care
If you build clinical software for the US market, certification decides your integration surface. The criteria tell you which FHIR version, which profiles, which auth flow and which data classes you can rely on being present in any certified EHR. If you code or bill, CEHRT status is what makes a provider eligible for Promoting Interoperability credit, and the same rules define what "blocking" a records request means. Start at the CHPL, then read the criterion, then read the implementation guide the criterion points at.