USCDI v3, v4 and HTI-1 for health IT developers: what changed and what to build

Direct answer

USCDI v3 is the required data baseline for ONC-certified health IT. HTI-1 set the deadline at December 31, 2025, and an enforcement discretion notice gave developers until February 28, 2026. For the (g)(10) API that means US Core 6.1.0 and SMART App Launch 2.0.0. USCDI v4, v5 and v6 are voluntary upgrades through SVAP, and v7 was published in July 2026. HTI-5, which would remove 34 certification criteria, is still a proposed rule.

The HTI rules and where each one stands

ONC now operates as ASTP/ONC. The HTI rules page lists four final rules and one proposal. Most of them implement the 21st Century Cures Act of December 2016, which created the information blocking prohibition and the API conditions of certification.

Your current certification depends on the HTI-1 final rule. The HTI-5 proposed rule is what to plan around. Trade press reported in August 2026 that the HTI-5 final rule was at OMB review, but it had not appeared in the Federal Register by early October 2026. Do not commit roadmap decisions to its contents until it does.

USCDI versions, US Core versions and certification status

USCDI is the ONC list of data classes and elements. US Core is the HL7 FHIR implementation guide that represents them. Certification criteria name a USCDI version, and your FHIR server ships a US Core package. Both belong in your architecture decision record. The all USCDI versions page is the authoritative list.

The Standards Version Advancement Process (SVAP) lets a developer certify to a newer version than the regulation requires. It is optional. You still have to support the regulatory baseline, so a module on US Core 9.0.0 must keep satisfying the USCDI v3 requirements.

Two 2025 notices changed what "USCDI v3" means in practice. On March 21, 2025 ASTP/ONC announced enforcement discretion for sexual orientation, gender identity and related elements, and allowed sex to be represented with only 248152002 (Female) and 248153007 (Male). On November 24, 2025 it moved the January 1, 2026 compliance date to February 28, 2026 for 15 criteria, including (g)(10), after the autumn 2025 funding lapse took testing tools offline. Both are listed on the enforcement discretion notices page.

What USCDI v3 added and where it lives in US Core 6.1.0

Compared with v2, USCDI v3 added two data classes, Health Insurance Information and Health Status/Assessments, plus new elements in existing classes. The US Core 6.1.0 USCDI mapping is the element-level reference.

Coverage is the class most teams underestimate, because the data lives in registration and billing systems that never fed the clinical FHIR server. A minimal synthetic instance looks like this:

{
  "resourceType": "Coverage",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage"]
  },
  "identifier": [{
    "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MB" }] },
    "system": "http://example.org/fhir/memberidentifier",
    "value": "M-000123"
  }],
  "status": "active",
  "type": { "coding": [{ "system": "https://nahdo.org/sopt", "code": "3712", "display": "PPO" }] },
  "subscriberId": "S-000456",
  "beneficiary": { "reference": "Patient/example-123" },
  "relationship": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" }] },
  "payor": [{ "reference": "Organization/example-payer" }],
  "class": [{
    "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "group" }] },
    "value": "GRP-7781"
  }]
}

Group Number goes in class with type group, Member Identifier is the identifier typed MB, and Payer Identifier sits on the referenced Organization. A common failure is putting the group number into identifier. The resource still validates, but Group Number is missing from the element where consumers and test tools look for it.

The (g)(10) API after HTI-1

The (g)(10) certification companion guide lists the current requirements. The parts that changed under HTI-1:

• US Core 6.1.0 and SMART App Launch 2.0.0, with SVAP options for later US Core releases and SMART 2.2.0.
• SMART v2 scopes, including granular scopes on Condition and Observation categories, such as patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory.
• Revoking an app's access within one hour of a patient's request, required since March 11, 2024.
• Refresh tokens valid for at least three months for confidential apps and native apps that can secure them.
• Asymmetric client authentication (client-confidential-asymmetric) and POST-based authorization (authorize-post).
• Service base URLs published in a standardized FHIR format, required since December 31, 2024.

Check your discovery document before running the test kit:

GET /fhir/r4/.well-known/smart-configuration
Accept: application/json

