# USCDI v3, v4 and HTI-1 for health IT developers: what changed and what to build > Which USCDI version certified health IT must support in 2026, which US Core release goes with it, what HTI-1 changed for (g)(10), decision support and information blocking, and what the HTI-5 proposal would change. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/uscdi-hti-1-health-it-developers Updated: 2026-10-06 ## 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](https://healthit.gov/regulations/hti-rules) 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. | Rule | Published | Status (October 2026) | What it means for developers | | --------- | --------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | **HTI-1** | January 9, 2024 | Final | USCDI v3 baseline, DSI criterion, `(g)(10)` moved to US Core 6.1.0 and SMART 2.0.0, Insights condition, information blocking changes | | **HTI-2** | Proposed July 2024 | TEFCA parts finalized December 2024; remaining proposals withdrawn December 29, 2025 | The proposal to adopt USCDI v4 as the next baseline was withdrawn | | **HTI-3** | December 17, 2024 | Final | Protecting Care Access exception, revised Privacy exception | | **HTI-4** | August 2025, with the FY 2026 IPPS final rule | Final | NCPDP SCRIPT 2023011 (only version accepted from January 1, 2028), real-time prescription benefit, prior authorization API criteria | | **HTI-5** | December 29, 2025 | Proposed. Comments closed February 27, 2026 | Remove 34 criteria, revise 7, adopt USCDI v3.1, tighten information blocking exceptions | Your current certification depends on the [HTI-1 final rule](https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and). The [HTI-5 proposed rule](https://www.federalregister.gov/documents/2025/12/29/2025-23896/health-data-technology-and-interoperability-astponc-deregulatory-actions-to-unleash-prosperity) 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](https://isp.healthit.gov/all-uscdi-versions) is the authoritative list. | USCDI | US Core | Certification status (October 2026) | | ----------------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | v1 (July 2020 errata) | 3.1.1 | Expired as a baseline on January 1, 2026 | | v2 (July 2021) | 5.0.1 | Never a baseline; US Core 5.0.1 was SVAP-approved in 2022 | | v3 (July 2022, October 2022 errata) | 6.1.0 | **Required baseline** from January 1, 2026 | | v3.1 (June 2025) | No dedicated release | Removes sexual orientation and gender identity elements; HTI-5 proposes adopting it | | v4 (July 2023) | 7.0.0 | SVAP 2024, voluntary from August 19, 2024 | | v5 (July 2024) | 8.0.0 (8.0.1 correction) | SVAP 2025, voluntary from August 29, 2025 | | v6 (July 2025) | 9.0.0 (May 2026) | [SVAP 2026](https://healthit.gov/blog/standards/advancements-in-health-it-oncs-2026-approved-svap-standards/), voluntary from August 29, 2026 | | v7 (July 23, 2026) | None published yet | Published by ASTP/ONC, not adopted or SVAP-approved | 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](https://www.healthit.gov/topic/certification-criteria-compliance-dates-enforcement-discretion-notice). ## 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](https://hl7.org/fhir/us/core/STU6.1/uscdi.html) is the element-level reference. | USCDI v3 element | US Core 6.1.0 profile | Search to test | | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Coverage Status, Coverage Type, Relationship to Subscriber, Member/Subscriber Identifier, Group Number, Payer Identifier | US Core Coverage | `GET [base]/Coverage?patient=[id]` | | Functional Status, Disability Status, Mental/Cognitive Status | US Core Observation Screening Assessment, Simple Observation, Condition Problems and Health Concerns | `category` values `functional-status`, `disability-status`, `cognitive-status` | | Health Concerns | US Core Condition Problems and Health Concerns | `category=health-concern` | | Pregnancy Status | US Core Observation Pregnancy Status (plus Pregnancy Intent) | Observation by `code` | | Specimen Type, Result Status | US Core Laboratory Result Observation, US Core Specimen | Specimen by `_id` | | Dose, Dose Unit, Indication | US Core MedicationRequest | MedicationRequest by `patient` | | Fill Status | US Core MedicationDispense | `GET [base]/MedicationDispense?patient=[id]` | | Related Person's Name and Relationship | US Core RelatedPerson | RelatedPerson by `_id` | | Occupation, Occupation Industry | US Core Observation Occupation | Observation by `code` | | Tribal Affiliation, Date of Death | US Core Patient (extension, `deceased[x]`) | Patient read | | Reason for Referral | US Core ServiceRequest | `GET [base]/ServiceRequest?patient=[id]` | 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: ```json { "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](https://healthit.gov/test-method/standardized-api-patient-and-population-services) 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: ```http GET /fhir/r4/.well-known/smart-configuration Accept: application/json ``` ```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](https://alabenaicha.me/insights/smart-on-fhir-app-launch). For certification testing, the [Inferno (g)(10) test kit](https://inferno.healthit.gov/test-kits/onc-certification-g10/) 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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-171) currently contains **ten exceptions**: | Subpart | Exceptions | | ------------------------------------- | -------------------------------------------------------------------------------------------------------- | | B: not fulfilling requests | Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance, Protecting Care Access (HTI-3) | | C: procedures for fulfilling requests | Manner (renamed from Content and Manner by HTI-1), Fees, Licensing | | D: TEFCA | TEFCA Manner (HTI-1) | 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](https://alabenaicha.me/insights/tefca-trusted-exchange-framework) and [US Core and TEFCA implementation](https://alabenaicha.me/insights/fhir-us-core-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](https://www.hhs.gov/press-room/hhs-crackdown-health-data-blocking.html), 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](https://alabenaicha.me/insights/da-vinci-prior-authorization-fhir). * If you also sell in Europe, keep separate profile sets. [EU Core and US Core](https://alabenaicha.me/insights/eu-core-vs-us-core-fhir-comparison) 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](https://alabenaicha.me/services/hl7-fhir-integration).