ONC Health IT Certification Program testing requirements

What does certification commit you to after the certificate is issued?

Testing is where the obligation starts. An ONC-Authorized Testing Lab tests a Health IT Module, an ONC-Authorized Certification Body issues the certification, and from that day subpart D of 45 CFR part 170, Conditions and Maintenance of Certification Requirements for Health IT Developers, binds the developer for as long as the certification is live. Subpart D runs to eight sections, from section 170.400 to section 170.407, Insights Condition and Maintenance of Certification.

section 170.405, Real world testing is the section that sets the calendar. It reaches a developer with any Health IT Module certified to a criterion in section 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), (g)(31) through (33), (h), and (j)(20) and (21), and it requires the developer to test the real world use of that Module for interoperability in the type of setting in which it is marketed. That list expands to 30 criteria against the current text of section 170.315, and the applicable list published on healthit.gov enumerates exactly those 30.

These are the dates that recur for as long as the product stays certified:

Recurring ONC Health IT certification obligations, from Real World Testing plans to record retention, with the section and timing of each.

What is due	Section	When
Real World Testing plan to the ONC-ACB	170.405(b)(1)	in time for the ONC-ACB to publish a CHPL hyperlink by December 15 each year
Real World Testing results report	170.405(b)(2)(ii)	in time for a CHPL hyperlink by March 15 each year
Non-conformity found during real world testing	170.405(b)(2)(i)	reported to the ONC-ACB within 30 days
Attestation of compliance with the Conditions	170.406(b)	semiannually
Service base URL bundle reviewed and updated	170.404(b)(2)	quarterly
Predictive DSI source attributes and risk practices reviewed	170.402(b)(4)	ongoing since 1 January 2025
Insights measure responses	170.407(b)(1)	annually, first measures from July 2027
Records demonstrating compliance retained	170.402(b)(1)	10 years from first certification

section 170.405(b)(1)(iii) fixes seven elements the plan has to carry for each criterion in scope: the testing methodology, the care settings tested and why those settings, how conformance will be demonstrated for any National Coordinator approved newer standard version, a schedule of key milestones, the expected outcomes, at least one measurement or metric, and a justification for the approach. It covers every Module certified to those criteria as of August 31 of the year the plan is submitted, addresses the calendar year that follows, and must be approved by a representative capable of binding the developer to execute it. The results report at section 170.405(b)(2)(ii) carries six elements, the same list without the justification, and reports what happened in place of what was expected.

One naming point before the criteria. The programme is the ONC Health IT Certification Program. The office was dually titled Assistant Secretary for Technology Policy and Office of the National Coordinator from 89 FR 60903 of 29 July 2024 until 91 FR 16204 of 1 April 2026 reversed that action and restored ONC as a singularly titled office.

Which criteria is the product tested against?

Section 170.315, ONC certification criteria for Health IT, is the backbone. It runs to ten paragraph letters, (a) through (j), of which (i) is [Reserved], and holds 60 numbered criteria that are not themselves reserved.

Paragraphs (a) to (j) of the ONC certification criteria, with each group name and its count of live criteria.

Paragraph	Group	Live criteria
(a)	Clinical	9
(b)	Care coordination	9
(c)	Clinical quality measures	4
(d)	Privacy and security	13
(e)	Patient engagement	2
(f)	Public health	7
(g)	Design and performance	12
(h)	Transport methods and other protocols	2
(j)	Modular API capabilities	2

Two changes have already moved under a scope written from that table. One of the 60 criteria has expired on its own terms: section 170.315(a)(9)(vi) states that the adoption of the clinical decision support criterion expires on 1 January 2025, and the live decision support criterion is (b)(11) Decision support interventions. Five further criteria were removed as time limited by the HTI-2 final rule and their paragraph letters now read [Reserved]: drug-formulary and preferred drug list checks at (a)(10), patient-specific education resources at (a)(13), data export at (b)(6), secure messaging at (e)(2), and application access-data category request at (g)(8). A scope inherited from a 2023 plan carries criteria that no longer exist.

The privacy and security set at section 170.315(d) is thirteen consecutive criteria with no reserved gaps, from (d)(1) Authentication, access control, and authorization to (d)(13) Multi-factor authentication. It is its own list, drawn up for certification rather than for the HIPAA Security Rule, so evidence prepared for one does not transfer to the other without a mapping. HIPAA testing requirements for software covers the safeguards side, and audit trail testing covers the evidence behind (d)(2), (d)(3) and (d)(10). Section 170.550(h)(2) allows a Module to be tested once to each applicable privacy and security criterion where the developer attests that the capability applies to the full certification scope, with a carve-out that forces a separate test to (d)(9) Trusted connection.