{
  "capabilities": [
    "launch-ehr", "launch-standalone", "authorize-post",
    "client-public", "client-confidential-symmetric", "client-confidential-asymmetric",
    "sso-openid-connect", "context-banner", "context-style",
    "context-ehr-patient", "context-ehr-encounter", "context-standalone-patient",
    "permission-offline", "permission-patient", "permission-user", "permission-v2"
  ],
  "code_challenge_methods_supported": ["S256"]
}

Launch flows, scopes and PKCE are covered in detail in SMART on FHIR app launch. For certification testing, the Inferno (g)(10) test kit is the approved method. Before you choose an SVAP version, check which US Core releases the current kit supports, because test kit support can trail SVAP approval.

Decision support interventions and the Insights condition

HTI-1 replaced the clinical decision support criterion with decision support interventions (DSI, 170.315(b)(11)). Developers had to deliver it by December 31, 2024. It requires 13 source attributes for evidence-based DSIs and 31 for predictive DSIs, plus risk management practices for predictive DSIs that the developer supplies. In practice this works like a model card that customers can review.

HTI-5 proposes to revise (b)(11) and remove the source attribute requirements. Until a final rule says otherwise, the criterion stands as written.

The Insights condition originally required several reporting measures starting July 2027. An April 2025 enforcement discretion notice limited reporting to one measure, use of FHIR in apps through certified health IT, and HTI-5 proposes the same limit in regulation.

Information blocking: actors, exceptions, penalties

Information blocking applies to three types of actor: health care providers, developers of certified health IT, and health information networks or exchanges. Since October 6, 2022, the electronic health information (EHI) it covers has not been limited to USCDI. It means ePHI in a designated record set, so a USCDI-only API does not settle your obligations.

45 CFR Part 171 currently contains ten exceptions:

HTI-1 also defined "offer health IT" and added two Infeasibility conditions, covering third-party modification requests and the case where alternative manners have been exhausted. HTI-5 proposes to remove the third-party modification condition and the TEFCA Manner exception, and to require that contracts under the Manner exception be at market rate and contain no unconscionable terms. For QHINs and the TEFCA side of this, see TEFCA explained and US Core and TEFCA implementation.

Penalties depend on the type of actor:

• Developers and HINs/HIEs: OIG civil money penalties of up to $1 million per violation, effective September 1, 2023. A developer can also lose its certification.
• Providers: CMS disincentives from July 31, 2024. Hospitals lose meaningful EHR user status, MIPS clinicians get a zero in Promoting Interoperability, and Shared Savings Program participants can be excluded for at least a year (from January 1, 2025).

On September 3, 2025, HHS announced a crackdown, with OIG investigating complaints and ASTP/ONC expanding certification surveillance.

Developer checklist

• Pin USCDI v3 and US Core 6.1.0 as the floor, and record any SVAP version you adopt.
• Expose Coverage, the health status assessment observations, Specimen, MedicationDispense, RelatedPerson and ServiceRequest. These are the v3 additions teams most often leave out.
• Validate every resource against the profiles, including must-support slices, with the HL7 validator before running Inferno.
• Pass the Inferno (g)(10) kit for standalone patient launch, EHR launch, granular scopes, token refresh, revocation and Bulk Data export.
• Publish service base URLs in the standardized FHIR format.
• Test revocation end to end: patient revokes, and the next API call within one hour returns 401.
• Keep a written information blocking policy that names the exception you rely on whenever you refuse or limit a request.
• If you integrate payer workflows, the HTI-4 criteria (g)(31) to (g)(33) follow Da Vinci CRD, DTR and PAS. See Da Vinci prior authorization.
• If you also sell in Europe, keep separate profile sets. EU Core and US Core are not interchangeable.

Pitfalls

• Treating SVAP as a deadline. US Core 9.0.0 is optional. USCDI v3 on US Core 6.1.0 is mandatory.
• Reading HTI-5 as law. Security criteria such as multi-factor authentication (d)(13) remain in force until a final rule removes them.
• Assuming USCDI v4 is next. The HTI-2 proposal to adopt it was withdrawn, and HTI-5 proposes v3.1.
• Scoping information blocking to the API. The EHI definition is wider than USCDI.

If you need a US Core gap analysis, (g)(10) test preparation or a FHIR façade over an existing EHR, see HL7 FHIR integration.