Section 170.102 pins which criteria a Base EHR has to hold: (a)(1), (2), or (3); (a)(5) and (14), (b)(1), (c)(1), and (g)(7), (9), (10); and (h)(1) or (2), plus (b)(11) on and after 1 January 2025 and (b)(4) on and after 1 January 2028. That definition is the usual starting scope for a records system, and EHR and EMR testing covers what else breaks in that class of product.

What does the API criterion at (g)(10) require?

Section 170.315(g)(10) Standardized API for patient and population services is where most of the testing effort lands, because it is a demonstration of running API technology rather than a document review. Its sub-paragraphs cover data response, supported search operations, application registration, secure connection, authentication and authorization, and then patient authorization revocation, token introspection, documentation and service base URL publication.

section 170.315(g)(10)(i)(A) is the sentence that decides the size of the test suite. A Module must respond to requests for a single patient's data according to the standards adopted in section 170.215(a) and 170.215(b)(1), including the mandatory capabilities described in the US Core Server CapabilityStatement, for each of the data included in section 170.213, and "all data elements indicated as 'mandatory' and 'must support' by the standards and implementation specifications must be supported." Paragraph (i)(B) repeats the requirement for multiple patients' data as a group, adding the bulk data specification at section 170.215(d).

The criterion does not stand alone. section 170.404 is the API Condition of Certification and applies to (g)(7) through (10) and (g)(31) through (33). It requires complete business and technical documentation published "via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps", authenticity verification of an API User completed within ten business days of a registration request, registration for production use within five business days of that verification, and service base URLs published as FHIR Endpoint and Organization resources collected into a Bundle and reviewed quarterly. Those clocks are testable, and they are where a surveillance question tends to start.

Section 170.550(h)(3)(viii) then maps (g)(7) through (10) onto the privacy and security criteria at (d)(1), (9), (12), and (13), and (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), or (d)(10). Three of the seven Insights measures at section 170.407(a)(3) are triggered by (g)(10) alone: applications supported through certified health IT, use of FHIR in apps, and use of FHIR bulk data access.

This page carries the versions the regulation names. The specification itself, its maturity model and its conformance machinery are covered in FHIR R4 conformance testing requirements, and the tooling in FHIR conformance testing tools.

What is tested, and what is only attested?

Not every criterion is exercised in a lab. The Certification Program Test Method is built from Test Procedures, Test Tools and Test Data, and each test procedure carries a grid of five testing components: Documentation, Visual inspection, Test Tool(s), Test Data, and SVAP. Visual inspection is most commonly a live demonstration of functionality that meets the criterion. Several criteria require no testing at all and instead require the developer to attest to meeting the requirements, with the ONC-ACB verifying the attested conformance. The programme's guidance says to consult the relevant test procedure to find out which criteria those are, so the answer for a given scope comes from the procedures rather than from the CFR text.

Certification Companion Guides bind. ONC publishes one per criterion, they do not undergo a formal public comment period, and health IT certified under the programme "must conform to the full scope of the product's required capabilities, including regulatory/conformance expectation clarifications and interpretations set forth in the applicable Certification Companion Guides." A test plan built from the CFR text alone is missing a layer of the conformance expectation.

The Test Method page carries a per-criterion table with 55 rows. Five criteria that exist in the current CFR have no row on it: (a)(9), whose adoption expired, plus (b)(4), (g)(32), (g)(33) and (j)(21). That is an observation about the page rather than a conclusion about those five criteria, and it is worth settling with the ONC-ACB before a schedule is built on them.

Which version of each standard applies right now?

Two separate acts govern this. A version is adopted in section 170.215 by rulemaking, and a newer version is approved for use in certification by the National Coordinator through the Standards Version Advancement Process at section 170.405. The FY 2027 IPPS rule states plainly that a version can sit in the regulation while the National Coordinator "has not approved version 2.1.0 for use in the ONC Health IT Certification Program".

FHIR Release 4.0.1 is the API base standard at section 170.215(a)(1), and it is the only release that paragraph names. For the rest of the (g)(10) stack:

Standards behind ONC criterion (g)(10), with the version named in the regulation set against the newer version approved through SVAP.

Standard behind (g)(10)	Version named in the regulation	Version approved through SVAP
US Core Implementation Guide	STU 6.1.0, section 170.215(b)(1)(ii)	STU 9.0.0, June 2026, 2026 SVAP Approved
USCDI	Version 3, October 2022 Errata, section 170.213(b)	Version 6, 2026 SVAP Approved
SMART App Launch	Release 2.0.0, section 170.215(c)(2)	Release 2.2.0, 30 April 2024, 2024 SVAP Approved
Bulk Data Access	v1.0.0: STU 1, section 170.215(d)(1)	v2.0.0: STU 2, 26 November 2021, 2022 SVAP Approved

US Core STU 3.1.1 is gone. Section 170.215(b)(1)(i) still prints it with the sentence that its adoption expires on 1 January 2026, and it no longer appears in the (g)(10) row of the approved SVAP versions table, which leaves STU 6.1.0 as the only US Core version named in section 170.215(b) that is in force. STU 9.0.0 of June 2026 became available for voluntary certification on 29 August 2026, alongside previously approved versions, and approved versions do not lapse between SVAP cycles.

USCDI has three simultaneous answers, and compressing them into one version number is how a roadmap goes wrong. Section 170.213 adopts USCDI v1, July 2020 Errata, whose adoption expired on 1 January 2026, and USCDI v3; v2 is adopted nowhere in part 170. The 2026 SVAP cycle approves USCDI v6 for voluntary use from 29 August 2026 against (b)(1), (b)(2), (b)(11), (g)(9) and (g)(10). ONC states separately that, consistent with EO 14168 and OPM guidance, it "is exercising enforcement discretion and issuing certification guidance for conformance to the USCDI v3 standard." The regulation says v3, SVAP permits v6, and conformance to v3 is itself under enforcement discretion.

One more version change is already dated. The FY 2027 IPPS/LTCH PPS final rule, 91 FR 49570 of 4 August 2026, revises section 170.215(j), (k), (m) and (n) effective 1 October 2026, moving the Da Vinci prior authorization guides to CRD 2.2.1-STU 2.2, DTR 2.2.0-STU 2.2 and PAS 2.2.1-STU 2.2, moving CARIN for Blue Button to 2.2.0-STU 2.2, and adding a new (k)(3) for Clinical Data Exchange at CDex 2.1.0-STU 2.1. The eCFR prints a link to that amendment at the head of section 170.215. It does not touch paragraph (a) or paragraph (b)(1), so the FHIR and US Core versions above are settled rather than pending.

What is currently not being enforced?

The rule text and what ONC says it expects have come apart on Real World Testing, and the two have to be read side by side.

ONC Real World Testing: what section 170.405 requires set against what ONC says it expects developers to submit for now.

What section 170.405 requires	What ONC says it expects for now
An annual plan submitted so the ONC-ACB can publish a CHPL hyperlink by December 15	For CY 2025, a developer is not expected to submit a plan for the 2026 Real World Testing year
An annual results report so the ONC-ACB can publish a CHPL hyperlink by March 15	For CY 2026, only a developer with a Module certified to the (g)(7) through (10) criteria as of 31 August 2024 is expected to submit a CY 2025 results report by March 2026

Nothing in the left column has been amended. Enforcement discretion is a statement about what ONC expects to receive, ONC dates its own notice to 30 June 2025, and the SVAP page adds that the discretion changes no SVAP requirement in either direction.

HTI-5 is also where the criteria list itself is under review. It proposes to fully remove the artificial intelligence model card requirements from the decision support interventions criterion, and states that ONC intends to retain and make no changes to 19 certification criteria. Until it is final, every criterion in section 170.315 is live and every one of them is a candidate for change.

Which parts of the regulation contradict each other?

Five, as the text stood on 31 August 2026, quoted as found rather than tidied up. They matter because a test plan that resolves one of them silently has made a decision the ONC-ACB never agreed to.

• Section 170.406(a)(5), the attestation cross-reference to Real World Testing, lists only section 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h). Section 170.405(a) itself also reaches (g)(31) through (33) and (j)(20) and (21).
• Section 170.550(e) cites "Sec. 171.405(b)(7) or (8)". The Standards Version Advancement Process paragraphs are at section 170.405(b)(8) and (9).
• Section 170.550(h)(2)(ii) still carves out a separate test for a Module presented to section 170.315(e)(2), which is [Reserved].
• The approved SVAP versions table gives the (g)(33) prior authorization guide as "Version 2.2.1-STU 2" where the FY 2027 amendatory text writes "Version 2.2.1-STU 2.2".
• The HTI-2 final rule's amendatory instruction removes and reserves paragraphs "(e)(2) and (g)(2)" while its own preamble names (g)(8), and the current CFR shows (g)(2) live and (g)(8) reserved.

The rename left a trace of the same kind. Section 170.523(f) is the only place in part 170 that still reads "Provide the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP/ONC), no less frequently than weekly, a current list of Health IT Modules that have been certified". The office title changed in April 2026 and that one paragraph has not been conformed to it.

Who tests, who certifies, and who comes back afterwards?

Two organisations do both jobs. On 2 September 2026 healthit.gov listed two ONC-ATLs and two ONC-ACBs, and they are the same pair: Drummond Group, and SLI Compliance, a Division of Gaming Laboratories International, LLC. Both pages carried a last update of 22 June 2026. An ONC-ACB maintains accreditation to ISO/IEC 17065 under section 170.523(a); an ONC-ATL maintains NVLAP accreditation including ISO/IEC 17025 under section 170.524(a). Section 170.557 requires both to provide remote testing and remote certification for development and deployment sites, so distance is a settled question. Supplier availability is the planning constraint, and the number to plan against is two.

section 170.556 is what comes back afterwards. An ONC-ACB must initiate surveillance in the field whenever it becomes aware of facts or circumstances that would cause a reasonable person to question a Module's continued conformity, and may conduct randomized surveillance at randomly selected locations during each calendar year surveillance period. The assessment "must be based on the use of the capability with production data unless the use of test data is specifically approved by the National Coordinator." Production data in a live deployment is PHI, which is why the terms under which an outside test team touches it are settled before any work starts: how PHI is handled and what is signed first sets those out.

A non-conformity becomes public. Section 170.523(f)(1)(xxii) requires the CHPL to carry the specific certification requirements the technology failed to conform to, a summary of the deficiencies the ONC-ACB identified, the developer's explanation where available, and the dates surveillance was initiated and completed. Above the ONC-ACB, section 170.580 lets ONC review certified health IT directly and demand all records related to development, testing, certification, implementation, maintenance and use of that health IT. A corrective action plan under section 170.580(c) has eight required elements and has to be adequate within 90 days of the notice of non-conformity, and section 170.581 ends the chain with a certification ban that takes effect immediately in the case it names. The working answer is to keep test evidence in a state where it can be handed over on request, which is the same state the Real World Testing results report needs it in.

Where does ONC certification go wrong?

• The scope is priced criterion by criterion and section 170.550(g) attaches (g)(3), (g)(4), (g)(5), (g)(6), (b)(10) and (b)(4) after the estimate is signed.
• A Real World Testing plan names a methodology and a care setting and carries no measurement, although section 170.405(b)(1)(iii)(F) requires at least one per criterion.
• API evidence for (g)(10) covers the mandatory elements and stops there, while the criterion requires every element marked must support as well.
• Safety-enhanced design testing runs with fewer than the ten participants section 170.315(g)(3)(ii) requires, or the report omits the association of each task to its certification criterion that (g)(3)(iv)(C) itemises.
• The EHI export is demonstrated with a developer in the room, although section 170.315(b)(10)(i)(B) requires the user to execute it at any time without subsequent developer assistance.
• Service base URLs are published once and never reviewed again, against the quarterly review in section 170.404(b)(2).
• Prescribing rounds miss section 170.315(b)(3)(ii)(E) and (F): oral liquid medications in mL rather than cc, a zero written before the decimal point for amounts under one, and no trailing zeroes after a decimal point.
• The plan is written against the enforcement discretion rather than against section 170.405, so nothing exists to submit on the day the discretion lapses.

What do we run against the ONC criteria?

The work starts from the scope rather than from the criteria list: confirm what the Module is presented for, add what section 170.550(g) and (h) attach to that, then build the evidence each criterion actually asks for, with the API criterion and the dependent design and performance criteria taking most of the effort. The recurring layer is planned in the same pass, because the Real World Testing plan and the results report fall due on fixed dates whether or not anyone budgeted for them. We test and prepare evidence; the certification decision belongs to an ONC-ACB.

The interoperability work itself is described in healthcare interoperability testing, and the record side of it, including traceability from criterion to test to result, in validation documentation.

Section numbers, criterion letters, dates and version strings on this page were read from 45 CFR part 170 as it stood on 31 August 2026, and from healthit.gov on 2 September 2026.